SPF, DKIM and DMARC Explained: How the Three Records Work Together

SPF says which servers may send mail for your domain. DKIM signs each message so receivers can prove which domain sent it and that it was not changed in transit. DMARC ties both to the From address people actually see: a message passes DMARC only if SPF or DKIM passes for a domain that matches the From domain, and the DMARC record tells receivers what to do when it doesn't.

You can check all three for any domain right now with our free SPF checker, DKIM checker and DMARC checker. The rest of this guide explains what those tools are reading and why each result matters.

The short version in one table

	SPF	DKIM	DMARC
Standard	RFC 7208 (2014)	RFC 6376 (2011)	RFC 7489 (2015), replaced by RFC 9989 (May 2026)
What it checks	The envelope sender (MAIL FROM) and HELO name	A signature in the DKIM-Signature header	That SPF or DKIM passed for the From domain
Where it lives	TXT record at example.com	TXT record at selector._domainkey.example.com	TXT record at _dmarc.example.com
Survives forwarding	Usually not	Yes, if the message isn't modified	Yes, via DKIM
Tells receivers what to do	Only weakly (-all vs ~all)	No	Yes: none, quarantine or reject

The reason three records exist is that each one, on its own, leaves a gap. SPF and DKIM authenticate a domain, but not necessarily the one in the From line. DMARC closes that gap.

SPF: who is allowed to send

SPF is a list of servers authorised to send mail using your domain in the envelope sender. The receiving server looks up the TXT record on the domain in the MAIL FROM command (the address bounces go to, often shown as Return-Path) and checks whether the connecting IP is on the list. RFC 7208 also allows checking the HELO name.

A typical record for a company on Google Workspace that also sends newsletters through a marketing platform:

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

Read left to right:

• v=spf1 identifies the record as SPF. There must be only one such record per domain.
• include: pulls in another domain's SPF list, here Google's and the email platform's.
• -all means everything not listed should fail. ~all means softfail: suspicious, but don't reject on SPF alone. ?all is neutral and gives receivers almost nothing.

Two limits trip people up. RFC 7208 section 4.6.4 says implementations "MUST limit the total number" of DNS-querying terms (include, a, mx, ptr, exists and redirect) to 10, and exceeding it is a permanent error. It also says lookups that return nothing, called "void lookups", SHOULD be limited to two. If you have stacked up includes over the years, our worked example on fixing too many DNS lookups shows how to get back under the limit, and common SPF mistakes covers the rest.

What SPF can't do: it says nothing about the From address the reader sees. A spammer can use their own domain in MAIL FROM, pass SPF for it, and put your domain in the From header. And when a message is forwarded, the forwarding server's IP isn't in your record, so SPF usually fails.

DKIM: a signature that travels with the message

DKIM attaches a cryptographic signature to each message. The sending server signs selected headers and the body with a private key, and adds a DKIM-Signature header. Two tags in that header matter most for understanding it:

• d= is the signing domain, the domain taking responsibility for the message.
• s= is the selector, which tells the receiver where to find the public key.

The receiver fetches the public key from DNS at selector._domainkey.domain, for example:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

v=DKIM1 is the version, k=rsa the key type and p= the public key itself (truncated here). If the signature verifies, the receiver knows the d= domain signed the message and that the signed parts were not altered. An empty p= means the key has been revoked.

Because the signature lives inside the message, DKIM survives ordinary forwarding. It breaks when an intermediary changes signed content, which mailing lists that add footers or subject tags often do.

Key length matters. RFC 8301 says signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits". Our DKIM key length study measured how many domains still use 1024-bit keys. The DKIM checker finds common selectors automatically and decodes the key length. Setup guides for the two biggest platforms are here: Google Workspace and Microsoft 365.

What DKIM can't do: like SPF, it authenticates the d= domain, which can be any domain. A message signed by d=bulk-sender.net with From: you@example.com passes DKIM but proves nothing about example.com.

DMARC: tying both to the From address

DMARC answers the question the other two leave open: did this message really come from the domain in the From header? A message passes DMARC when either:

