p=reject is the strictest of the three DMARC policies. It tells receiving mail servers that any message carrying your domain in the From header, and failing DMARC, should be rejected rather than delivered or filtered.
The part that decides whether that is safe for you is not the policy tag. It is whether every legitimate path your mail travels still produces an aligned pass by the time it reaches the recipient. Those are different questions, and the second one is where the failures live.
It publishes a request that receivers reject mail using your domain in the From header when that mail fails DMARC. RFC 9989 defines p as a requested policy, so enforcement stays at the receiver's discretion, and the large mailbox providers do honour it. A message fails DMARC when neither SPF nor DKIM produces an aligned pass.
Aligned is the load-bearing word. Under RFC 9989, DMARC passes when at least one underlying mechanism passes and the identifier it authenticated matches the domain in the From header. SPF authenticates the envelope sender, which your ESP usually sets to its own bounce domain. DKIM authenticates the domain in the signature's d= tag. Neither of those has to be the domain your recipients see.
This is why a sender can hold two green checks and still fail. SPF passes on the ESP's bounce domain, DKIM signs with the ESP's domain, and the From header says yourcompany.com. Both mechanisms passed. Neither aligned. DMARC fails, and under p=reject the message is rejected.
d= value DKIM signed with, and the From header domain. If neither of the first two matches the third, under relaxed alignment at the organizational domain level, the message has no aligned pass and the policy will bite.
They are the three values RFC 9989 defines for the requested policy, and they differ only in what a receiver is asked to do with a failing message. p=none asks for no special handling and reports only. p=quarantine asks for the message to be treated as suspicious, in practice the spam folder. p=reject asks for outright rejection.
| Policy | Asked of the receiver | What it is for |
|---|---|---|
p=none | Deliver as normal, send aggregate reports | Observation. Find every legitimate sending source before enforcing anything. |
p=quarantine | Treat failing mail as suspicious | Enforcement with a recoverable failure mode. Mail lands in spam rather than disappearing. |
p=reject | Reject failing mail | Full protection of the domain. Failing mail does not arrive at all. |
Three tags modify all three policies. sp= sets a separate policy for subdomains that exist, and adkim= and aspf= switch alignment between relaxed, the default, which matches at the organizational domain, and strict, which requires an exact domain match.
RFC 9989 added a fourth, published in May 2026: np= covers subdomains that do not exist in DNS at all, which sp= does not. If absent it defaults to sp=, or to p= if there is no sp=. It closes a real spoofing pattern at no real cost, since no legitimate sender uses a subdomain that was never created.
Indirect mail flows, almost every time. A forwarder relays your message from its own IP address, which breaks SPF because the sending IP is no longer one you authorised. A mailing list that adds a subject tag or appends a footer modifies signed content, which breaks the DKIM signature. With both broken there is no aligned pass left.
Under p=none this is invisible, because nothing changes for the recipient. Under p=reject the same message is rejected at the SMTP transaction. Nothing about your configuration changed between those two outcomes. The only thing that changed was the instruction you gave the receiver about mail that was already failing.
ARC, specified in RFC 8617, exists to address this by letting intermediaries record an authentication result that a later receiver can choose to trust. Adoption is uneven, so I treat it as something that helps rather than something to rely on.
It was removed in May 2026. RFC 9989 replaced the fifteen-year-old original DMARC specification and dropped pct entirely, along with rf and ri. The percentage-based rollout it offered is gone. In its place is a binary t tag: t=y marks a policy as still provisional, and removing the tag signals full enforcement.
That change actually resolves a confusion pct always carried. Under the old rule, messages not selected by the pct sample were never exempt from policy, they were handled under the next lower policy instead. With p=reject; pct=50, the unselected half was quarantined, not delivered normally, so a partial rollout never meant what most senders assumed it meant. A binary flag removes that ambiguity: a policy is either provisional everywhere or enforced everywhere.
pct= value. It still parses, since a receiver on RFC 9989 ignores a removed tag rather than rejecting the record, but it does nothing now. If the intent was a staged rollout, I replace it with t=y for the transition and drop the tag once the policy is fully trusted.
When aggregate reports show every legitimate sending source producing an aligned pass, and they have shown it long enough to include your infrequent senders. The billing system that mails once a month, the recruiting tool, the transactional service someone set up two years ago. Those are what a short observation window misses.
The sequence I use is p=none with rua reporting until sources stop being new, then p=quarantine at full percentage, then p=reject. Each step is held long enough to cover a full billing and campaign cycle. Skipping the quarantine step is the common shortcut, and it converts a recoverable failure into an invisible one, since rejected mail generates no complaint from the recipient who never received it.
p=reject protects the domain in the From header. It does nothing about lookalike domains, display name spoofing, or a compromised account sending fully authenticated mail from inside your own infrastructure. All three are common, and all three produce mail that passes DMARC because it genuinely originated where it claims to.
So a domain at p=reject is a domain that cannot be impersonated by unauthenticated senders. That is worth having and it is a narrower claim than the one usually attached to it, and RFC 9989's np= only narrows it slightly further. If your SPF record is part of what you are hardening, the specific ways a valid one still causes damage are in why your SPF record might be actively making things worse.
Not directly. DMARC is an authentication policy rather than a reputation signal, so moving from none to reject does not raise your standing with a mailbox provider on its own. It stops unauthorised senders using your domain, which protects the reputation you already have. Google's bulk sender requirements are met by any published policy, including p=none.
Only the kind that puts your exact domain in the From header. Lookalike domains, display name spoofing and compromised internal accounts all sit outside what DMARC evaluates. They are frequently the more common attack, and they need monitoring and user reporting rather than a DNS record.
Not usually. A policy at the organizational domain applies to subdomains unless you override it with sp, which covers subdomains that exist, or np, added in RFC 9989, which covers subdomains that do not. Setting np=reject is low-risk for most senders, since it only affects mail claiming a subdomain nobody created.
They keep arriving unchanged. Reporting is driven by the rua tag and is independent of the policy, so you continue to see sources, volumes and alignment results after enforcement begins. Stopping reporting when you reach reject removes the only visibility you have into what the policy is now rejecting.