DMARC p=reject is blocking legitimate mail — how to fix it

Publishing p=reject is the right destination for DMARC — it's what actually stops spoofing of your domain. But flip it on before every legitimate source is aligned, and those sources start bouncing. The good news: this is a precise, fixable problem, not a reputation slump. You know exactly which mail is affected and why, the reports name the culprits, and the repair is mechanical — align each source and the rejections stop while the protection stays on.

It's an alignment problem

DMARC passes when the domain authenticated by SPF or DKIM aligns with your visible From domain. A source can even pass SPF and still fail DMARC if the authenticated domain is the provider's, not yours. Under p=reject, anything unaligned is rejected — which is exactly why a forgotten or third-party sender suddenly fails.

What p=reject actually does

A crucial point that calms a lot of panic: the policy tag only applies to mail that fails DMARC — mail where both SPF alignment and DKIM alignment have failed. It does nothing to mail that already passes. So p=reject didn’t “break” your good senders; it exposed the ones that were never aligned in the first place and were only getting through because nothing was enforcing the rule. The mail that’s bouncing was failing authentication all along — you just couldn’t see it until enforcement made it visible.

One nuance worth knowing: receivers apply your policy on a best-effort basis. The DMARC standard asks them to honour it, but they can use local judgement and override — so a single failing message showing up somewhere isn’t always your policy at work; it can be a forwarding path, an enterprise quarantine workflow, or a stream that didn’t fail the way it first looked. Read the aggregate reports before drawing conclusions from one bounce.

Immediate triage without surrendering protection

If legitimate mail is bouncing right now and you need to stop the bleeding, there’s a controlled way to do it that doesn’t throw away your spoofing protection. Rather than dropping all the way back to p=none, use the pct tag or step down to p=quarantine as a temporary measure while you align sources — for example p=quarantine; pct=25 applies enforcement to only a quarter of failing mail, so legitimate senders you haven’t fixed yet are merely quarantined (or, outside the percentage, delivered) rather than rejected outright.

The distinction matters: this is a controlled ramp down to buy time, not a permanent retreat. The destination is still all your legitimate sources aligned under p=reject. Treat the softened policy as a temporary state with a deadline, fix the sources the reports name, and climb back up — don’t leave the domain parked at p=none where it protects nothing.

Find the failing sources

Your DMARC aggregate (RUA) reports list every source sending as your domain and whether each aligned on SPF and DKIM. That's your map: it names the senders to fix. If you're not collecting RUA reports yet, add a rua= address to your DMARC record first.

As you read them, sort every source into three buckets. Known and passing are your healthy senders — keep a documented list. Known but failing are almost always configuration: a legitimate platform that simply isn’t aligned yet, and the bulk of your fix work. Unknown sources deserve scrutiny — some are harmless noise, some are the spoofing p=reject is meant to stop, and you specifically do not want to “fix” those by authorising them. The goal is to align everything in the first two buckets and let the policy keep rejecting the third.

Align each legitimate source

For every sender you authorise, get it authenticated and aligned: add it to SPF and publish its DKIM key on your domain so messages are signed as your domain. Third-party platforms (CRMs, ESPs) all document this — follow their SPF include and DKIM steps. Once a source is DKIM-aligned to your domain, it sails through p=reject.

The common culprits

A handful of sources account for most “legitimate mail rejected” cases, and knowing them speeds the hunt. Third-party platforms — a CRM, an ESP, a help-desk, an invoicing tool — that send as your domain but were never set up to DKIM-sign as you, or whose SPF include you forgot, are the biggest group. Forgotten internal sources come next: an old application server, a monitoring box, a department’s mailer that nobody documented. Subdomains are a quiet one — a policy on the parent doesn’t cover them unless you set sp= or publish per-subdomain records.

A subtler trap is strict alignment. If your DMARC record sets aspf=s or adkim=s, the authenticated domain must match your From domain exactly — a subdomain won’t do. Plenty of legitimate senders sign with a subdomain (relaxed alignment accepts that), so strict mode can reject mail that would otherwise pass. Unless you specifically need exact-match alignment, the default relaxed mode is the right choice and avoids a whole category of self-inflicted rejections.

The right rollout: none → quarantine → reject

The reason this problem happens at all is almost always a skipped rollout — someone published p=reject on day one. Done properly, you never block legitimate mail by surprise, because you reach enforcement only after the reports are clean. The sequence is the same whether you run one domain or hundreds:

1. p=none with a rua= address — the audit phase. Collect reports and inventory every source. Don’t treat this as the destination, but don’t skip it either.
2. Fix and align every legitimate sender until your reports show consistent SPF or DKIM alignment across all of them — aim for around 98% of legitimate traffic passing before tightening.
3. p=quarantine with a pct ramp — enforce gradually rather than all at once.
4. p=reject — full enforcement, once the quarantine phase stays quiet.

A sensible pct ramp during the quarantine phase, holding a couple of weeks at each step while you watch the reports:

Step	Effect	Hold
pct=10	10% of failing mail enforced; rest treated as none	~2 weeks
pct=25	Quarter enforced; watch for newly-surfaced senders	~2–3 weeks
pct=50	Half enforced; most issues visible by now	~2–3 weeks
pct=75	Most enforced; confirm reports stay clean	~2–3 weeks
pct=100	Full quarantine, then advance to reject	remainder

Done at this pace, the full journey from first record to p=reject commonly takes nine to eighteen months, with roughly ninety days minimum at each phase. That sounds slow, but it’s why a careful rollout never produces the “p=reject is blocking my mail” emergency in the first place — and it’s also why only a minority of DMARC domains have reached full reject. Patience here is the feature, not the bug.

