A DMARC policy of p=reject asks receiving mail servers to refuse any message that fails DMARC authentication at the SMTP layer, so it never reaches inbox or spam. It is the strongest enforcement level DMARC offers, and the intended end state for any domain serious about stopping spoofing. The precondition is non-negotiable: only publish p=reject once aggregate reports and alignment testing have confirmed every legitimate sender passes cleanly, because DNS does not distinguish between a phishing attempt and a forgotten internal tool sending on your behalf.
TL;DR:
- Moving to DMARC reject requires several weeks of confirmed, error-free SPF and DKIM alignment across all legitimate senders, verified through aggregate reports.
- Subdomains should have explicitly configured policies with sp= and np= tags to prevent spoofing and avoid unintended fails during enforcement.
- Quarantine can serve as a permanent destination for complex or shifting senders, especially for marketing campaigns, rather than just a staging step before reject.
- Enforcing reject suddenly can cause email outages if internal tools, third-party services, or forwarding systems are not properly aligned or included in SPF and DKIM.
- A gradual rollout from none to quarantine to reject, with careful monitoring and TTL adjustments, minimizes risks and allows for quick rollback if needed.
Digistrat
Protect Email Performance During DMARC Changes
Digistrat assesses sender reputation, infrastructure, and list quality to help businesses address email deliverability challenges.
Table of Contents
- What p=reject actually does at the SMTP layer
- Quarantine vs reject: which enforcement level fits your domain?
- How do you know you’re ready to set DMARC to reject?
- Rolling out DMARC enforcement step by step
- What breaks first when you enforce DMARC (and how to fix it)
- Reading DMARC aggregate reports after enforcement
- Subdomains, mailing lists, ARC and BIMI: what enforcement touches
- Rollback and emergency procedures if reject causes problems
- Why most DMARC rollouts fail on process, not technology
- Getting to DMARC reject without breaking your inbound revenue
- Sources
- FAQ
What p=reject actually does at the SMTP layer
A DMARC record lives as a TXT entry at _dmarc.yourdomain.com, and the p= tag inside it tells receiving servers what to do with mail that fails both SPF and DKIM alignment checks. When that tag reads p=reject, the instruction is unambiguous: refuse the message during the SMTP transaction itself, before it is accepted onto the receiving server at all.
That distinction matters more than most administrators expect. Quarantine still lets the message through the front door and drops it in a spam folder, where a curious recipient might still find it. Reject closes the door entirely. There is no bounce sitting in a junk folder, no delayed delivery, and often no trace in the sender’s own logs beyond an SMTP rejection code, which is why monitoring reports become so important once you flip the switch.
It helps to remember that a DMARC policy is a request, not a command. RFC 9989, the DMARCbis update to the original specification, is explicit that final disposition remains a matter of local policy at the receiving end. In practice, major mailbox providers such as Gmail and Microsoft honour p=reject consistently, but smaller or regional mail systems can apply their own judgement. The same RFC also formally retires pct= as the primary rollout mechanism, replacing it with the t=test flag, which is a cleaner way to signal “not yet fully live” without diluting enforcement in a way that is hard to audit.
Worth noting before you go further: phishing remains one of the most common vectors employees fall for, which is precisely the exposure p=reject closes off at your own domain.
Key mechanics to hold onto:
p=rejecttriggers refusal during the SMTP handshake, not after acceptance.- Enforcement depends on the receiver’s own mail system honouring the DMARC record.
t=yreplacespct=as the preferred way to signal a cautious rollout under DMARCbis.- SPF and DKIM alignment, not just their presence, is what the policy actually checks.
Quarantine vs reject: which enforcement level fits your domain?
The three DMARC policy states map to three very different outcomes for a failing message. p=none lets it land wherever it would have gone anyway, purely for monitoring. p=quarantine diverts it to spam or junk. p=reject refuses it outright, and once refused, it is genuinely gone: there is no folder to check, no delayed retry that magically appears three days later.
That difference changes how expensive a mistake becomes. A false positive under quarantine is annoying (a customer might miss an invoice email for a day) but recoverable, because the message still exists somewhere. A false positive under reject is often silent and permanent from the sender’s point of view, unless the sending system logs the bounce and someone actually reads it.
- None: full delivery regardless of authentication result, used purely to gather reporting data.
- Quarantine: message routed to spam, recoverable if someone checks the right folder.
- Reject: message refused at SMTP, unrecoverable without a resend from the original source.
Quarantine vs reject DMARC decisions should not always be treated as a staging step on the way to something stronger. For domains with a genuinely complex or shifting sending ecosystem, quarantine can be a deliberate, permanent destination rather than a stepping stone, particularly where silent loss under reject would be commercially unacceptable.
Pro Tip: If your organisation runs frequent one-off marketing campaigns through unfamiliar platforms, keep those specific subdomains on quarantine even after your main domain reaches reject. It buys you a safety net exactly where new senders are most likely to slip up.
How do you know you’re ready to set DMARC to reject?
Jumping straight to p=reject without data is one of the most common causes of email outages, and it is entirely avoidable. The correct policy is the strictest one your aggregate reports actually prove your senders can survive, not the strictest one you feel confident about.
Work through this sequence before you touch the record:
- Build a complete sender inventory. List every system sending as your domain, including the obvious ones (your ESP, your CRM) and the easily forgotten ones (a helpdesk tool, an internal monitoring alert, a finance system emailing invoices).
- Verify SPF and DKIM alignment for each sender individually. A sender can pass SPF or DKIM in isolation and still fail DMARC alignment if the domains do not match the way the specification requires. Remember that SPF has a hard limit of 10 DNS lookups, so a sprawling list of third-party includes can silently break authentication for everyone.
- Run aggregate (rua) reports for a sustained window, ideally several weeks, covering normal business cycles rather than a quiet fortnight that hides seasonal senders.
- Confirm failure rates are genuinely minimal, not just trending downward, and investigate every remaining failure by source IP before moving on.
- Decide explicit
sp=andnp=values for subdomains, and map out how mailing lists or forwarding arrangements will behave once enforcement tightens.
Pro Tip: Export your rua reports into something queryable rather than reading raw XML by eye. Even a basic spreadsheet pivot on source IP and disposition will surface the two or three problem senders responsible for most of your failures.
Rolling out DMARC enforcement step by step
Moving through DMARC enforcement levels works best as a deliberate sequence, not a single jump. Start at p=none, move to p=quarantine once you are confident in your sender list, and only set DMARC to reject once quarantine has run cleanly for a meaningful stretch. That none to quarantine to reject sequence, with rua reporting active throughout, is the rollout path most operational guides converge on.
Example records at each stage:
The t=y flag deserves particular attention. Under DMARCbis, publishing your intended policy alongside t=y asks receivers to apply enforcement one level lower than stated while you validate the effects, which is a far more transparent mechanism than the old pct= ramp. If you still choose a legacy pct= ramp for gradual rollout, know that it is deprecated in DMARCbis and t=y is the preferred modern equivalent.
Two practical habits make this safer:
- Lower your DNS TTL to something like 300 seconds before making any policy change, so a rollback propagates quickly if something breaks.
- Space out each stage by at least a week or two, giving reports enough time to surface issues before you tighten further.
Pro Tip: Keep a dated log of every DMARC record change alongside the aggregate report window it was measured against. When something breaks three weeks later, you want to know exactly which change caused it, not guess between four possibilities.
What breaks first when you enforce DMARC (and how to fix it)
Certain failure patterns show up almost every time a domain moves to enforcement, and knowing them in advance saves hours of guesswork.
- Forgotten internal tools and third-party services. Ticketing systems, alerting platforms, and finance software often send as your domain without anyone realising they were never added to SPF or given a DKIM key. Your sender inventory from the readiness checklist should catch most of these before they cause a rejection.
- Mailing lists and forwarding. When a message passes through a mailing list or gets forwarded, the envelope sender often changes while the DKIM signature breaks entirely, causing legitimate mail to fail DMARC. ARC (Authenticated Received Chain) headers, where the intermediary supports them, help preserve authentication signals through that hop.
- Subdomain misconfiguration. A missing or incorrect
sp=ornp=value can leave a subdomain either under-protected or unexpectedly caught by a policy meant for something else entirely.
To trace any of these, go back to your aggregate reports and sort by source IP and disposition. A single IP responsible for a disproportionate share of failures is almost always the fastest lead.
Pro Tip: Cross-reference failing source IPs against your DNS provider’s SPF include list before assuming a sender is illegitimate. Sometimes the sender is genuine but simply never got added to the record.
Reading DMARC aggregate reports after enforcement
Once p=reject is live, aggregate reports stop being a nice-to-have and become your only visibility into what is actually happening to your mail. Each report entry carries the source IP, SPF and DKIM pass or fail results, the header-from and envelope-from domains, and a message count for that combination.
Prioritise by volume first. A source sending five failing messages a week is a low priority; a source sending five thousand needs investigation the same day you spot it, because that is either a serious spoofing attempt or a business-critical sender about to lose mail permanently.
Forensic reports (ruf) can add detail down to individual failing messages, but adoption is patchy because they can contain personal data, and many providers restrict or decline to send them for privacy reasons. Treat ruf as a supplementary tool rather than something to depend on.
- Sort every report by disposition and volume before reading anything else.
- Flag any new source IP appearing for the first time, since that is often either a new legitimate sender or an active spoofing attempt.
- Automate parsing where possible; manually reading raw XML aggregate reports does not scale past a handful of domains.
Given that phishing continues to be one of the most exploited weaknesses employees encounter, a spike in failed authentication attempts against your domain is worth treating as a live incident, not routine noise.
Subdomains, mailing lists, ARC and BIMI: what enforcement touches
Enforcement decisions rarely stop at the top-level domain, and several adjacent systems need explicit configuration once you tighten policy.
- Subdomain policy. Use
sp=to set the policy inherited by subdomains that send mail, andnp=to cover subdomains that do not exist at all. Settingnp=rejectcloses off a common spoofing route where attackers register mail from a non-existent subdomain of a trusted brand, even while your main domain is still cautiously sitting on monitor mode. - Mailing lists and forwarding. Both routinely break DKIM signatures. Where the intermediary supports ARC, it preserves the original authentication result for the next hop to trust.
- BIMI. Brand logos in the inbox depend on DMARC enforcement being in place, usually at quarantine or above, so marketing teams chasing BIMI adoption need to understand that it is gated behind the same policy decisions this article covers.
- Third-party senders. Wherever possible, move third parties onto their own DKIM signing keys or verified sending arrangements rather than leaning on SPF includes alone, which age badly and quietly exceed lookup limits.
Rollback and emergency procedures if reject causes problems
Every rollout to p=reject should have a rollback plan written down before the change goes live, not improvised afterwards.
- Lower your DNS TTL to a short value (300 seconds is typical) several days ahead of any policy change, so a reversal propagates within minutes rather than hours.
- If critical mail starts failing, revert the DMARC record to the previous policy level immediately and confirm via a fresh DNS lookup that receivers are picking up the change.
- Use bounce feedback and, where available, direct contact channels with major mailbox providers to identify exactly which messages were affected and why.
- Communicate the rollback to stakeholders promptly, since silent email loss under reject rarely announces itself the way a server outage does.
Why most DMARC rollouts fail on process, not technology
The technical side of DMARC is genuinely simple, which is exactly what makes it dangerous. Anyone can paste p=reject into a DNS record in thirty seconds. What causes outages is not a misunderstanding of the specification; it is skipping the reporting window that would have shown which senders were about to break.
Work on DMARC rollouts tends to fall into a consistent pattern: inventorying every sending source a client has genuinely forgotten about, working through weeks of aggregate report data to spot alignment failures before they become rejections, fixing the underlying SPF and DKIM configuration rather than just recommending it, and staying on hand through the quarantine and reject stages to catch anything that slips through.
Outsourcing this makes sense once the sender list gets complicated, once a previous attempt at enforcement has already caused a delivery incident, or once the internal team simply does not have the hours to read weeks of XML reports properly. That is usually the point where a specialist earns their fee faster than an internal team can learn the same lessons by trial and error.
Getting to DMARC reject without breaking your inbound revenue
One approach differs from most generic DMARC guides in one practical way: the fixes happen directly, rather than being described in a report and left for an internal team to implement weeks later. For a business relying on email for revenue, that gap between diagnosis and action is where the real damage tends to happen.
An engagement typically starts with the free health check, which looks at your current sender authentication, sender reputation, and how close your domain actually is to a safe p=reject rollout. From there, clients move into whichever plan suits their situation, whether that is an Advised arrangement where Digistrat guides your own team through the checklist above, a Managed engagement where the deliverability review and fix work is carried out directly, or an Owned plan for organisations that want the whole authentication setup handled end to end. The DMARC checker, monitoring and setup service covers the technical rollout itself, including record configuration, aggregate report analysis, and staged enforcement through quarantine to reject.
For teams that just need a focused answer to one tricky question, whether that is a subdomain misconfiguration or a mailing list that keeps failing alignment, the £250 one-off advisory session is built for exactly that. If your DMARC report backlog has been sitting unread for a month, that is the next step worth taking.
Sources
For readers who want to verify the technical claims above directly against source material:
FAQ
How do I change my DMARC policy to reject?
Update the p= tag in your DMARC TXT record to p=reject, but only after aggregate reports over several weeks confirm every legitimate sender is passing SPF and DKIM alignment. Publishing reject without that data is the single most common cause of DMARC-related outages.
How do I fix a DMARC policy stuck at quarantine that won’t move to reject?
Usually this means aggregate reports still show failures from a legitimate sender, most often an internal tool, a mailing list, or a third-party service using SPF alone without proper alignment. Work through your sender inventory, fix the specific alignment failures shown in the reports, and only then update the record to p=reject.
What does a DMARC policy actually mean?
A DMARC policy tells receiving mail servers what to do with a message that fails SPF and DKIM alignment checks against your domain, with three possible instructions: none for monitoring only, quarantine to route it to spam, and reject to refuse it outright at SMTP level. It sits in a DNS TXT record and works alongside SPF and DKIM rather than replacing either.
How do I fix a DMARC fail error?
A DMARC failure almost always traces back to either an SPF alignment mismatch, a broken DKIM signature (often from forwarding or a mailing list), or a sending source missing from your authentication setup entirely. Check the aggregate report for the specific source IP and header-from domain involved, then correct the SPF include or DKIM key for that exact sender.
How long does it take to reach full DMARC enforcement safely?
Most organisations take between two and six months to move from p=none through p=quarantine to a stable p=reject, depending on how many senders they have and how quickly failures get resolved. Rushing this timeline is the most common reason enforcement causes unexpected delivery problems.
