- Every sender to Gmail needs SPF or DKIM; past 5,000 messages a day you need SPF, DKIM, DMARC and a From header aligned with one of them.
- DMARC passes when at least one mechanism produces an aligned pass, and alignment defaults to relaxed, so an exact domain match is not required unless you ask for it.
- SPF fails with a permerror beyond 10 DNS-querying terms, and nested vendor includes count toward your total.
Three DNS records decide whether your mail is trusted: SPF, DKIM and DMARC. If you send under 5,000 messages a day to Gmail addresses, Google requires either SPF or DKIM. Cross 5,000 a day and it requires SPF and DKIM and DMARC, plus a From header that lines up with one of them. Everything else in this guide is about getting those records right the first time, and about the two mistakes that silently break them.
What each record actually proves
The three are often described as one system. They are not. Each answers a different question, and each leaves a gap the next one covers.
| Record | What it proves | What it does not prove |
|---|---|---|
| SPF | The sending server's IP is one the domain authorised | Nothing about the message contents, and nothing about the From address a reader sees |
| DKIM | The listed headers and body were not altered after signing, by a key published under the signing domain | The sending IP address. It also does not, by itself, bind the signature to the visible From header |
| DMARC | That an SPF or DKIM pass belongs to the same domain the reader sees in From, and tells receivers what to do when it does not | That the message is wanted. It is an identity check, not a spam verdict |
That middle column matters. DKIM's own specification is explicit that a signature "asserts nothing else about 'protecting' the end-to-end integrity of the message", and that matching the signature to a header identity is left to receiver policy. DMARC exists precisely to close that gap.
Alignment is the rule most setups get wrong
DMARC does not simply ask whether SPF or DKIM passed. It asks whether a pass aligned with the domain in the From header. A message can pass SPF cleanly and still fail DMARC, because the SPF check validated your email vendor's bounce domain rather than yours.
Two details are worth committing to memory. First, DMARC is satisfied when
at least one mechanism produces an aligned pass, so you do not need
both SPF and DKIM to succeed on every message. Second, alignment defaults to
relaxed, which accepts a match on the organisational domain, so a signature
from mail.example.com aligns with a From address at
example.com. Strict mode requires an exact match of the full domain name.
You opt into strict with adkim=s or aspf=s.
The practical consequence: get DKIM signing with your own domain in the
d= tag. DKIM survives forwarding far better than SPF does, so an aligned
DKIM signature is what keeps DMARC passing when a recipient auto-forwards your mail.
What is required at your sending volume
Google's sender requirements took effect on 1 February 2024 and separate all senders from bulk senders at a threshold of 5,000 messages per day to Gmail accounts.
| Requirement | Under 5,000/day | 5,000+/day |
|---|---|---|
| SPF or DKIM | Required (either one) | Not sufficient on its own |
| SPF and DKIM | Recommended | Required (both) |
| DMARC record | Recommended | Required |
| From aligned with SPF or DKIM domain | Recommended | Required |
| Spam rate in Postmaster Tools | Below 0.30% | Below 0.30%, target 0.10% |
Note what the bulk requirement does not demand: an enforcing policy.
A DMARC record with p=none satisfies the requirement. That is deliberate,
and it is what makes a careful rollout possible.
The ten-lookup limit that breaks SPF quietly
SPF has a hard ceiling that surprises teams who add tools over time. Every
include, a, mx, ptr,
exists and redirect term costs a DNS lookup, and the
specification requires implementations to "limit the total number of those terms to 10
during SPF evaluation" and to return permerror if that limit is exceeded.
Nothing in your DNS panel warns you. You add a fourth vendor's
include:, that vendor's record contains three includes of its own, and
your SPF quietly starts failing for every message. Two related rules: a domain must not
publish more than one SPF record, and a record should end in all or a
redirect rather than trailing off. Use ~all while you are
still watching reports and -all once you are confident every legitimate
sender is listed.
A five-minute audit
Count the DNS-querying terms in your own record, then expand every
include: one level and count theirs. If the total is 8 or more, you are one
vendor away from an outage. Consolidate by removing tools that no longer send mail
rather than by nesting further.
A rollout order that will not bounce your own invoices
The failure mode here is enforcing before you know who sends on your behalf. Payroll, the CRM, the helpdesk, the invoicing tool and the marketing platform all send as your domain, and the person configuring DNS rarely knows all five.
| Step | Action | Wait for |
|---|---|---|
| 1 | Inventory every system that sends as your domain | Nothing. Do this first |
| 2 | Publish SPF listing those senders; end with ~all | DNS propagation |
| 3 | Enable DKIM at each vendor with your domain in d= | Each vendor to confirm signing |
| 4 | Publish v=DMARC1; p=none; rua= your reporting address | Two to four weeks of reports |
| 5 | Fix every legitimate sender showing as unaligned | Reports to come back clean |
| 6 | Move to p=quarantine | Another reporting cycle |
| 7 | Move to p=reject | Done |
Step 4 is the one teams skip, and it is the only step that tells you the truth. The
rua tag has no default: if you leave it out, aggregate reports are simply
never generated, and you move to enforcement blind.
Where the records live
All three are DNS TXT records, but not in the same place, which is a common source of confusion:
| Record | DNS name | Starts with |
|---|---|---|
| SPF | The domain itself | v=spf1 |
| DKIM | selector._domainkey.example.com | v=DKIM1 |
| DMARC | _dmarc.example.com | v=DMARC1 |
The DKIM name is built from the signature itself: a signature with
d=example.com and s=foo.bar sends the verifier to
foo.bar._domainkey.example.com. That is why each vendor gives you a
different selector, and why several vendors can sign for one domain without colliding.
What to do this week
If you send any mail at all, confirm you have SPF or DKIM in place, because that is
the baseline requirement for every sender regardless of volume. If you are anywhere near
5,000 messages a day, publish a p=none DMARC record with a reporting
address today and start reading the reports. The record costs nothing, satisfies the
bulk requirement immediately, and buys you the visibility you will need before
enforcing.
Frequently asked questions
Do I need both SPF and DKIM for DMARC to pass?
No. DMARC is satisfied when at least one supported mechanism produces a pass on an
aligned identifier. Configuring both is still worth doing, because DKIM tends to survive
forwarding where SPF does not.
Is p=none pointless?
No. It publishes no enforcement, but it turns on aggregate reporting, and it satisfies
Google's DMARC requirement for bulk senders. It is the observation stage, not a
permanent destination.
Can I list every vendor in one SPF record?
Only up to the limit. The specification caps DNS-querying terms at 10 per evaluation and
requires a permerror beyond that, and nested vendor includes count toward
your total. Audit the expanded count, not just the terms you typed.
What key size should DKIM use?
The specification requires signers to use RSA keys of at least 1024 bits for long-lived
keys. Very large keys can be awkward in DNS because of response size limits, so 2048
bits is the common practical choice.
Sources
RFC 7208, Sender Policy Framework · RFC 6376, DomainKeys Identified Mail · RFC 7489, DMARC · Google, Email sender guidelines. Requirement thresholds are Google's as published for senders to Gmail accounts, effective 1 February 2024.
More in this section Technology →