How do I know it is safe to move to p=reject?

21 June 2026 · 13 min read

You know it is safe to move to p=reject when the evidence says so, not when a date on the calendar arrives or when you feel impatient with p=none. Enforcement is a decision you make from data, and the data comes from your own DMARC aggregate reports. Before you publish a rejecting policy you want to be able to answer one question honestly: "Is every system that legitimately sends as my domain authenticating and aligning, and has it stayed that way long enough that I trust it?" If you can point to a clean run of reports that proves it, the move is a controlled step. If you cannot, p=reject is a gamble, because rejection is silent and irreversible: a receiving mailbox that honours your policy will discard the failing message with no bounce you will notice in time and no way to recover what was thrown away. This article lays out exactly what evidence to gather, how to read it, how to handle the awkward cases like forwarding, and how to ramp into enforcement with a rollback plan so that "safe" is something you have demonstrated rather than hoped for.

What "safe" actually means at p=reject

DMARC only ever acts on mail that fails both SPF alignment and DKIM alignment. A message can pass SPF, fail DKIM, and still pass DMARC, or vice versa, as long as one mechanism passes and the domain it authenticates against matches the domain your recipients see in the From header. That matching requirement is alignment, and it is the part that catches people out. A message can have a perfectly valid SPF result for a vendor's own domain and still fail DMARC because that domain is not yours. If you are fuzzy on this, read DMARC alignment explained before you go further, because everything below depends on it.

So "safe to move to p=reject" reduces to a concrete claim: none of your legitimate mail fails DMARC alignment. Not "most". Not "the important stuff". None of it, across a representative window of time that includes your infrequent senders. The whole purpose of the monitoring phase at p=none is to let you verify that claim with real receiver data instead of assuming it. You can confirm your current published policy at any time with the free DMARC checker; if it still reads p=none, you are in the right place to start gathering evidence.

Evidence one: full source coverage

The first and most important thing to establish is that you have seen everything that sends as your domain. This is the failure that breaks email at enforcement: an unknown legitimate sender you never fixed because you never knew it existed. Aggregate reports are how you find them.

When you publish a p=none record with a rua= address, mailbox providers begin sending you daily XML summaries grouped by sending IP, authentication result and alignment. Over time these reports draw a map of your real email estate. The systems that surprise people are rarely the obvious ones; it is the quarterly invoicing run, the helpdesk that emails customers from a subdomain, the CRM a regional office signed up for, the legacy application on a server nobody owns any more, the recruitment tool, the appointment-reminder service. Read reading your first DMARC report for how to interpret the raw data, and use the DMARC report analyzer to turn the XML into a plain list of who is sending and whether they pass.

Coverage means two things:

Time coverage. You have collected reports long enough to capture low-frequency senders. Two weeks is a floor, not a target. If you bill monthly, run payroll monthly, or send seasonal campaigns, you need a window that contains at least one of each. A month is a sensible minimum for most estates, and longer for complex ones.
Source coverage. Every sending IP and service in the reports has been identified and classified as either legitimate-and-yours, third-party-you-authorise, or unwanted. You should have no rows left in the "I do not recognise this" pile. An unidentified source is not necessarily an attacker; it is just as likely to be a forgotten internal system, and enforcing against it would cut off real mail.

A practical test for coverage: when a new batch of reports arrives, does it contain any sending source you have not already seen and accounted for? When the answer has been "no new surprises" for a sustained period, your map is probably complete. If you are still seeing fresh sources appear, the map is not finished and it is too early to enforce. For the wider picture of why discovery, not policy, drives the timeline, see how long it takes to reach p=reject.

Evidence two: sustained alignment, not a single good day

Once you can see every source, the next question is whether each legitimate one aligns. It is not enough that a sender passes SPF or DKIM in some abstract sense; the authenticated domain has to match your visible From domain under DMARC's alignment rules.

For each legitimate source, confirm one of the following:

DKIM aligned. The message carries a valid DKIM signature where the d= domain is your domain (or a subdomain, under relaxed alignment). DKIM is the more robust of the two because it survives a forwarded message: the signature travels with the email and is re-verified wherever it lands. Wherever a vendor supports it, set up DKIM signing on your domain and confirm the selector resolves with the DKIM checker. Hosted DKIM management keeps those keys published and rotated for you.
SPF aligned. The envelope sender (the MAIL FROM, also called the return-path) is in a domain that matches your From domain and is authorised by your SPF record. Many providers send with their own return-path by default, which passes SPF for their domain and therefore fails SPF alignment for yours; the fix is usually a custom return-path or "custom MAIL FROM" setting on the vendor side. Validate your record with the SPF checker.

