A DMARC policy of reject tells receiving servers to refuse any message that claims your domain and fails authentication. It gives the strongest protection against spoofing and the least room for error, because a legitimate sender you forgot about is bounced rather than filed in spam. Switch it on only after the reports show every real sender passing.
The short version
Under p=reject, a failing message is refused during the SMTP conversation, so the recipient never sees it and the sending server receives a bounce. Google’s guidance allows reject but warns that rejected messages are never delivered. Treat it as the last stage of a rollout, not the first.
What happens to a message under p=reject
| Situation | Result under p=reject | Why |
|---|---|---|
| Your own tool, signing with aligned DKIM | Delivered | It passes DMARC |
| A spoofer sending as your exact domain | Refused | It fails SPF and DKIM alignment |
| A forgotten billing or support tool | Refused and bounced | It was never aligned |
| A message forwarded by the recipient to another mailbox | Often delivered | SPF usually fails after forwarding, but DKIM survives if the forwarder leaves the content unchanged |
| A post to a mailing list that adds a footer | Can be refused | The list resends from its own servers and alters the message |
If you have not yet reached enforcement at all, start with our guide to the policy not enabled warning, which covers the move from p=none to quarantine.
Why forwarding and mailing lists are the weak spots
DMARC passes when SPF or DKIM passes and aligns with the visible From domain. Forwarding tends to break SPF, because the forwarding server is not listed for your domain. DKIM survives only if nothing in the signed content changes, so an added footer or banner can break it.
Mailing lists break both checks. The list resends from its own servers, and it often adds subject tags or footers that invalidate the author’s signature. Hackernoon’s explainer notes that Yahoo and AOL’s 2014 policy change caused this at scale. ARC, defined in RFC 8617, lets a list record earlier authentication results, but only receivers that evaluate ARC benefit. The others still reject the message.
The practical rule from the Suped guide is caution for any domain whose users post to external mailing lists. It advises against reject for those domains, with at least a month at p=none and a similarly long period at quarantine first.

Checks to pass before you switch
The first check is an inventory, not the reports. A quiet period in aggregate reports does not prove that no other senders exist, so cross-check the reports against the tools your team actually uses. Look for hidden mail such as password resets, billing, cron alerts, support tools, sales systems and vendor mail.
Then confirm that there is only one DMARC record at _dmarc, that its syntax is valid, and that your SPF record stays within the limit of ten DNS-querying terms. Any source that fails both SPF and DKIM should be fixed or retired before you move on. A malformed or duplicated record causes its own failures, which our guide to the 554 5.7.5 error explains.
Subdomains: what sp= does
The sp= tag sets the policy for subdomains that have no DMARC record of their own. If it is absent, subdomains inherit the policy from p=. That means a move to reject on the main domain also applies to every forgotten subdomain that sends mail, so audit them first and set sp= deliberately.
Promote, hold or roll back
| What you see | What to do |
|---|---|
| Every legitimate source is aligned and a full sending cycle ran clean | Promote to the next stage |
| A legitimate sender fails, but it has an owner and a fix plan | Hold at the current stage |
| Customer, employee, billing or security mail is confirmed blocked | Roll back to the last known good record |
Prepare the rollback before you need it. Lower the record’s TTL ahead of the change, save the last known good record, and name the person who is allowed to revert it. Rollback is not instant, because cached records persist, and mail that was already rejected has to be resent once the problem is fixed.
Questions about a DMARC policy of reject
Does p=reject block all spoofed email?
It tells participating receivers to refuse mail that fails DMARC for your exact domain, which stops most direct spoofing of your From address. It does not stop lookalike domains or display name tricks, because those use a different domain that your record does not cover.
Is p=reject better than p=quarantine?
It protects more, and it also fails harder. Quarantine sends failing mail to spam, where it can still be found, while reject refuses it outright. Choose reject once the reports show every legitimate sender passing, and not before that point.
Can p=reject hurt my own deliverability?
Only for messages that fail DMARC. Mail that passes aligned SPF or DKIM is delivered as normal. The risk is a forgotten sender, a forwarded message or a mailing list post that fails and is refused instead of being filed in spam.
How long should I stay at quarantine before reject?
Google gives no fixed interval beyond monitoring first and raising the percentage gradually. One guide advises at least a month at quarantine for domains whose users post to mailing lists. Hold until a full sending cycle, including monthly billing mail, runs clean.
How do I undo p=reject if mail is blocked?
Restore the last known good record and send fresh test messages. Cached records mean the change is not instant, and rejected mail has to be resent. Lowering the record’s TTL before the switch makes the reversal spread faster.
Bottom line
p=reject is a sound destination for a domain that sends from a small, known set of tools. Get there by inventory first, then by stages, and keep a rollback ready. For domains with many senders or heavy mailing list use, quarantine can be an acceptable place to stop.
Related reading
- DMARC quarantine/reject policy not enabled: the staged path from p=none
- 554 5.7.5 permanent error evaluating DMARC policy: fixing record faults that cause bounces
- SPF, DKIM and DMARC explained: the foundations behind the policy


