Dmarc Policy Reject: Getting There Without Losing Mail

A dmarc policy reject record is the only DMARC setting that actually stops spoofed mail - quarantine demotes it, none merely observes it, reject makes it bounce before any inbox is involved. It is also the setting people postpone for years, because the same line that bounces a phisher bounces your own invoice run if an invoice sender was never aligned. The postponement usually rests on vagueness: not knowing how ready is ready, which streams still fail, or what happens in the worst case. This guide replaces the vagueness with numbers, the specific last-mile work for third-party platforms, the honest accounting of mail that will always fail, and the rollback that makes the whole move low-drama.

This assumes you are already at p=none or p=quarantine with aggregate reports flowing; if not, that inventory stage comes first, no exceptions.

What a dmarc policy reject record changes on day one

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com instructs receivers to refuse, during the SMTP conversation, any message using your domain in the From line that lacks an aligned SPF or DKIM pass. Three populations get refused: spoofers (the point), any legitimate stream you failed to align (the risk), and a thin tail of legitimately-sent mail damaged in transit by forwarding (the trade-off you accept knowingly). Everything below is about emptying the second population and measuring the third before you flip.

Knowing you're ready: numbers, not vibes

Your aggregate reports - viewed through any DMARC report tool, since raw XML resists human reading - reduce to one readiness metric: the aligned pass rate of your legitimate volume, tracked over at least two quiet weeks at quarantine. Ready looks like this:

• 98-99%+ of total volume passes aligned. Not "most streams look fine" - a percentage, from the reports.
• Every sending IP block in the reports is identified. Each row is attributable to a named system: Workspace or 365, the newsletter platform, the CRM, the billing tool, the support desk. Unidentified rows are either spoofers (fine - reject exists for them) or a system you forgot (not fine - find it before it finds you).
• The residual failures have forwarding's signature. Forwarded mail typically shows SPF failing (the forwarder's server isn't in your record) while DKIM still passes - those messages pass DMARC and cost nothing. The genuinely doomed residue is mail whose DKIM also broke; see the tail section below.
• Two weeks at quarantine produced zero complaints. Quarantine is your dress rehearsal: anything wrongly demoted to spam gets reported by humans at zero bounce cost.

If any bullet fails, you are not late - you are mid-process. The calendar cost of finishing the checklist is days; the cost of skipping it is bounced production mail.

The last mile: third-party platforms

The streams that block most rollouts are external platforms, and each has the same two-lever fix. Lever one, DKIM alignment: complete the platform's "authenticate your domain" flow so its signatures carry d=yourdomain.com - usually two or three CNAME records. Lever two, SPF alignment: platforms send with their own bounce domain in the envelope, which un-aligns SPF; the fix is the platform's custom return path option (a CNAME like bounce.yourdomain.com), where offered.

You need one lever per platform, not both, and DKIM is the sturdier one - it survives the forwarding that breaks SPF. A platform that can do neither - no domain authentication at all - cannot coexist with reject; the choices are migrating that workload to a platform that can, or leaving it sending as a different (sub)domain with its own laxer policy. Choose deliberately; the reports will not let you forget it exists.

The irreducible tail: forwarding and mailing lists

Some legitimate mail will fail under reject forever, and pretending otherwise causes more anxiety than the truth. When a recipient auto-forwards their mail to another account, SPF breaks; if the forwarder preserves the body, DKIM survives and DMARC passes. The problem case is the older mailing-list manager or gateway that rewrites messages - adding footers, tagging subjects - which breaks DKIM too, leaving nothing aligned. Modern lists mitigate by rewriting the From to their own domain; large receivers also honor ARC (RFC 8617), which lets a trusted forwarder vouch for the original authentication.

Quantitatively, for a typical business domain, this tail is a fraction of one percent of volume, visible in your reports before you ever enforce. Read your own number, decide it is acceptable (it almost always is - the same tail exists for every reject-policy domain on the internet, including every bank's), and proceed. The alternative - staying spoofable to protect the last 0.3% - is a bad trade dressed as caution.

Flipping the switch, and the rollback

Mechanics matter for the day itself:

1. Lower the record's TTL to 300 seconds a day in advance, so any rollback propagates in minutes rather than hours.
2. Change p=quarantine to p=reject. Change nothing else; keep rua= forever. Skip pct= entirely - partial reject behaves inconsistently across receivers, and your quarantine weeks already were the gradual phase.
3. Watch reports daily for two weeks. You are looking for a legitimate stream newly failing - which, after the checklist above, means a system that started sending after your inventory.
4. Rollback, if ever needed, is one word: back to quarantine, live within the TTL. Misconfigured streams degrade from bouncing to spam-foldering while you fix alignment, then you return to reject. Senders whose mail bounced know it bounced - SMTP rejection is loud by design - so resends after the fix are a conversation, not data loss.

Life at reject

The policy is a commitment, not a completion. Keep reading reports monthly: the recurring failure mode at mature domains is the new tool - marketing signs a contract, the tool sends its first campaign unaligned, and reject bounces the launch. The cure is procedural: domain authentication becomes step one of onboarding any tool that sends email, before the first real send. Pair the apex policy with subdomain hygiene - sp=reject unless a subdomain deliberately runs its own record - and park your non-sending domains at reject too. From there, the record just sits: one line of DNS, doing the only thing in email security that makes an entire fraud class bounce.

Frequently asked questions

Will a DMARC reject policy lose legitimate email?

Aligned streams lose nothing. The irreducible loss is rewritten-forward mail - typically a fraction of one percent, measurable in your aggregate reports before you enforce - since intact forwards still pass via DKIM and large receivers honor ARC.

How long should I run quarantine before moving to reject?

Two quiet weeks is a sound bar: 98-99%+ aligned pass rate, every sending IP identified, residual failures showing forwarding's signature, and zero human complaints about mail in spam.

What if something breaks after switching to reject?

Roll back the one word to quarantine - live within your TTL, minutes if you lowered it to 300 beforehand - fix the stream's alignment, then return. Bounced senders see their bounce, so nothing disappears silently.

Do I still need DMARC reports after reaching reject?

Yes, permanently. The classic post-reject failure is a newly onboarded tool sending unaligned mail straight into bounces - monthly report review plus domain authentication as onboarding step one prevents it.