Belt and braces is the goal: get senders passing both SPF alignment and DKIM alignment where you can, so a single broken mechanism does not push a message to failure. But pay attention to the word sustained. One clean day proves very little. You are looking for alignment that holds across the whole reporting window, including weekends, month-end batches and campaign sends. A sender that aligns on Tuesday but fails on Friday when a different mail server in the vendor's pool handles the load is not ready. Watch the trend in the reports until the failing rows for your legitimate sources reach and stay at zero.

While you are doing this, keep an eye on your SPF record's lookup budget. SPF permits a maximum of ten DNS lookups during evaluation, and a record that exceeds it returns a permerror, which means SPF effectively fails for every message. Stacking up vendor include: mechanisms quietly pushes you over that limit. If you are close, flattening or restructuring the record fixes it; automatic SPF flattening keeps you under the limit as vendors change their infrastructure, and you can read how that works in how SPF flattening works.

Evidence three: a deliberate plan for forwarding

Forwarding is the one scenario that can look like a failure when nothing is actually wrong, and it is the single most common reason people hesitate at enforcement. It deserves its own analysis before you commit.

When a message is forwarded, for example a user auto-forwarding to another account, or a server-side alias relaying mail onward, the forwarding hop changes the connecting IP. SPF breaks at that point because the new sending server is not in your SPF record; it is the forwarder's. DKIM usually survives, because the signature is part of the message and is re-verified at the destination, unless the forwarder modifies the body or certain headers, for example by appending a footer, rewriting links or changing the subject. A mailing list is the classic offender: it commonly alters the subject and adds a footer, which invalidates the original DKIM signature, and it forwards from its own IP, which breaks SPF. The result is a message that fails DMARC despite being entirely legitimate. The mechanics are covered in why forwarding breaks authentication.

Here is the part that matters for your decision: forwarding failures in your reports are expected and are usually not a reason to delay enforcement. What you must do is distinguish them from real failures of your own systems, so you do not block your own infrastructure while accepting that some forwarded copies will fail.

Identify forwarding streams in the reports. They typically show as low-volume sources, often consumer-mailbox or mailing-list infrastructure, where DKIM may pass even though SPF fails on an unfamiliar IP, or where both fail on a known list server. Distinguish these from your transactional and marketing senders.
Lean on DKIM. Because aligned DKIM survives plain forwarding, getting strong DKIM alignment on your real senders means most simple forwards still pass DMARC. This is another reason DKIM alignment is worth the effort even when SPF already passes.
Understand ARC for lists. Authenticated Received Chain lets an intermediary vouch for the authentication results it saw before it modified the message. It does not force a receiver to accept the mail, but participating receivers can use it to avoid penalising legitimate list traffic. See ARC explained and the deeper treatment in mailing lists, DMARC and ARC.
Accept the residual. A small volume of forwarded mail to receivers that do not honour ARC will fail at p=reject. This is true for every domain on the internet at enforcement and is not a defect in your setup. The question is whether the legitimate, in-your-control sources are clean, and whether the forwarding volume is understood and acceptable. For most domains it is a thin slice, and the protection enforcement buys against spoofing is worth it.

If you discover that critical business mail flows through a mailing list or an aliasing setup that mangles your messages, address that specific channel, by signing in a way that survives, by changing the list configuration, or by accepting the known impact, before you enforce. The point is that you go into p=reject having already decided what happens to forwarded mail, rather than being surprised by it.

The staged ramp

Once coverage is complete, alignment is sustained, and forwarding is understood, you enforce in stages. Never jump from p=none straight to p=reject. The intermediate steps exist so that any mistake shows up small and recoverable. The full route is described in the enforcement journey, and the policy meanings in none, quarantine, reject. A sensible ramp looks like this:

p=quarantine; pct=10. Quarantine sends failing mail to spam rather than discarding it, and pct=10 applies that treatment to only ten percent of failing messages. This is the gentlest possible enforcement: visible, recoverable, and limited to a small slice. Watch the reports. The percentage applies to mail that fails, so if your legitimate mail is genuinely clean, almost nothing should be affected.
Raise quarantine: pct=25, then 50, then 100. At each step, wait for at least a few days of reports and confirm that no legitimate source has started failing. If something appears, you have caught it in spam, not in the void, and you can pause and fix it.
p=quarantine; pct=100. A full quarantine that holds clean for a sustained window is your strongest signal that p=reject is safe. By this point, all your legitimate mail is passing and only genuine failures (spoofing and the known forwarding residual) are being quarantined.
p=reject. Switch the policy. Failing mail is now rejected outright. Because you proved the system clean at full quarantine first, this change should produce no visible difference for your legitimate mail; it simply moves the unwanted traffic from spam to refused.