Forwarding and the limits of your control

Some failures aren’t yours to fix at the source. Forwarded mail and mailing lists routinely break alignment: SPF fails because the forwarding server’s IP isn’t in your record, and DKIM can fail if the list modifies the body. That mail genuinely fails DMARC, and p=reject will act on it — but the cause is the forwarder, not your configuration.

The mitigation is ARC, implemented by the forwarder, which preserves the original authentication result through the modification so a receiver can see the mail was legitimate before it was forwarded. You can enable ARC on lists and relays you operate; for a third party’s list you can’t, and you simply accept that some forwarded copies will fail — a deliberate trade-off, not a reason to weaken your policy for everyone else. Keep DKIM healthy so it survives forwarding wherever the body isn’t changed, since DKIM is what carries DMARC through a forward when SPF can’t.

Aligning a source: prefer DKIM

When you align a failing source, you have two routes — SPF and DKIM — and they aren’t equally durable. SPF alignment means adding the sender to your SPF record (or using a subdomain that does), which is quick but fragile: it breaks the moment the mail is forwarded, because the forwarding IP isn’t yours. DKIM alignment means the source signs messages with a key published on your domain, and it travels with the message — surviving forwarding as long as the body isn’t modified. For anything that matters, getting DKIM aligned is the more durable, forwarding-resistant fix.

In practice, every reputable third-party platform documents how to do both: an SPF include to add and a DKIM key (or CNAME) to publish on your domain, often under a subdomain they assign you. Do both where you can, but treat DKIM as the one that must work, since DMARC passes on either aligned mechanism and DKIM is the one that holds up through the messy real-world mail paths. Mind your SPF lookup budget while you’re adding includes, too — piling on third-party includes is a fast way to trip the ten-lookup limit and cause a different authentication failure entirely.

Keep monitoring after you reach reject

Reaching p=reject isn’t the finish line, because the set of things sending as your domain never stops changing. A new vendor gets onboarded, an existing one rotates its sending infrastructure, a team spins up a tool without telling IT — any of these can introduce a new unaligned source that your policy will dutifully reject. The only way to catch it before it becomes a “why is our invoicing email bouncing” fire drill is to keep reading your aggregate reports.

Leave rua= reporting on permanently and review it on a cadence — the same reports that guided your rollout are your early-warning system afterward. A new source showing up failing alignment is a prompt to align it (if it’s legitimate) or to investigate it (if it isn’t), and either way you want to know from a report rather than from an angry colleague whose mail vanished. DMARC enforcement is a state you maintain, not a switch you flip once.

Mistakes that turn this into a crisis

Four missteps cause most of the pain. Jumping straight to p=reject — publishing enforcement without an audit phase — is the root of nearly every “it blocked my mail” story, because you enforce against senders you never inventoried. Panic-rolling back to p=none at the first bounce throws away the protection instead of fixing the one unaligned source. Staying at p=none forever is the opposite error: monitoring with no enforcement gives you visibility into spoofing but zero defence against it.

The fourth is forgetting it’s ongoing — treating the day you reach reject as the end, then being surprised months later when a new vendor’s mail bounces. Each of these has the same antidote: a deliberate, monitored progression with reports running throughout. The teams that never hit this problem aren’t luckier or more technical — they simply refused to skip the boring middle steps, and let the aggregate reports tell them when it was safe to tighten.

The tags that control all this

It helps to see where each lever lives in the record itself, because the fix is usually a tag change away:

_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; sp=reject; pct=25;
    adkim=r; aspf=r; rua=mailto:[email protected]"

p= is the policy for the organisational domain; sp= sets a separate policy for subdomains (omit it and subdomains inherit p=, which is often not what people assume). pct= is the percentage of failing mail the policy acts on — your ramp control. adkim= and aspf= set alignment mode, r for relaxed (a subdomain match counts) or s for strict (exact match only); relaxed is the safer default. And rua= is where aggregate reports are sent — the single most important tag during a rollout, because without it you’re enforcing blind.

When legitimate mail is being rejected, the emergency adjustment is almost always one of these: soften p= to quarantine, dial pct= down, or loosen a stray aspf=s / adkim=s back to relaxed — each a temporary breather while you do the real work of aligning the source. Knowing which tag to reach for turns a panic into a one-line, reversible change.

The bottom line

If p=reject is rejecting legitimate mail, it didn’t break anything — it surfaced a sending source that was never aligned to your domain. The fix is to find that source in your aggregate reports and align its SPF and, more importantly, its DKIM to your From domain, not to weaken the policy and give up the spoofing protection you deployed it for. If you need breathing room, step down to p=quarantine or a pct ramp temporarily — with a deadline — then climb back to full enforcement.

Better still, avoid the emergency entirely by rolling out in order: p=none to audit, align every legitimate sender, p=quarantine with a percentage ramp, then p=reject — and keep the reports running afterward so new senders never catch you out. It’s a months-long discipline, not a weekend task, which is exactly why a careful rollout never produces this problem. If you’d rather have it done right, our DMARC deployment service takes a domain from monitoring to enforcement safely, and the Auto PMTA Configurator publishes aligned SPF, DKIM and DMARC for your own sending from the start so your primary stream is never the one that fails. The throughline is simple: p=reject isn’t blocking your mail to spite you — it’s enforcing a rule your senders were always supposed to meet, and the lasting fix is to make them meet it rather than to stop asking. Align the sources, keep the reports open, and enforcement quietly does the job you published it to do.