SPF vs DKIM vs DMARC: what each one checks and how they work together
SPF, DKIM and DMARC side by side: what each checks, which domain it looks at, where its record lives, and why DMARC needs the other two.
On this page
SPF (opens in a new tab) (Sender Policy Framework) lets a domain say which servers may use its name when sending. DKIM (opens in a new tab) (DomainKeys Identified Mail) adds a cryptographic signature that ties the message to a domain. DMARC (opens in a new tab) (Domain-based Message Authentication, Reporting and Conformance) needs an SPF or DKIM pass for a domain aligned with the From: address, and lets the domain owner request how receivers handle mail that fails. So DMARC builds on the other two: set up SPF and DKIM first.
SPF, DKIM and DMARC side by side
SPF (opens in a new tab) checks the domain in the envelope ("MAIL FROM") or HELO identity, and its record is a TXT record (opens in a new tab) at that domain. DKIM (opens in a new tab) checks the domain that signed the message, and its public key is a TXT record under _domainkey (opens in a new tab). DMARC (opens in a new tab) checks the From: domain, which RFC 9989 calls the Author Domain, and its record lives at _dmarc (opens in a new tab).
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it checks | Whether the sending server is authorised for the MAIL FROM or HELO domain | A cryptographic signature on the message | Whether an SPF or DKIM pass is aligned with the From: domain |
| Which domain | MAIL FROM or HELO domain | The signing domain (d=) |
The From: (Author) domain |
| Where the record lives | TXT at the domain, for example example.com |
TXT at <selector>._domainkey.example.com |
TXT at _dmarc.example.com |
| What a pass shows | The server may use that domain | The signed content has not changed since it was signed | The From: domain was authenticated by SPF or DKIM |
Check your domain now
See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.
SPF: which servers may send for the domain
RFC 7208 (opens in a new tab) defines SPF as a way for a domain to authorise hosts to use its name in the MAIL FROM or HELO identity. Receivers test the sending server against the published record during the mail transaction.
The record is a list of mechanisms. Receivers read them from left to right (opens in a new tab), and the first one that matches decides the result. The RFC's own example ends with the all mechanism (opens in a new tab), which sits rightmost as the default:
v=spf1 a mx -all
SPF also sets limits. A domain must not publish more than one SPF record (opens in a new tab), and evaluation is capped at 10 DNS-querying terms (opens in a new tab); going past 10 returns a permanent error. For the lookup error, see SPF: too many DNS lookups; to write a record, use the SPF record generator.
DKIM: a signature tied to a domain
DKIM (opens in a new tab) lets an organisation take some responsibility for a message by associating a domain name with it. The receiver validates that with a cryptographic signature and a public key fetched from the signer's domain. A valid signature shows that the signed content has not changed since it was signed.
The signature travels in the DKIM-Signature header (opens in a new tab). Its d= tag names the domain taking responsibility, and its s= tag names the selector. The receiver joins the two to find the key under _domainkey (opens in a new tab): a signature with d=example.com and s=selector1 means a DNS query for selector1._domainkey.example.com.
If signatures fail, see DKIM fail.
DMARC: the check that ties SPF and DKIM to the From: address
RFC 9989 (opens in a new tab) points out that SPF and DKIM authenticate domains that are not directly tied to the From: address. DMARC closes that gap: a DMARC pass needs an SPF or DKIM pass and also needs that passing domain to be "aligned" with the From: domain.
Alignment (opens in a new tab) comes in two strengths. Relaxed alignment means the From: domain and the authenticated domain share the same Organizational Domain. Strict alignment means the two are identical.
One aligned identifier is enough (opens in a new tab). RFC 9989 gives the reason alignment is required: any domain owner, even a bad actor, can publish an SPF record for its own domain and get an SPF pass, and a message can carry a valid signature from any domain. RFC 9989 also notes that nearly all domain owners have found relaxed alignment sufficient. For SPF, DMARC uses only the MAIL FROM identity (opens in a new tab).
The record (opens in a new tab) is a TXT record at _dmarc in front of the domain, so example.com publishes it at _dmarc.example.com. Its p tag (opens in a new tab) states the policy for mail that fails: none expresses no preference, quarantine says the owner considers such mail suspicious, and reject says the use of the domain is not valid. The rua tag lists the addresses that aggregate reports are to be sent to:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
A domain and all its subdomains at p=none while the owner reads aggregate reports is what RFC 9989 calls "Monitoring Mode" (opens in a new tab). Next: DMARC record tags and DMARC reports.
What one real domain publishes
Here is what gmail.com publishes for SPF and DMARC, checked against live DNS. The SPF record at gmail.com, v=spf1 redirect=_spf.google.com, is a single redirect.
The redirect modifier (opens in a new tab) is meant for sharing one set of authorisations and policy within a single administrative domain. The record at _spf.google.com lists ip4 and ip6 ranges and ends with ~all.
The DMARC record at _dmarc.gmail.com is:
v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com
In the _dmarc.gmail.com record, p=none expresses no preference, and sp=quarantine sets the subdomain policy to quarantine: the domain owner considers failing mail from its subdomains suspicious. The p policy (opens in a new tab) applies to the domain queried and to its subdomains unless a subdomain tag such as sp sets a separate policy. The rua tag names the address aggregate reports are to be sent to.
What Gmail requires
Google's sender guidelines (opens in a new tab) require SPF or DKIM from all senders, and SPF, DKIM and DMARC from bulk senders. Since February 1, 2024, the bulk-sender requirements apply to senders of more than 5,000 messages a day to Gmail accounts. For those senders, the DMARC policy can be none, and for direct mail the From: domain must be aligned with either the SPF domain or the DKIM domain. Messages that are not authenticated might be marked as spam or rejected with a 5.7.26 error.
The order to set them up
- SPF and DKIM for every sender. List each service that sends as your domain in SPF, and turn on DKIM signing with your domain in each one. RFC 9989 (opens in a new tab) recommends using both as the mechanisms underneath DMARC.
- DMARC at
p=nonewithrua. This is Monitoring Mode (opens in a new tab): the owner uses the aggregate reports to adjust the authentication of its mail streams. To write the record, use the DMARC record generator. - Enforce once the reports show your senders pass. For that step, see DMARC policy not enabled; for failing mail, see DMARC fail.
Check all three for your domain
The free check reads the public DNS records of the domain you enter and changes nothing; no account is needed. It tries commonly used DKIM selectors, so a key under an unusual selector can exist without the check seeing it. A DNS finding shows how your domain is set up, not where a particular message landed.
Sources
- RFC 7208 §1: SPF introduction (opens in a new tab)
- RFC 7208 §3.1: TXT records (opens in a new tab)
- RFC 7208 §3.2: multiple records (opens in a new tab)
- RFC 7208 §4.6.2: mechanisms (opens in a new tab)
- RFC 7208 §4.6.4: DNS lookup limits (opens in a new tab)
- RFC 7208 §5.1: the all mechanism (opens in a new tab)
- RFC 7208 §6.1: redirect (opens in a new tab)
- RFC 6376 §1: DKIM introduction (opens in a new tab)
- RFC 6376 §3.5: the DKIM-Signature header (opens in a new tab)
- RFC 6376 §3.6.2: key lookup in DNS (opens in a new tab)
- RFC 9989 §1: DMARC introduction (opens in a new tab)
- RFC 9989 §3.2.10: alignment (opens in a new tab)
- RFC 9989 §3.2.12: Monitoring Mode (opens in a new tab)
- RFC 9989 §4.4: identifier alignment (opens in a new tab)
- RFC 9989 §4.4.2: SPF-authenticated identifiers (opens in a new tab)
- RFC 9989 §4.5: DMARC policy record (opens in a new tab)
- RFC 9989 §4.7: DMARC record format (opens in a new tab)
- Google: email sender guidelines (opens in a new tab)
Tools for this
-
SPF, DKIM and DMARC check
Check the email records a domain publishes today and see what to fix first.
-
SPF record generator
Build an SPF record for the services that send your email.
-
DMARC record generator
Build a DMARC record step by step, from monitoring to reject.
Frequently asked questions
Do I need SPF, DKIM and DMARC, or is one enough?
Gmail requires SPF or DKIM from all senders and SPF, DKIM and DMARC from bulk senders, and RFC 9989 recommends using both SPF and DKIM underneath DMARC.
Can DMARC pass when SPF fails?
Yes. DMARC needs only one authenticated identifier aligned with the From: domain, so an aligned DKIM pass is enough even when SPF fails.
Does a passing check mean my email reaches the inbox?
No. A DNS check shows how your domain is set up, not where a particular message landed.
Check your domain now
See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.