DMARC: Why SPF and DKIM Are Incomplete Without It

SPF and DKIM each verify one thing in isolation. DMARC supplies the policy that ties them together: when authentication fails, should the recipient deliver the mail, quarantine it, or discard it? And — the part that makes DMARC indispensable — it orders receivers to send you reports about every failure, including attempts to spoof your domain that you never knew about.

The recommended rollout

1. Start monitor-only: publish v=DMARC1; p=none; rua=mailto:dmarc@example.com. Nothing gets blocked; you just start receiving aggregate XML reports.
2. Read the reports for a few weeks. They reveal every service sending mail as your domain — including ones marketing forgot to mention, and any spoofing attempts.
3. Close the loop: add every legitimate source to SPF, and make sure each signs with DKIM whose d= aligns with your visible From: domain.
4. Tighten gradually: move to p=quarantine (with pct= to roll out gradually if you are nervous), then to p=reject once reports show a clean pass rate.

Why this is no longer optional

Without DMARC, an attacker can send convincing phishing mail with your domain in the From: header, and a failing SPF or DKIM check has no consequence — the receiver improvises. Gmail and Microsoft Outlook now require outbound bulk senders to publish DMARC, and inbound filters weight the policy heavily when deciding placement. A domain with SPF and DKIM but no DMARC record leaves the final decision to someone else’s defaults.

The practical tools are simple: dig +short TXT _dmarc.example.com shows the published policy, and the aggregate reports (rua) show reality. The WhoDNS email records tool validates your DMARC record syntax and flags the common mistakes — a typo in the tag name, a policy published at the wrong subdomain, or a p=none that has been “temporary” for two years.

🔗 Related tool: Check your DMARC and email records