A few notes on the mechanics. pct is a sampling control, and not every receiver implements it identically, so treat it as a way to reduce blast radius rather than a precise dial; the deeper detail is in DMARC pct sampling. Consider your subdomain policy too: the sp tag sets policy for subdomains independently, and if you have subdomains that send mail you want them included in the same discipline. Do not leave a subdomain at an implied none while the organisational domain reaches reject, because attackers will simply spoof the subdomain instead.

Throughout the ramp, the reports remain your instrument panel. Continuous monitoring is what tells you a DKIM key expired, a vendor changed its sending infrastructure, or a new internal system appeared, before it becomes a user-visible problem. Hosted monitoring and change alerts email you the moment a previously-passing source starts failing, which turns the ramp from a manual vigil into a managed process; the design is described in monitoring and change alerts.

Your rollback plan

Safe does not mean nothing can go wrong; it means you can react fast if it does. Before you publish each enforcing step, know exactly how you would reverse it.

Rollback is a single DNS edit. DMARC policy lives in one TXT record. Easing back from p=reject to p=quarantine, or from quarantine to p=none, is one change to that record. There is nothing to redeploy and no application to restart.
Know your propagation time. The speed of a rollback is bounded by the TTL on your DMARC record. A high TTL means receivers may keep using the old, stricter policy for hours after you change it. Before enforcing, set a modest TTL (for example a few hours, or lower) on the DMARC record so a rollback takes effect quickly. This is a deliberate pre-enforcement step, not an afterthought.
Define your trigger. Decide in advance what would make you roll back: a specific legitimate source appearing in the failing rows, a spike in failures from a known-good IP range, or a credible user report of missing mail. Vague intentions are not a plan. A named trigger lets you act without debating it under pressure.
Watch the right signal. The fastest evidence of trouble is the next aggregate report cycle showing one of your own sources failing, plus alerting on it. The slowest and worst signal is a customer telling you their messages never arrived. Bias your monitoring towards the former.
Step backwards, not all the way. If something fails at p=reject, dropping to p=quarantine usually restores delivery to spam (recoverable) while you investigate, which is less disruptive than collapsing all the way to p=none. Reserve the full retreat for a genuinely broad problem.

Because each enforcing step was reached only after the data was clean, an actual rollback should be rare. But having the plan written down is part of what makes the move safe, in the same way that a checklist before take-off is not pessimism, it is competence.

A readiness checklist

Before you publish p=reject, you should be able to tick every one of these honestly:

You have collected aggregate reports for a window long enough to include your infrequent senders, and recent reports contain no unfamiliar sources.
Every legitimate source is identified and classified, with nothing left in the "unknown" pile.
Each legitimate source passes DKIM alignment, SPF alignment, or both, and has done so consistently across the window, not on a single good day.
Your SPF record is within the ten-lookup limit and returns no permerror.
You have identified your forwarding and mailing-list streams, decided how to handle them, and accepted the small known residual that will fail at receivers without ARC.
You have ramped through quarantine with pct and held a clean full quarantine before switching.
Your subdomain policy (sp) is set deliberately, not left implicitly open.
Your DMARC record TTL is low enough for a fast rollback, and you have a named trigger and a defined step-back.

If you can tick all of these, the evidence supports enforcement and the move is safe. If any line is shaky, that line is your next piece of work, not a reason to enforce and hope. The full set of prerequisites is gathered in our requirements guide, and unfamiliar terms are defined in the glossary.

How DMARC Engine makes the call for you

Everything above is a discipline you can run by hand, and plenty of people do. The reason it is error-prone is not that any single step is hard; it is that the evidence is scattered across daily XML reports, the senders change underneath you, and the cost of getting it wrong is invisible until a customer complains. DMARC Engine collapses that work into one managed flow: it publishes and hosts your records, parses every aggregate report into a clear readout of sources and alignment, surfaces new and failing senders as alerts, and recommends each enforcement step only when the data supports advancing, holding you at the current step until it does. Hosted SPF flattening keeps you inside the lookup limit, hosted DKIM keeps signatures valid, and MTA-STS hardens the transport on top. You keep your existing email providers; the platform changes the DNS, watches the reports and tells you, with evidence, when p=reject is safe.

If you want to start now, publish a monitoring record today so the discovery clock begins, then run a free DMARC check and an SPF check to see your current position without changing anything. For the broader walkthrough, read reach p=reject without breaking email and will enforcing DMARC break my email?. The domains that reach p=reject without incident are not the lucky ones; they are the ones that gathered the evidence first.