DMARC p=reject Is a Request, Not a Command: Why Receiver Compliance Is Voluntary

In early 2025, we were monitoring delivery for a client domain configured at p=reject to a single high-volume legitimate sender, with extremely high observed spoofing volume from external attackers. The client's three-character .com resembled a well-known global brand, which made it a prime impersonation target. The DMARC enforcement was doing its job — major mailbox providers were rejecting the spoofed traffic — and we were watching aggregate reports to confirm.

Then a 552 5.2.2 bounce came back from So-Net, Japan's third-largest ISP, owned by Sony. The bounce wasn't a DMARC rejection. It was Quota exceeded — the recipient's mailbox was full. Meaning So-Net had accepted the spoofed message at the SMTP layer, despite an explicit p=reject policy from the sender domain, and only bounced it because the destination mailbox had no room for it.

That single bounce illustrated a property of DMARC that gets understated in most documentation: the policy is a request to the receiver, not a technical enforcement mechanism. Whether the receiver actually rejects failing mail is the receiver's choice. Most major receivers honor p=reject. Some don't. And the ones that don't, by definition, won't appear in your aggregate reports as rejections — they'll appear as deliveries, or won't appear at all if they don't generate reports.

This post is about what p=reject actually does, what it doesn't do, and how to think about your real attack surface as a sender.

How the Spec Works

DMARC defines three policy modes — p=none, p=quarantine, and p=reject — and instructs receiving mail servers on what action to take when a message fails authentication. The relevant language from RFC 7489 is intentionally permissive about receiver behavior:

"Senders can request, via a DMARC policy statement in the DNS, particular actions to be taken when authentication of messages claiming to originate from their domains fails. However, mail receivers are not required to honor those requests."

This isn't an oversight. It's a deliberate design choice. DMARC operates across the entire global email system, with receivers ranging from major hyperscale providers to small regional ISPs to corporate mail servers running self-hosted software a decade out of date. A specification that required receivers to honor sender policy would have prevented adoption — receivers couldn't comply without rebuilding their internal mail handling. So the spec made receiver action advisory.

The result is that DMARC enforcement is a probabilistic protection, not a deterministic one. The probability is high — the major providers that handle the bulk of global email volume (Gmail, Microsoft, Yahoo, Apple, and the large enterprise gateways) generally honor p=reject. The probability is not 1. And the receivers that don't honor it are not evenly distributed: they cluster in specific geographies, specific provider categories, and specific configurations.

So-Net and the Japanese ISP Pattern

So-Net's behavior in our observed case was straightforward acceptance: the message failed authentication, the policy was p=reject, the message was accepted at SMTP, and the only reason for the eventual bounce was that the recipient's quota was full. Other observed Japanese ISPs (notably some smaller regional providers) exhibit similar patterns.

This isn't a Sony or So-Net-specific problem. It's a regional pattern in Japan, where DMARC enforcement adoption among receivers has historically lagged the rest of the developed world. The Japan-specific DMARC adoption picture has been improving — pressure from M3AAWG and from major Japanese banks has pushed several large receivers toward enforcement — but pockets of non-compliance remain, and they're a real surface for targeted phishing campaigns aimed at Japanese recipients.

The structural reason is that Japanese consumer ISPs historically built mail systems on different assumptions than Western ISPs. Japanese carriers prioritized delivery over filtering, with the result that authentication failures historically resulted in spam-folder placement rather than rejection. Updating these systems to do DMARC-aware rejection requires architectural changes that are slow to roll out across a regulated telecom industry.

For senders with no Japanese customer base, this is academic. For senders with Japanese customers or Japanese-speaking employees, it's a real consideration. Spoofed mail addressed to recipients on non-compliant providers will arrive, regardless of how strictly enforced your DMARC policy is.

Beyond Geography: Other Sources of Non-Compliance

Geographic non-compliance is the easiest pattern to describe. But there are several other categories of receivers that materially weaken DMARC's protection:

Forwarders. Email forwarding (not aliases — forwarding, where mail is received by one server and re-sent to a final destination) breaks SPF alignment, often breaks DKIM alignment if any headers are modified, and therefore breaks DMARC. The receiver at the final destination sees an authentication failure for legitimate mail. The right behavior is to evaluate ARC (Authenticated Received Chain) headers to recover the authentication state from upstream. Many receivers don't implement ARC, or implement it inconsistently. The practical effect is that legitimate forwarded mail bounces under p=reject, even though the original sender properly authenticated it.

