Diagnostic suite Β· live

DMARC in plain English

How DMARC ties SPF and DKIM together, and the safe rollout from p=none to p=reject.

Illustration of three DMARC policy gates β€” none, quarantine, and reject β€” with an envelope flowing through

DMARC in plain English

How DMARC ties SPF and DKIM together, and the safe rollout from p=none to p=reject.

11 min read

DMARC β€” Domain-based Message Authentication, Reporting and Conformance β€” is the third leg of the email-auth stool. It ties SPF and DKIM together, tells receiving mail servers what to do when both fail, and, crucially, gives you visibility: receivers send aggregate reports back to you so you can finally see who is sending mail as your domain. In 2024 Google and Yahoo effectively made DMARC mandatory for any sender pushing more than 5,000 messages per day to their users. In 2026 nobody serious operates without it.

What DMARC actually adds

SPF authenticates the envelope sender. DKIM authenticates the signing domain. Neither one checks the From: header β€” the address your users actually see. That gap is what phishers exploit: they send from an IP with valid SPF for their own domain, or with a valid DKIM signature for their own domain, while spoofing From: security@yourbank.com. SPF passes, DKIM passes, the message lands in the inbox, and your customer wires their savings to a criminal.

DMARC closes that gap by demanding alignment: the visible From: domain must match the domain that passed SPF, the domain that passed DKIM, or both. If neither aligns, DMARC's p= policy tells the receiver what to do.

A minimum viable DMARC record

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r"
  • v=DMARC1 β€” version tag. Always this.
  • p=none β€” monitoring only. Nothing gets blocked, but you get reports.
  • rua=mailto:... β€” where daily aggregate reports go.
  • fo=1 β€” send failure samples when SPF or DKIM fails (default is only when both fail).
  • adkim=r / aspf=r β€” relaxed alignment: matching organizational domain is enough. s = strict, exact domain match required.

The three policies, explained

  • p=none β€” "tell me, do nothing." Receivers still evaluate DMARC and send reports; failures are delivered normally. Use during discovery.
  • p=quarantine β€” receivers should put failing mail in spam. Ninety percent of the protective value with a fraction of the risk.
  • p=reject β€” receivers should refuse the message outright at SMTP time. This is the goal. When you're at p=reject, nobody in the world can send convincing phish from your domain.

The rollout playbook

  1. Week 0. Publish p=none with rua=. Sign up for a DMARC aggregator (Postmark, dmarcian, Valimail, Easy DMARC β€” several have free tiers under 10k msgs/day).
  2. Weeks 1-2. Read reports. Every legitimate sender should show SPF and/or DKIM passing and aligning. Fix any that don't: add missing SPF includes, enable DKIM on the ESP, add SPF for that one Zapier automation nobody remembered.
  3. Week 3. Move to p=quarantine; pct=25 β€” apply the policy to 25% of failing mail. If nothing catches fire, ramp to 50, 75, 100 over two weeks.
  4. Week 5. Move to p=reject; pct=100. Congratulations, your domain is now unspoofable in any meaningful sense.

Why alignment matters more than pass/fail

You'll see reports where SPF passed but did not align. That's a red flag: it usually means a marketing platform is sending with its own bounce domain in MAIL FROM. SPF says "yes, this IP is authorized for MailerCorp" β€” great for MailerCorp, useless for proving you sent it. Fix by asking the ESP to use a custom bounce domain like bounces.yourdomain.com, which puts your organizational domain back into the envelope sender.

Reading aggregate reports without going insane

Raw DMARC aggregate reports are XML files, one per reporting receiver per day, sent to your rua= address. A busy domain gets 50-200 per day. Reading them by hand is masochism. Use a processor. The good ones roll data up into "here are your senders, here's their SPF/DKIM/alignment pass rate, here are the sources you probably didn't know about." That last category is where DMARC pays for itself β€” you'll discover forgotten SaaS tools, shadow-IT scripts, and outright impersonators.

Common gotchas

  • Forwarders break SPF. When a user forwards mail from you to their Gmail, the sending IP is now their forwarder's, not yours. SPF fails. DKIM survives (if headers weren't modified) and saves alignment. This is why DKIM is the more resilient authentication method.
  • Mailing lists rewrite From:. Traditional lists change the From: to the list address, which breaks alignment on both SPF and DKIM. ARC (Authenticated Received Chain) exists to fix this. Modern list software supports it.
  • Subdomain policy. If you don't set sp=, subdomains inherit p=. Explicitly setting sp=reject on your org domain locks down any subdomain a spammer might invent.
  • External destinations. If your rua= address is at a different domain, that domain must publish a special your-domain.com._report._dmarc.other-domain.com record. Most aggregators handle this for you.

The value in one sentence

DMARC costs you a TXT record and thirty minutes of setup, gives you complete visibility into who is sending mail as you, and β€” once you reach p=reject β€” makes convincing phishing of your customers effectively impossible. There is no cheaper security win in email.

Related tools: DMARC Checker Β· DMARC Generator Β· SPF Checker Β· DKIM Checker Β· Email Header Analyzer

Frequently asked questions

No. Start at p=none with rua= aggregate reporting. Watch for two weeks. When 100% of legitimate mail passes SPF and DKIM with alignment, move to p=quarantine. Two more weeks of clean reports, then p=reject.