SPF, DKIM, and DMARC Explained: Email Authentication

SPF, DKIM, and DMARC are three DNS-based records that work together to prove an email actually came from the domain it claims to, and to tell receiving mail servers what to do when it doesn’t. Email’s original protocol, SMTP, has no built-in sender verification — anyone can put any “From” address on a message — which is exactly why phishing and spoofing became so easy, and why these three records exist as a bolt-on trust layer.

SPF: who is allowed to send

Sender Policy Framework (SPF) is a DNS TXT record listing which mail servers are authorized to send email on behalf of a domain. When a receiving server gets a message claiming to be from example.com, it looks up example.com’s SPF record and checks whether the connecting server’s IP address is on the authorized list.

example.com. IN TXT "v=spf1 include:_spf.google.com ip4:203.0.113.5 -all"

That record says: mail from example.com is legitimate if it comes from Google Workspace’s mail servers or from the IP 203.0.113.5; the -all at the end means anything else should be rejected outright. SPF’s weakness is that it only checks the envelope sender (the technical return-path address used for bounce handling), not the visible “From” header a person actually sees — so SPF alone doesn’t stop every kind of spoofing, and it breaks when a message is forwarded through a server not on the original list, since the forwarding server’s IP won’t match.

DKIM: proving the content wasn’t altered

DomainKeys Identified Mail (DKIM) takes a different approach: instead of checking where a message came from, it cryptographically signs the message content. The sending server generates a signature over specific headers and the body, using a private key, and publishes the corresponding public key as a DNS TXT record.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

The signature is attached to the outgoing message as a DKIM-Signature header. A receiving server fetches the public key from DNS using the selector named in that header, verifies the signature, and can confirm two things: the message really was signed by a holder of the domain’s private key, and the signed parts of the message haven’t been altered in transit. This is the same public/private key model behind digital signatures generally — a different trust model from a shared-secret scheme like HMAC — with DKIM simply applying it to email headers and body content.

Unlike SPF, DKIM survives most forwarding, because the signature travels with the message rather than depending on the connecting IP. But DKIM alone doesn’t verify which domain’s “From” address a message is claiming — it only proves that whoever signed it controlled the domain named in the signature, which isn’t necessarily the visible From address either.

DMARC: tying it together with a policy

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the piece that closes the gap both SPF and DKIM leave open on their own: it explicitly checks that the domain in the visible “From” header aligns with the domain that passed SPF or DKIM (a check called “alignment”), and it publishes a policy telling receivers what to do when that check fails.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:reports@example.com"

The p= tag sets the policy:

• p=none — take no enforcement action, just collect reports. This is the recommended starting point.
• p=quarantine — treat failing messages as suspicious (usually routed to spam).
• p=reject — refuse failing messages outright.

The rua= tag requests aggregate reports, which is how domain owners actually discover what’s sending mail as their domain — including services they forgot they’d authorized, or genuine spoofing attempts — before tightening the policy to quarantine and eventually reject.

How the three fit together

	Checks	Survives forwarding	What it verifies
SPF	Sending server’s IP address	No	Envelope sender is an authorized server
DKIM	Cryptographic signature over headers/body	Yes	Message content wasn’t altered, signer controls the signing domain
DMARC	Alignment between SPF/DKIM and the visible From domain	N/A — it’s a policy layer	Combines and enforces the other two

A message can pass SPF but fail DMARC (if the SPF-authorized domain doesn’t match the visible From address), or pass DKIM but fail DMARC for the same reason. DMARC is what turns “this message passed some check” into “this message is legitimately from the domain the recipient actually sees” — which is the property phishing protection actually needs.

Why this matters beyond spam filtering

Getting SPF, DKIM, and DMARC configured correctly isn’t just about avoiding the spam folder — a p=reject DMARC policy is one of the more effective, low-cost defenses against domain spoofing used in business email compromise and phishing campaigns that impersonate a company’s own domain, the same class of attack that passkeys are designed to make harder to exploit even if a credential is captured. It’s also increasingly a prerequisite for deliverability: major mailbox providers have progressively tightened bulk-sender requirements around these three records, so a domain sending marketing or transactional email without them risks messages being filtered or rejected regardless of content.

Rolling out DMARC safely is a staged process: start at p=none and watch the aggregate reports to find every legitimate sending source (marketing platforms, support tools, internal scripts), fix or add SPF/DKIM coverage for each one, and only then move to quarantine and finally reject. Jumping straight to reject without that discovery step is the most common way teams accidentally block their own legitimate mail.

The takeaway

SPF authorizes which servers can send for a domain, DKIM cryptographically signs message content so it can’t be altered in transit, and DMARC ties the two together by checking that the visible From address aligns with whichever check passed — then enforces a policy on anything that doesn’t. None of the three is sufficient alone; together they’re the standard defense against email spoofing, and rolling them out safely means starting with p=none reporting before tightening to reject.