- p=reject, defined
- p=reject is the strongest DMARC policy, instructing receiving servers to refuse mail that fails authentication outright, so a spoofed message is never delivered anywhere.
Rejection is the only policy that actually stops domain spoofing. Below it, a forged message still reaches somewhere a person could open it.
It is also the prerequisite for BIMI. Neither Gmail nor Yahoo will display a brand logo for a domain that is not enforcing at quarantine or reject.
Forwarding is the practical hazard. A mailing list that rewrites headers breaks the DKIM signature, and SPF was already broken by the relay, so legitimate mail fails both paths and is rejected.
The usual answer is to move list traffic to a subdomain with its own gentler policy, and to rely on receivers that implement ARC to preserve the original authentication result.
How ZapBounce reports it
The checker reports reject as full enforcement and notes whether the subdomain policy matches, because a strict organizational policy with an unset sp tag leaves subdomains covered in a way people often do not intend.
What the refusal looks like on the wire
At p=reject, a failing message is turned away mid-conversation and the sending server receives the reason as text. Gmail answers with 550 5.7.26 Unauthenticated email from acme.example is not accepted due to domain's DMARC policy. Microsoft's version reads 550 5.7.509 Access denied, sending domain acme.example does not pass DMARC verification and has a DMARC policy of reject.
Say your support desk tool was never authenticated. Each reply your agents send now comes back to the tool as one of those two lines. If the tool surfaces bounces, an agent sees it within minutes. Where it hides them, tickets simply go unanswered from the customer's point of view.
Search your sending platforms' bounce logs for 5.7.26 and 5.7.509 in the first days after the change. Every hit is either a sender you forgot or a spoofed message that was stopped, and the source IP tells you which.
Domains that send nothing should start here
The careful, staged rollout applies to domains that send mail. A domain that sends none has no legitimate traffic to break, so you can publish v=DMARC1; p=reject on day one. Pair it with an SPF record of v=spf1 -all, which says no server is allowed to send for this name.
Think about how many of those you own: old brand names, country variants, the misspellings you registered defensively. Attackers like them because they look official and nobody's watching. Ten minutes of DNS work closes each one.
For your sending domains, a useful pre-flight test is 30 consecutive days at full quarantine with no legitimate source showing up as failed in the reports. Keep the rua address after you switch. Reports keep arriving at reject, and they're how you'll notice when a new tool gets plugged in next year without anyone telling you.
p=reject: common questions
What are the risks of p=reject?
Any unauthenticated legitimate sender stops being delivered, with no spam folder to recover from. Forwarded and mailing-list mail is the usual casualty.
Is reject required for BIMI?
Quarantine or reject. BIMI ignores a domain at p=none entirely.
How do I handle mailing lists at reject?
Send that traffic from a subdomain with a softer policy, and rely on receivers that support ARC to carry the original result through.