Introduction
Now that DMARC has been formalized as a Proposed Standard in RFC 9989, it is tempting to read the moment as a green light: the standard is mature, enforcement is all-or-nothing, so move every client to p=reject and be done. That impulse is understandable and, applied bluntly, wrong. Reject remains the strongest DMARC policy and the correct destination for almost every domain, but the messy realities that always complicated enforcement — forwarding, mailing lists and mail gateways — did not disappear when the RFCs were published. DMARCbis changed the tags; it did not change the internet's habit of modifying and relaying mail in ways that break authentication.
This article is for MSPs deciding when and how to move client domains to enforcement under the new standard. It explains why reject is still the goal, what still gets in the way of a clean result, where ARC genuinely helps and where it does not, and how the removal of the pct tag reshapes the safe rollout into a disciplined, evidence-led sequence. It complements pct is going away and the DMARC for MSPs pillar.
Reject is the goal, not the starting line
There is no ambiguity about the destination. p=reject is the only policy that actually stops a spoofed message from reaching the inbox; p=quarantine diverts it to junk, and p=none does nothing but observe. A domain that carries real risk of impersonation — which is most domains — is only fully protected at reject. Nothing in this article argues against that. The argument is about sequencing: reject is where a domain should end up, not where it should begin, and the discipline of getting there safely is the whole value an MSP provides. The failure mode to avoid is treating a mature standard as a reason to skip the work that makes enforcement safe.
What still gets in the way of a clean pass
DMARC passes when a message shows an aligned SPF or an aligned DKIM result. The complications all come from situations where legitimate mail loses that aligned pass in transit. Three are worth naming, because they account for the overwhelming majority of "but this is real mail" surprises during a rollout.
Forwarding
When a recipient auto-forwards mail, the forwarding server relays the message from its own IP address. SPF, which authorizes IPs for the original domain, breaks immediately because the forwarder is not an authorized sender for that domain. DKIM can survive forwarding if the signed content is untouched, which is exactly why DKIM alignment matters so much under enforcement — but any forwarder that modifies the message, by adding a footer or rewriting links, can break the DKIM signature too, at which point the forwarded message fails DMARC despite being entirely legitimate.
Mailing lists
Discussion lists and listservs are notorious because they routinely modify messages — prepending [list-name] to the subject, appending unsubscribe footers, altering the body. Each modification invalidates the original DKIM signature, and the list relays from its own infrastructure, so SPF does not align either. A client who participates in industry mailing lists will generate DMARC failures for genuine mail, and moving to reject without understanding this can bounce their contributions to a list they care about.
Gateways in front of the mailbox
Many organizations route mail through a security gateway or appliance. When a gateway sits in front of a mailbox platform, it can alter messages and re-originate them in ways that disturb SPF and DKIM alignment — a problem common enough to have its own detailed treatment in why DMARC fails with a gateway in front of Microsoft 365. The same class of issue appears with any inline mail-processing layer, not just Microsoft 365.
Where ARC helps, and where it does not
The Authenticated Received Chain is often presented as the answer to the forwarding and mailing-list problem, and it does help — but only under specific conditions. ARC lets an intermediary that legitimately modifies a message record the authentication results it saw before the modification, cryptographically sealing that assessment so a later receiver can choose to trust it. When an intermediary applies ARC and the final receiver evaluates ARC, a message that would otherwise fail can still be delivered on the strength of the chain.
The limitation is that ARC is only useful when both sides participate and the receiver decides the sealer is trustworthy. It is not a switch you flip on the client's domain to make forwarding problems vanish; it depends on the intermediary sealing correctly and the destination honouring the seal, neither of which you control. Treat ARC as a mitigation that improves outcomes in some intermediary scenarios, not as a universal fix that makes reject safe regardless of the mail path. The mechanics are covered in ARC explained.
The staged path now that pct is gone
For years, MSPs softened the move to enforcement with the pct tag, publishing p=reject; pct=10 and inching upward. RFC 9989 removes pct, and receivers implementing the new standard ignore it, so enforcement is now genuinely all-or-nothing at each policy level. That sounds like it removes the safety margin, but in practice it clarifies the real rollout, which was never about percentages. The safe path is a sequence of complete policy states, each gated by evidence:
- Start at
p=noneand collect aggregate reports until you have a complete, confident inventory of every source that legitimately sends as the domain. - Bring each of those sources into aligned SPF or aligned DKIM, and confirm the alignment is stable rather than intermittent.
- Move to
p=quarantine, applied in full, once the reports show that legitimate mail authenticates and only unknown or unwanted sources are failing. - Advance to
p=rejectwhen quarantine has run cleanly for long enough to trust the picture, accounting explicitly for forwarding and list traffic.
Because each level is all-or-nothing, the safety now comes from the quality of the evidence behind each transition, not from a percentage dial. That is a more honest model, and a more defensible one when a client asks why you are confident. The reasoning is expanded in pct is going away.
Document known senders before you recommend reject
The single most important prerequisite for reject is a documented sender inventory. Before recommending enforcement, an MSP should be able to name every system that sends mail as the client — the mail platform, marketing tools, ticketing systems, billing services, CRM, and the one-off application the client forgot about — and show that each produces an aligned pass. Only against that inventory can you tell the difference between a failure that means "an attacker is spoofing this domain" and one that means "the client's own newsletter is misconfigured." Moving to reject without the inventory is how legitimate mail gets bounced and how an MSP turns a security improvement into a support incident.
The inventory is also what lets you reason about the awkward cases. If the client participates in mailing lists or relies on forwarding, you document that, decide whether ARC or a sender-side fix addresses it, and set expectations before enforcing — rather than discovering it from an angry phone call after.
Read the evidence: reports and headers
Two evidence sources drive the decision. Aggregate reports, now standardized in RFC 9990 with DKIM detail required rather than optional, give you the population-level view: which sources are passing, which are failing, and whether the failing ones are legitimate. When a specific message raises a question — a real message that failed, or a delivered message the reports suggested should have been rejected — the answer is in the headers. Pasting the full headers into an email header analyzer shows the SPF result, the DKIM result and the alignment for that exact message, which is often the fastest way to explain a surprising outcome. The common and confusing case where a report shows reject but the mail still arrived is worked through in DMARC reports say reject but email was delivered.
When a domain is genuinely ready for reject
A domain is ready for p=reject when three conditions hold together: every legitimate sender is inventoried and producing an aligned pass, the aggregate reports show a clean picture with failures confined to unknown or malicious sources, and the known complications — forwarding, lists, gateways — are understood and either mitigated or explicitly accepted. When those conditions are met, moving to reject is low-risk and overdue. When they are not, no amount of standards maturity makes it safe; the work is to reach those conditions, not to skip them. Reject remains the goal precisely because it is the only policy that fully protects the client — and it remains a policy that rewards care, even under a modern standard.
Related articles
- DMARC for MSPs — complete guide
- pct is going away: rethinking partial DMARC enforcement
- Why DMARC fails with a gateway in front of Microsoft 365
- ARC (Authenticated Received Chain) explained
- DMARC reports say reject but email was delivered
Authoritative references
- RFC 9989 — core DMARC protocol, which removes pct
- RFC 9990 — DMARC aggregate reporting
- RFC 7489 — the obsoleted 2015 specification
Author: DMARC AI editorial team Last updated: August 2026