Email authentication: SPF, DKIM, and DMARC with alignment
How the three records fit together, why alignment is the part that actually stops spoofing, and a staged path to an enforcing DMARC policy without breaking legitimate mail.
What to implement
Publish SPF and DKIM for every sending source, then deploy DMARC starting at p=none with reporting, use the aggregate reports to find and fix all legitimate senders, and ramp to p=quarantine and finally p=reject with alignment. Alignment is the mechanism that makes DMARC stop spoofing — SPF or DKIM passing is not enough on its own.
Email was designed with no sender authentication, which is why spoofing your domain is trivial by default. SPF, DKIM, and DMARC are the layered fix. The common failure is deploying SPF and DKIM but never reaching an enforcing DMARC policy — so spoofed mail is authenticated-looking but nothing rejects it.
What each record does
- **SPF (Sender Policy Framework)** — a DNS TXT record listing which IPs/hosts may send mail for your domain. The receiver checks the envelope-from (Return-Path) domain against it. SPF breaks on forwarding and is limited to 10 DNS lookups.
- **DKIM (DomainKeys Identified Mail)** — the sending server cryptographically signs the message with a private key; the public key is published in DNS. The receiver verifies the signature, proving the message wasn't altered and came from an authorized signer. DKIM survives forwarding.
- **DMARC (Domain-based Message Authentication, Reporting & Conformance)** — ties SPF and DKIM to the visible From: domain, tells receivers what to do when checks fail (none / quarantine / reject), and sends you reports.
Alignment is the whole point
DMARC passes only when SPF or DKIM passes AND the authenticated domain aligns with the visible From: domain. A message can pass SPF for the attacker's own domain while spoofing your From: — SPF alone wouldn't catch it. DMARC alignment closes that gap. Prefer DKIM alignment (relaxed) as the durable signal, since SPF alignment breaks on forwarding.
Staged rollout to enforcement
The risk in DMARC is blocking your own legitimate mail (marketing platforms, ticketing systems, payroll, third-party senders). The staged approach removes that risk by finding every sender before you enforce.
- **1. Inventory senders.** List every system that sends as your domain — ESPs, SaaS apps, on-prem relays, help desks.
- **2. Publish SPF and DKIM for each.** Get every legitimate source authenticated and aligned. Use SPF include mechanisms carefully to stay under the 10-lookup limit.
- **3. Deploy DMARC at p=none with rua reporting.** This monitors without affecting delivery. Point aggregate reports at a mailbox or DMARC analytics service.
- **4. Read the reports.** Find sources that fail alignment and fix them (add DKIM, correct SPF, or migrate). Do not proceed until legitimate mail is clean.
- **5. Move to p=quarantine**, optionally with a pct ramp, and monitor.
- **6. Move to p=reject.** Spoofed mail is now rejected outright. This is the goal state.
Don't forget the adjacent controls
- Set an enforcing DMARC policy on **parked/non-sending domains** too (p=reject, with SPF `-all` and an empty DKIM) so they can't be abused.
- Consider **BIMI** once at p=quarantine/reject to display a verified brand logo — a user-visible authenticity signal.
- Add **MTA-STS and TLS-RPT** to enforce encrypted transport and get failure reporting.
- Watch the **SPF 10-DNS-lookup limit**; flattening or consolidating includes avoids silent SPF failures.
Jumping straight to p=reject
Enforcing before you've inventoried senders from the p=none reports will silently drop legitimate business mail — invoices, password resets, notifications. Always spend real time at p=none/quarantine reading aggregate reports first. Rushing enforcement is the fastest way to get DMARC rolled back org-wide.
Verify the end state
Confirm the DMARC record is p=reject with rua reporting, that all known legitimate senders pass with alignment in recent aggregate reports, that parked domains carry a reject policy, and that DKIM keys are rotated periodically (and use at least 2048-bit keys). Re-check after onboarding any new SaaS sender.