SPF, DKIM and DMARC explained in plain English

Email was designed without any built-in way to prove who sent a message. SPF, DKIM and DMARC are three DNS-based standards that fill that gap. Together they let a receiving server check that mail claiming to come from your domain really does, and tell it what to do when it does not.

They are no longer optional for marketing mail. Gmail, Yahoo and Microsoft all expect them from senders of any real volume. Here is what each one does, what the records look like, and how to set them up safely. All examples use example.com.

The short version

SPF (Sender Policy Framework)

SPF is a published list of the servers allowed to send mail for a domain. When a message arrives, the receiving server looks at the envelope sender domain (also called the Return-Path or MAIL FROM, which is usually hidden from the reader), fetches that domain's SPF record, and checks whether the connecting IP address is on the list.

An example record:

example.com.  TXT  "v=spf1 include:_spf.google.com include:mail.example-esp.net ~all"

• v=spf1 marks it as an SPF record.
• Each include: authorizes another provider's servers.
• ~all (softfail) says other servers are probably not authorized. -all (fail) says they definitely are not.

The two SPF rules people break most

One SPF record per domain. If a domain has two TXT records that start with v=spf1, SPF returns a permanent error. When you add a new provider, merge its include: into the existing record instead of creating a second one.

The 10-DNS-lookup limit. SPF evaluation may trigger at most 10 DNS lookups. Mechanisms such as include, a, mx, ptr, exists and the redirect modifier each count, and nested includes count too. Exceed 10 and SPF fails with a permanent error, even though the record looks fine. Remove providers you no longer use, and avoid ptr entirely.

What SPF cannot do

SPF checks the envelope sender, not the From address people see. It also usually breaks when mail is forwarded, because the forwarding server is not in your record. That is why SPF alone is not enough.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each message. The sending server signs selected headers and the body with a private key. The receiving server reads the d= domain and s= selector from the signature, fetches the matching public key from DNS, and checks the signature.

If it verifies, the receiver knows two things: the domain in d= took responsibility for the message, and the signed parts were not altered in transit.

An example public key record:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

Many sending providers ask you to publish a CNAME instead, pointing to a key they host and rotate:

s1._domainkey.example.com.  CNAME  s1.dkim.example-esp.net.

A few practical points:

• Use 2048-bit RSA keys where your provider supports them.
• Selectors let you run several keys at once, one per provider, without conflict.
• DKIM usually survives forwarding, as long as the message is not modified along the way. That makes it the more reliable half of DMARC.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC ties SPF and DKIM to the domain your readers actually see in the From header, and lets you publish a policy for mail that fails.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• p= is the policy: none, quarantine or reject.
• rua= is where receivers send aggregate reports, which are daily XML summaries of who is sending mail as your domain and whether it passes.
• Optional tags include sp= (policy for subdomains), adkim= and aspf= (alignment mode) and pct= (share of failing mail the policy applies to).

Alignment, the part most guides skip

A message passes DMARC when at least one of these is true:

• SPF passes and the envelope sender domain aligns with the From domain, or
• DKIM passes and the DKIM d= domain aligns with the From domain.

In relaxed mode (the default), "aligns" means the same organizational domain, so bounce.example.com aligns with example.com. In strict mode (adkim=s or aspf=s) the domains must match exactly.

This is why a message can pass SPF and DKIM yet fail DMARC. If your provider signs with its own domain and uses its own bounce domain, both checks pass for the provider, not for you. Custom DKIM and a custom Return-Path on your own domain fix that.

The three policies

Receivers treat the policy as a request, and each applies its own judgment.

A safe DMARC rollout path

1. Publish SPF and DKIM for every service that sends as your domain. Think beyond marketing: help desk, invoicing, CRM, calendar tools and your own mail server.
2. Publish p=none with a rua address. This changes nothing about delivery but starts the reports.
3. Read the reports for a few weeks. Look for legitimate sources that fail alignment and fix them. Anything unrecognized may be spoofing.
4. Move to p=quarantine. Some teams step up gradually using pct=, for example applying it to part of the failing mail first.
5. Move to p=reject once reports show your legitimate mail consistently passing.

Rushing to p=reject before step 3 is the classic way to send your own invoices to the void.

Common mistakes

• Two SPF records on the same domain, usually after adding a new tool.
• Too many SPF lookups from stacking includes over the years.
• DKIM not enabled at a provider, or enabled with the provider's own domain, so it does not align.
• DMARC record at the wrong name. It must be at _dmarc.example.com, not the root.
• Syntax slips, such as a missing semicolon between DMARC tags, v=DMARC1 not being the first tag, or a missing mailto: in rua.
• Forgetting subdomains. Without sp=, subdomains inherit the main policy, which is usually what you want, but check it.
• Treating p=none as the finish line. It is monitoring, not protection against spoofing.

How to check your records

• Use the free SPF checker to see your record, catch duplicate records and count DNS lookups.
• Use the DMARC checker to confirm your policy and reporting address.
• To check DKIM on a real message, send one to a mailbox you control and look for dkim=pass and dmarc=pass in the Authentication-Results header.

If you send through InboxRoads, sending domains generate the SPF, DKIM and DMARC records for you, plus a custom Return-Path where the sending provider supports it, so your mail can align with your own domain. Click Verify DNS once the records are published; only verified domains can be used for senders.

FAQ

Do I need all three?

Yes, if you send marketing mail at any real volume. As of 2026, Gmail and Yahoo require SPF, DKIM and DMARC for bulk senders. See our Gmail and Yahoo bulk sender requirements checklist.

Should my SPF record end in ~all or -all?

Both are common. With DMARC in place, receivers mostly act on the DMARC result, so the difference matters less. Many senders use ~all while still auditing sources.

How long do DNS changes take?

Often minutes, sometimes longer, depending on the record's TTL and your DNS host. If a check fails right after publishing, wait and try again.

Will DMARC stop all phishing that uses my brand?

No. At p=reject it blocks exact-domain spoofing at receivers that enforce it. It does not stop lookalike domains such as examp1e.com.