Setting up email authentication, in the right order
Set up email authentication in this order: (1) inventory every system that sends as your domain; (2) enable aligned DKIM at each one; (3) publish a single SPF record inside the 10-lookup limit; (4) publish DMARC at p=none with a rua address; (5) read reports until every sender is accounted for; (6) move to quarantine, then reject. Starting at p=reject is how organisations reject their own invoices.
Why this order
Most guides list the three records and let you pick an order. The order is not arbitrary, and getting it wrong is how a DMARC rollout ends with the finance team's invoices being rejected.
- Inventory precedes everything. You cannot authorise senders you do not know about, and you will discover at least one you had forgotten. Enforcement is a deadline for a discovery process, so do the discovery first.
- DKIM before SPF. DKIM survives forwarding and mailing lists; SPF does not. Aligned DKIM alone is sufficient for DMARC to pass. If you only ever get one of the two right, make it DKIM.
p=nonebefore anything else. It is the only stage where a misconfiguration is free. Use it.
The records
# SPF — one TXT at the root. One. Not two. example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all" # DKIM — provider-specific; enable signing for YOUR domain, not theirs google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg…" # DMARC — note the _dmarc prefix. This is not a root TXT record. _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
~all, not -all, while you are still deploying.
-all (hard fail) tells receivers to reject unauthorised senders outright. If your
inventory is incomplete — and during deployment it is — that is a footgun. ~all
(soft fail) gives you the same DMARC behaviour with a gentler failure mode outside DMARC. Tighten
it after your reports are clean.
Verify each step
Run this after each DNS change. Propagation is usually minutes, not the mythical 48 hours.
Then automate it
DNS is not write-once. Someone will add an ESP, hit the lookup limit, and nobody will notice until mail bounces. Put the audit in CI, or monitor the domains continuously — see the API.
Frequently asked
What order should I set up SPF, DKIM and DMARC in?
Inventory your senders first, then DKIM, then SPF, then DMARC at p=none, then read reports, then raise enforcement. DKIM comes before SPF because it is the mechanism that survives forwarding and is sufficient on its own for DMARC to pass.
Can I just start at p=reject?
You can, and you should not. p=reject asks receivers to refuse any mail that fails DMARC — including your own, from the sender you forgot about. The point of starting at p=none with rua is to discover those senders while failures are still harmless.
How long does DMARC deployment take?
Weeks to a few months for most organisations, and the long pole is not DNS — it is waiting to observe a complete sending cycle. Systems that send once a quarter will not appear in your first week of reports, and those are precisely the ones that break when you enforce.
Related
- SPF vs DKIM vs DMARC — Three records, three different jobs.
- What p=none actually does — p=none asks receivers not to change message handling.
- Gmail bulk sender requirements — What Google requires once you cross its bulk threshold to personal Gmail accounts: authentication, alignment, DNS, TLS, spam rate and one-click unsubscribe.
- An SPF, DKIM and DMARC API — A JSON API for SPF, DKIM and DMARC over live DNS — correct 10-lookup counting, record flattening, and bulk auditing.
- Looking for an MXToolbox alternative? — MXToolbox is a good diagnostic site.
Automate this → — free tier, public pricing, API key emailed in about thirty seconds. No call with anyone.