DMARC policy: protect your domain from spoofing

What DMARC actually does

DMARC — Domain-based Message Authentication, Reporting & Conformance — sits on top of SPF and DKIM. It does three things:

1. Alignment. Requires that either SPF or DKIM not only passes, but is on a domain that aligns with the visible From: header. This is what stops a spammer from sending mail with a valid SPF record on a throwaway domain while showing your brand in the From.
2. Policy. Tells receivers what to do when alignment fails: do nothing (none), put the message in spam (quarantine), or reject it outright (reject).
3. Reporting. Asks receivers to send you aggregate reports of authentication results for messages claiming to be from your domain — so you can see who’s sending as you, legitimate or not.

Without DMARC, an attacker can spoof your domain freely (especially if you only have SPF, which doesn’t survive forwarding). With DMARC at p=reject, mailbox providers actively block forged mail before it lands.

A real DMARC record

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; aspf=s; adkim=s; pct=100"

Tag by tag:

• v=DMARC1 — version, always.
• p=reject — the policy. One of none, quarantine, reject.
• rua=mailto:... — aggregate report address. Daily XML summaries of authentication results across all your traffic.
• ruf=mailto:... — failure report address. Per-message failure reports. Often turned off due to privacy concerns; many providers don’t send these anymore.
• fo=1 — when to generate failure reports. 1 = whenever SPF or DKIM fails.
• aspf=s / adkim=s — alignment mode for SPF / DKIM. s (strict) requires exact domain match; r (relaxed, the default) allows organizational-domain match.
• pct=100 — percent of failing mail to apply the policy to. Useful for staged rollout (pct=10 during testing).

The three policies and when to use each

p=none — observation mode. Receivers do nothing, but you still get aggregate reports. This is the right place to start: deploy p=none first, watch the reports for a couple of weeks, find every legitimate sender that isn’t authenticating correctly, and fix them.

p=quarantine — failing mail goes to spam. Use this once you’re confident your aggregate reports show 95%+ alignment on legitimate traffic. It’s the safe middle ground.

p=reject — failing mail is bounced. This is what Gmail/Yahoo/Microsoft expect from bulk senders in 2026. Get to reject as soon as your legitimate mail is consistently aligning. Anything failing alignment at this point is almost certainly spoofing or a misconfigured sender.

The “I sent it from myself but it failed DMARC” trap

This happens to nearly everyone. Common causes:

• An ESP signing with its own domain. If d=mailchimp.com but From: [email protected], DKIM passed but didn’t align — DMARC fails. Fix: configure DKIM-for-your-domain in the ESP.
• SPF on the wrong domain. SPF is evaluated against the envelope MAIL FROM. If your ESP uses its own bounce domain (bounces.mailchimp.com), SPF passed on that domain, not on yours. DKIM alignment is the rescue here.
• Discussion lists. Mailing lists rewrite the From: to be the list address. The original DKIM signature usually survives, but it no longer aligns with the rewritten From, so DMARC fails. ARC was designed to fix this — but until ARC is universal, expect grumpy list owners if you go straight to p=reject without configuring exceptions.

How to read DMARC aggregate reports

The XML is tedious to eyeball. Use a service — there are free tiers from DMARCian, Postmark, Valimail, and others — or run a small parser yourself. What you’re looking for:

• Volume by source IP. Anything you don’t recognize is either an unknown legitimate sender or a spoofer.
• SPF and DKIM pass rates per source. A source with both at 100% is happily aligned. A source with both at 0% is either spoofed or misconfigured.
• Alignment results. Pass rates that are lower than the SPF/DKIM pass rates mean alignment is the problem, not the authentication itself.

A safe DMARC rollout plan

1. Publish p=none with rua= only. Wait two weeks.
2. Audit the aggregate reports. Identify every legitimate sender. Fix any SPF or DKIM gaps you find. Stop using any sender that can’t be authenticated.
3. Move to p=quarantine with pct=10. Wait one week. Watch reports.
4. Increase pct= over a few weeks until you reach pct=100 and remain comfortable.
5. Move to p=reject when you’re confident. This is the destination, not the starting point.

Why p=reject is worth the effort

p=none does nothing to stop spoofing — it’s a monitoring stance. p=quarantine puts spoofed mail in spam, where curious recipients might still open it. Only p=reject actually stops mail claiming to be from you from reaching mailboxes when it shouldn’t be there. For brand protection, regulatory compliance, and the new Gmail/Yahoo bulk sender requirements, p=reject is the bar.

How Email Health Pro grades DMARC

We resolve your _dmarc record, parse every tag, evaluate alignment for both SPF and DKIM against the visible From:, and grade the strength of your policy. We flag common misconfigurations — missing p=, mismatched alignment modes, oversized rua= list — and give you the exact text of the issue so you can fix it without guesswork.

Back to the authentication trio: SPF and DKIM are the building blocks. DMARC is what ties them to your visible brand.