Deepak Gupta

Roll Out DMARC to p=reject Without Breaking Mail

Email Security · practitioner · 9 min read · last reviewed 2026-08-31

Reaching p=reject takes six to eight weeks and one hard prerequisite: naming every system that sends as your domain. The staged rollout, the alignment rule people miss, and what breaks.

TL;DR

DMARC enforcement is an inventory project with a DNS edit at the end. The inventory is the work; the policy change is the last ten minutes.
p=none protects nothing. Its only value is the rua report stream, which is the sole complete inventory of your sending estate that exists anywhere.
Failures are invisible. A quarantined invoice does not bounce and a rejected password reset logs as delivered, so you find out weeks later from a customer.
Publish sp=quarantine and park-domain p=reject first. Both are near-zero risk and cover where spoofing actually concentrates.
Ramp p=quarantine through pct=25, 50, 100 before rejecting, then drop pct entirely. A record left at pct=25 delivers three quarters of spoofed mail and disqualifies you from BIMI.

Getting to p=reject without breaking legitimate mail takes six to eight weeks and has exactly one hard requirement: you must be able to name every system that sends as your domain before you turn enforcement on. The rollout is not a DNS edit. It is an inventory project with a DNS edit at the end.

Most teams know this and still get burned, because the inventory is never what they expected. The marketing platform is obvious. The billing provider's dunning emails, the applicant tracking system, the ten-year-old status page cron, and the regional sales director's personal SendGrid account are not.

What enforcement actually changes

DMARC publishes a policy telling receivers what to do with mail that fails authentication while claiming to be from your domain. Three values:

Policy	Receiver behavior	Spoofing stopped	Safe to publish blind
`p=none`	Deliver normally, send reports	None	Yes
`p=quarantine`	Route to spam	Most	No
`p=reject`	Refuse at SMTP	Yes	No

p=none is a monitoring mode. It protects nothing, because receivers act on it by doing exactly what they would have done anyway. Its only value is the rua report stream, and that value is enormous, because those reports are the only complete inventory of your sending estate you will ever get.

The dangerous property of enforcement is that failures are invisible to you. A quarantined invoice does not bounce. A rejected password reset generates an SMTP 550 the recipient never sees and your application logs as delivered. You find out when a customer complains three weeks later.

The alignment rule people miss

SPF and DKIM each check a different domain than the one your recipient reads. SPF checks the SMTP envelope sender. DKIM checks the d= tag in the signature. Neither looks at the visible From header on its own.

DMARC's contribution is requiring that at least one of them aligns with the From domain. This is the entire reason DMARC exists, and it is where most third-party sending platforms fail.

A vendor sending on your behalf with d=vendor-mail.com in the DKIM signature passes DKIM and fails DMARC. The mail is authenticated. It is just authenticated as the vendor. Every platform that offers "custom DKIM" or "branded sending domain" is selling you alignment, and you have to turn it on per platform.

Relaxed alignment (the default) allows an organizational-domain match, so mail.yourdomain.com aligns with yourdomain.com. Strict alignment requires an exact match. Stay relaxed unless you have a specific reason.

Step 1: Publish a monitoring record

Start here even if you never intend to enforce. The record costs nothing and the data is the whole project.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

Point rua at a parsing service, not a human mailbox. Aggregate reports are gzipped XML sent daily by every major receiver, and a mid-sized domain generates hundreds. Free parsers handle a single domain fine. Do not add ruf (forensic reports) to a shared inbox: those contain message content and most receivers do not send them anyway.

Step 2: Read reports until the list stops growing

Two to four weeks minimum. You are looking for one thing: every source IP sending as your domain, sorted into three buckets.

Legitimate and aligned. Nothing to do.
Legitimate and failing. The work. Each one needs SPF authorization, aligned DKIM signing, or both.
Not yours. Spoofing, forwarding, or a shadow-IT tool nobody told you about. Investigate before assuming malice; mailing lists and .forward rules break SPF constantly and are the most common source of scary-looking failures.

The list stops growing when a full week passes with no new legitimate source. Monthly and quarterly senders are why two weeks is a floor and not a target. If you bill annually, you have a sender that appears in reports once a year.

Step 3: Fix each failing sender

Work the bucket. Per platform, in preference order:

Enable aligned DKIM. Almost every serious sending platform supports signing with your domain. This is the durable fix, because DKIM signatures survive forwarding and SPF does not.
Add SPF authorization if DKIM is unavailable. Watch the lookup budget.
Move the sender onto a subdomain you control if the platform can only sign as itself.
Retire it. A surprising share of what shows up in reports is a tool nobody has used in two years and nobody will miss.

