DMARC, explained without the jargon

DMARC has the worst documentation-to-importance ratio of any email standard. Let's fix that.

What DMARC actually does

DMARC sits on top of SPF and DKIM. SPF tells the receiver which servers are allowed to send mail for your domain. DKIM cryptographically signs the message so its body and key headers cannot be tampered with mid-flight. DMARC tells the receiver what to do when SPF or DKIM fails, and asks them to send you reports about it.

The record itself

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@yourdomain.com; pct=100; adkim=r; aspf=r"

The tags that matter

p= (policy)

p=none — observe only. Receivers ignore the policy and only send reports. Useful while you're auditing what really sends from your domain.
p=quarantine — receivers are told to send failing mail to spam. The sweet spot for most senders.
p=reject — receivers are told to drop failing mail entirely. Banks and brands at risk of impersonation should aim here. Not appropriate while you still have legacy senders you haven't audited yet.

rua= and ruf=

rua is the address that receives aggregate reports (daily summaries of pass/fail rates by IP). ruf is the address that receives forensic reports (per-message failure dumps — most providers don't actually send these for privacy reasons). Always set rua. ruf is optional.

adkim= and aspf= (alignment)

r = relaxed. The DKIM signing domain or SPF return-path domain just needs to be a subdomain of your From domain. r is the default and what most people want.

s = strict. The signing domain has to be an exact match to your From domain. Use this only when you fully control all of your sending paths.

pct= (rollout percentage)

Apply the policy to N% of failing mail. Useful for staging a rollout from p=none to p=quarantine — start at pct=10, watch the reports, climb to pct=50, then pct=100.

The classic mistakes

Setting p=reject too early

Every cold email tool, every newsletter ESP, every transactional service you forget you signed up for is suddenly catastrophically broken. Never set reject without first runningp=none for a few weeks and reading the rua reports.

Forgetting to publish DKIM keys for every sender

If you send from Google Workspace AND Postmark AND Mailchimp, every one of them needs its own DKIM CNAME or TXT record published under your domain. Otherwise mail from that sender will fail DMARC alignment.

SPF with too many includes

SPF caps at 10 DNS lookups per RFC 7208 §4.6.4. Once you exceed that, the entire SPF check fails permanently. Five include directives is already getting risky. Use SPF flattening services or trim the unused senders out of your record.

Treating DMARC as set-and-forget

Read the rua reports. They will tell you exactly which IPs are sending unsigned mail in your name. That's how you discover the rogue marketing tool someone bought 18 months ago.

Practical rollout

Publish p=none with a working rua address. Wait a week.
Read the reports. Identify any sender that's failing alignment.
Either fix the sender's DKIM/SPF, or remove the sender if it's unauthorized.
Move to p=quarantine; pct=10. Wait a week.
Climb the percentage. Once at pct=100 with stable pass rates, consider p=reject.

DMARC is not magic. It's a feedback loop. Get the loop running and your inbox placement almost takes care of itself.