1. SPF passes and the MAIL FROM domain aligns with the From domain, or
2. DKIM passes and the d= domain aligns with the From domain.

One aligned pass is enough. Both RFC 7489 and RFC 9989 define it that way.

How alignment works

Alignment has two modes, set separately for SPF (aspf) and DKIM (adkim):

• Relaxed (r, the default): the two domains share the same organizational domain. bounces.example.com aligns with example.com.
• Strict (s): the two domains must be identical.

Here's how that plays out for a newsletter sent through a third-party platform:

Header	Value	Result
From	news@example.com	The domain DMARC protects
MAIL FROM	bounce-123@mail.platform.net	SPF passes for platform.net, not aligned
DKIM d=	example.com (custom DKIM set up)	DKIM passes, aligned
DMARC		Pass, through DKIM

Remove the custom DKIM and the platform signs with its own domain. Now both SPF and DKIM pass, neither is aligned, and DMARC fails. This is the most common DMARC failure on small domains: everything "passes" in the headers and the message still fails. Our guide to reading email headers shows where to find each of these values.

The DMARC record

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

• v=DMARC1 must come first.
• p= is the policy for mail that fails: none (monitor only), quarantine (treat as suspicious, usually spam folder) or reject (refuse it).
• rua= is where receivers send daily aggregate reports, which show every source sending as your domain and whether it passed.

p=none changes nothing about delivery. It exists so you can collect reports and fix legitimate senders before enforcing. Our annotated DMARC record examples cover the other tags, and moving from p=none to p=reject covers the rollout.

What changed in 2026

RFC 9989, published in May 2026, replaced RFC 7489 as the DMARC standard. It moved DMARC from Informational to the Standards Track, removed the pct, rf and ri tags, added a t tag for testing mode and a psd tag, and folded in the np tag for non-existent subdomains. It also replaces reliance on the Public Suffix List with a "DNS Tree Walk" for finding the organizational domain. For most domain owners the practical change is small: records with pct still work at receivers that haven't updated, and the new testing approach is explained in the rollout guide linked above.

What Gmail, Yahoo and Microsoft require

All three large mailbox providers now publish authentication rules, read from their own pages in October 2026:

Provider	All senders	Bulk senders
Gmail	"Set up SPF or DKIM"	SPF and DKIM; DMARC record, p=none acceptable; From aligned with SPF or DKIM domain (about 5,000+ messages a day to personal Gmail accounts)
Yahoo	"Implement SPF or DKIM at a minimum"	Both SPF and DKIM; "a valid DMARC policy with at least p=none" and DMARC must pass; relaxed alignment acceptable
Outlook.com	Not specified	Over 5,000 emails a day: SPF must pass, DKIM must pass, DMARC at least p=none aligned with SPF or DKIM

Note Microsoft's wording. DMARC itself is satisfied by one aligned pass, but Microsoft's high-volume rules ask for SPF and DKIM to both pass. A domain that only passes DMARC through DKIM meets Gmail's rule and may not meet Microsoft's. Details are in the Gmail and Yahoo requirements and the Outlook requirements.

How to check your own domain in five minutes

1. SPF. Run your domain through the SPF checker. You want exactly one v=spf1 record, every service that sends for you included, 10 or fewer DNS lookups, and an -all or ~all ending.
2. DKIM. Run the DKIM checker. You want a valid key for every platform that sends as your domain, at 2048 bits where the platform allows it. If a platform isn't found, look up its selector in its setup docs.
3. DMARC. Run the DMARC checker. You want a record at _dmarc, a policy, and an rua address someone actually reads. If you have no record, the DMARC generator builds one.
4. Alignment. Send a message from each platform to a Gmail address, open "Show original", and confirm that SPF or DKIM passes for your own domain, not the platform's.
5. Watch the reports. Aggregate reports will show senders you forgot about, such as a billing system or a CRM, before you move to enforcement.

The three records are cheap to publish and only valuable together. SPF and DKIM prove that some domain sent a message; DMARC is what makes that domain yours.