SPF has a hard ceiling of 10 DNS lookups per evaluation, and exceeding it returns permerror, which receivers treat as no SPF at all. Every include: costs at least one, and vendor includes nest. Count them before you add another. If you are near the ceiling, that is a signal to consolidate senders, not to buy a flattening service that hides the problem behind a cron job.

Step 4: Subdomain policy first

Add sp=quarantine while your organizational domain is still at p=none.

v=DMARC1; p=none; sp=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1

Subdomains are where spoofing concentrates and where you almost never have legitimate unaligned senders. This is enforcement with most of the benefit and nearly none of the risk, and it is the single most underused tag in the spec.

Publish v=DMARC1; p=reject; on every parked domain you own. A domain that sends no mail has no rollout risk at all.

Step 5: Quarantine, staged

Move the organizational domain to p=quarantine using pct to ramp:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

Hold at 25 for a week, then 50, then 100. Watch two things: the report stream for newly failing legitimate sources, and your support queue for "I never got the email" tickets. Quarantine is recoverable. A user can retrieve mail from spam. This is the last stage where a mistake is cheap.

Step 6: Reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Ramp pct the same way if you are cautious, though by this point quarantine has already surfaced anything broken. Drop pct entirely once you reach 100. A record parked at pct=25 leaves three quarters of spoofed mail delivered and disqualifies you from BIMI, which requires enforcement at full percentage.

Step 7: Keep reading the reports

The estate changes. Marketing buys a tool, someone spins up a transactional provider for a new feature, an acquisition brings its own stack. A domain at p=reject with nobody reading reports will eventually reject something that matters.

Review monthly. Treat any new source in the aggregate data as a ticket.

What breaks and how to tell

Symptom	Likely cause	Fix
Mail to one large receiver fails, others pass	SPF `permerror` from lookup overflow	Count includes, consolidate
Fails only when forwarded	SPF break on forwarding, no aligned DKIM	Enable DKIM signing at the source
Vendor mail passes DKIM, fails DMARC	Vendor signing with its own `d=`	Turn on custom or branded DKIM
Reports show your IPs failing intermittently	A second unmonitored MTA	Find it in the report source data
Everything passes but a receiver still spams you	Not a DMARC problem	Reputation, content, or list hygiene

Should you do it?

You send transactional or marketing mail at any volume

Yes, and treat the timeline as six to eight weeks rather than an afternoon. The inventory is the deliverable. Enforcement is the last ten minutes.

You are a small team with three sending services

Yes, and it will take you two weeks rather than eight. Publish p=none, read the reports, fix three things, ramp. Free tooling covers this entirely.

You own domains that send no mail

Publish p=reject on them today. There is no rollout, no inventory, and no risk. This is the cheapest security control available to you.

You have a sprawling estate and no owner

Do not start with a policy change. Start by finding someone who owns email authentication, because a p=reject record with no monitor is a future outage nobody will be able to diagnose.

Key takeaways

Aligned DKIM beats SPF authorization every time. Signatures survive forwarding; IP lists do not.
Every vendor offering custom DKIM or a branded sending domain is selling you DMARC alignment. You have to turn it on per platform, and nobody will tell you that you did not.
SPF's 10-lookup ceiling turns into permerror, which receivers treat as no SPF at all. Being near the limit is a signal to consolidate senders, not to buy a flattening service.
The two-week monitoring floor exists because of monthly and annual senders. If you bill yearly, you have a sending system that appears in reports once a year.
A p=reject record with nobody reading reports is a future outage nobody will be able to diagnose. Review monthly and treat every new source as a ticket.

Frequently asked questions

How long does DMARC enforcement take?: Six to eight weeks for a mid-sized sending estate, and about two weeks for a small team with three sending services. Most of that is the monitoring phase, where you read aggregate reports until a full week passes with no new legitimate sender.
Is p=none safe to publish?: Yes, entirely. It changes no receiver behavior and only opens the reporting channel. It is also the reason it protects nothing: attackers ignore it because receivers do.
What is DMARC alignment?: SPF validates the SMTP envelope sender and DKIM validates the signature's d= domain. Neither looks at the From header a recipient reads. DMARC requires that at least one of them match the From domain, which is the entire reason the standard exists.
Why does my mail fail DMARC when SPF and DKIM pass?: Almost always alignment. A platform sending on your behalf signs with its own domain, so DKIM passes as the vendor and fails DMARC for you. Enable the platform's custom or branded DKIM signing.
Should I use pct to ramp?: Yes at quarantine, and drop it once you reach 100. A record parked below pct=100 leaves the remainder of spoofed mail delivered and does not qualify as enforcement for BIMI.
What should I do with domains that send no mail?: Publish v=DMARC1; p=reject; on them today. There is no inventory, no rollout, and no risk, which makes it the cheapest email security control available.