SPF, DKIM and DMARC: the complete guide and deploy order

SPF, DKIM and DMARC are three DNS-based standards that together stop other people sending email as your domain. They are constantly mentioned in the same breath because none of them is sufficient alone: SPF says which servers may send for you, DKIM proves a message wasn't forged or altered, and DMARC ties both back to the visible From address and tells receivers what to do when something doesn't add up. This guide explains how the three fit together, the order you should deploy them in, and a checklist to confirm you've done it right.

How the three fit together

Each standard answers a different question:

The concept that binds them is alignment. SPF and DKIM each validate a domain, but that domain isn't necessarily the one your recipients see in the From field. DMARC closes the gap: a message passes DMARC only if SPF or DKIM passes and the validated domain aligns with the From domain. Either one is enough — which is deliberate, because SPF usually breaks when mail is forwarded while DKIM survives it. Belt and braces.

A minimal, complete setup looks like this across three DNS locations:

; SPF — one TXT at the apex
example.com.                 TXT  "v=spf1 include:_spf.google.com ~all"

; DKIM — public key under a selector
mail2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; DMARC — policy at the fixed _dmarc location
_dmarc.example.com.          TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

The order to deploy them

Order matters, because DMARC enforcement is only safe once SPF and DKIM are correct. Deploying DMARC first, or at enforcement, breaks your own mail.

1. SPF first. Inventory every system that sends as your domain, then publish a single SPF record covering them. Watch the 10-DNS-lookup limit — nested includes count recursively and tip records into permerror. Use ~all.
2. DKIM next. Enable signing on every sending platform and publish each provider's public key (usually via the CNAME they give you). Confirm each selector resolves and verifies. Use 2048-bit keys.
3. DMARC last, in stages. Start at p=none with a rua= address — monitoring only. Read the reports, fix every legitimate source that isn't aligned, then move to p=quarantine with a rising pct, and finally p=reject. Never jump straight to enforcement.

The work is mostly in step 3's reporting phase: the reports surface the forgotten CRM, the invoicing tool, the printer relay — every system you didn't know was sending as you.

Alignment, the part people miss

A common trap is celebrating "SPF passed" while DMARC still fails. SPF can pass for the return-path domain (often your ESP's) while the From address is your domain — no alignment, no DMARC pass. Strict vs relaxed alignment (aspf / adkim tags) controls whether an exact match or an organisational-domain match is required. Relaxed is the sensible default for most setups; strict is for the security-conscious who control all their subdomains.

The checklist

Before you call email authentication "done", confirm:

• Exactly one SPF record at the apex, starting v=spf1. (Two = permerror.)
• SPF lookup count under 10, including nested includes; no deprecated ptr.
• SPF on every sending subdomain, not just the apex — it doesn't cascade.
• DKIM signing enabled on every sending platform, each selector resolving and verifying, keys 2048-bit.
• DKIM keys delegated by CNAME where the provider rotates for you (not pasted as static TXT).
• A DMARC record at _dmarc, with a rua= address that someone reads.
• DMARC policy at p=reject (or at minimum p=quarantine) once reports are clean.
• sp=reject on parked or non-sending subdomains.
• Aggregate reports show no unaligned legitimate sources.
• All of the above is monitored, not just checked once.

That last point is the one that catches teams out. Authentication that's correct today drifts: providers re-IP, includes pile up, selectors get tidied away in a migration, a fat-fingered zone edit drops a record. Any of those can turn p=reject from protection into a silent outage.

Check it, then keep checking it

For a fast first pass against the checklist above, run your domain through the free email auth audit — it gives you a one-off snapshot of your SPF, DKIM and DMARC records and flags the obvious problems. For the deeper picture of how these records interact, see the email DNS security docs and the broader security docs.

The audit is a snapshot; staying secure is continuous. DomainOps monitors your SPF, DKIM and DMARC records around the clock and alerts you the moment one changes or breaks. To be clear about scope: it does not send your email or manage your DNS zone — it watches your authentication posture so drift gets caught before it becomes a deliverability incident. When you're ready, start monitoring your domains.