Mailing list operators. Lists that preserve the original From: address (rather than rewriting to the list address) create the same alignment-failure pattern as forwarding. Mailman, the older configuration of Google Groups, and a substantial portion of corporate distribution lists fall into this category. Subscribers on receiver platforms that strictly honor p=reject won't receive list mail. Subscribers on receivers that are more permissive will.

Internal mail handlers. This is the Microsoft 365 Groups case we've covered separately. A receiver may honor DMARC for inbound external mail and exempt internal routing paths from the same enforcement. The exemption isn't visible from the outside and doesn't generate DMARC reports.

Corporate mail gateways. Enterprise mail security products (Proofpoint, Mimecast, Cisco IronPort, Barracuda, and others) have their own DMARC enforcement modes that operators configure separately from the underlying mail platform. A gateway can be configured to ignore DMARC entirely, to use the policy as a single input to a multi-factor scoring system, or to enforce it strictly. The enforcement varies by tenant, not by product.

Legacy receivers. Self-hosted mail servers running older software stacks may not have DMARC support at all. The volume here is small but non-zero, and it concentrates in specific industries (legal, government, education) where mail infrastructure changes slowly.

What This Means for the Sender

The first implication is that p=reject is not a guarantee. It is a strong protection — strong enough to be the only realistic protection available — but not absolute. A determined attacker targeting recipients on known-non-compliant receivers can bypass p=reject by simply choosing the right targets.

The second implication is that you should still publish p=reject. The protection where it works (the major providers handling 90%+ of global volume) is overwhelmingly worth having. The protection where it doesn't work isn't a reason to lower the policy — it's a reason to layer additional defenses.

The third implication is that aggregate reports don't tell you the whole story. A receiver that ignores DMARC and accepts failing mail will not appear in your reports as a rejection. It may not appear in your reports at all, if the receiver doesn't generate aggregate reports (which several non-compliant receivers don't). The mail that succeeded against your policy at a non-compliant receiver is invisible to you.

The fourth implication is that brand protection requires more than DMARC. For high-value brand impersonation targets — financial services, large consumer brands, government entities — the additional defenses include:

• BIMI (Brand Indicators for Message Identification) to make verified logos visible in supporting mailbox clients, raising the cost of impersonation
• Active monitoring for lookalike domains (typosquats, IDN homoglyphs, character substitution) registered by potential attackers
• Direct relationships with major mailbox providers for sender-specific phishing reporting channels
• Customer education on what legitimate mail from the brand looks like, so impersonation that does land is recognizable

None of these replace DMARC. They acknowledge that DMARC, even at full enforcement, is one layer in a defense and not the entire defense.

The Counterfactual

It's worth being clear about what would happen without p=reject. Without DMARC, every spoofed message would be evaluated by every receiver on its own internal scoring system, which would heavily weight signals like sender reputation, content patterns, and recipient engagement. Some spoofed mail would land in inbox. Most would land in spam. There would be no consistent, sender-controllable policy.

With p=none, the receivers still evaluate spoofed mail on their internal scoring systems, but the sender now knows it's happening (via aggregate reports) without doing anything to stop it. The asymmetry of the situation — attacker free to spoof, defender able to watch — is what makes p=none so dangerous as a long-term state.

With p=quarantine and p=reject, the sender's explicit instruction is added to the receiver's internal logic. For the receivers that honor it, this is a step change in protection. For the receivers that don't, the practical outcome is the same as p=none. Either way, the move to enforcement is dominant — there's no scenario where staying at p=none is safer than moving to enforcement, even accounting for receiver non-compliance.

What to Do

If you operate a domain with high spoofing risk — particularly a globally-recognized brand or a financial services company — assume the following:

1. p=reject is doing its job at all major receivers. Don't lower it.
2. Recipients on non-compliant receivers (Japanese ISPs, some smaller regional providers, legacy corporate mail) will still receive spoofed mail addressed to them. You can't fix this from your side.
3. Aggregate reports underrepresent your spoofing volume because non-compliant receivers may not generate them. Use the absence as a signal to ask what you're not seeing.
4. Brand protection requires defenses beyond DMARC. Treat DMARC as the floor of your email security posture, not the ceiling.

If you operate a domain that doesn't face this kind of targeting — most small and mid-market organizations — the practical advice is simpler: get to p=reject, monitor your reports, and accept the residual risk. The realistic alternative is p=none, which doesn't protect against anyone.

The receiver-side variability isn't a reason to avoid enforcement. It's a reason to understand that what you're getting is a probabilistic improvement, not an absolute guarantee. Knowing the limits is part of operating the protection correctly.

---

Written by the team at SH Consulting. If you want help understanding your real spoofing surface beyond what aggregate reports show — including the receivers your reports don't cover — book a call.