Publishing a DMARC record is the easy part. The hard part, and the part that actually stops spoofing, is moving your policy from p=none to p=reject without bouncing a single piece of your own legitimate mail. This is the enforcement stage. It is where most domains stall, because p=none feels safe and nobody wants to be the person who broke the monthly invoice run. The good news is that enforcement is a methodical, reversible process. Done in stages, with reports in front of you the whole time, it is low drama. Here is exactly how we do it.
Why you move in stages at all
DMARC has three policy values, and they are blunt instruments. p=none tells receivers to take no action and just send you reports. p=quarantine tells them to deliver failing mail to the spam or junk folder. p=reject tells them to refuse it outright at the SMTP layer, so it never reaches the recipient at all. You could, in theory, jump straight from no record to p=reject. Almost nobody should.
The reason is alignment, and the fact that you rarely know every system that sends mail using your domain until you have watched the reports. A typical organisation discovers, on first inspection, that mail is leaving its name from a help-desk tool, a CRM, a payroll provider, an events platform, and two marketing services nobody in IT had heard of. Some are correctly authenticated, some are not. Switch to p=reject before fixing the ones that are not, and you block your own legitimate mail along with the forgeries.
Staging solves this. You start at monitor only, prove every legitimate source passes, tighten to quarantine, confirm nothing real is landing in spam, then move to reject with confidence. At each step the reports tell you whether it is safe to proceed. You are never guessing.
The prerequisite: alignment, not just a pass
Before you touch the policy value, your real mail must align. This is the single most common reason enforcement goes wrong, so it is worth being precise. SPF can pass and DMARC can still fail, because DMARC does not care that SPF passed for some envelope domain. It cares that the domain SPF or DKIM authenticated matches the domain your recipients actually see in the From header.
Take a marketing email sent through a third party. The envelope sender might be bounces@mail.sendingplatform.net, which is what SPF checks, while the visible From is hello@yourcompany.com. SPF passes for the platform, but the domains do not match, so SPF alignment fails. If DKIM is not aligned either, DMARC fails, and under p=reject that email is gone. The fix is usually a DKIM signature with a d= value that matches your domain, often set up as a custom signing domain inside the platform. We walk through this in detail on how alignment works. If alignment is not solid, do not advance the policy. Fix the source first.
The three stages, and what each does
Here is the staged path with what each policy instructs receivers to do, and what you should be watching while you sit at that stage.
| Stage | Record | What receivers do | What you watch |
|---|---|---|---|
| 1. Monitor | p=none |
Deliver everything as normal. Take no enforcement action. Send aggregate reports. | Discover every sending source. Confirm legitimate sources align and pass. Identify the unauthenticated or forged traffic. |
| 2. Quarantine | p=quarantine |
Send failing mail to the spam or junk folder. Deliver passing mail normally. | Confirm legitimate pass rate stays at effectively 100%. Watch that nothing real starts landing in spam. Only forged or broken mail should be affected. |
| 3. Reject | p=reject |
Refuse failing mail at the SMTP layer. It is never delivered. | Confirm the pass rate holds. From here, mail that fails authentication in your name simply cannot reach inboxes. |
Notice what does and does not change across the stages. Your legitimate mail behaves identically at every step, because it passes authentication at every step. The only mail whose treatment changes is mail that fails: at p=none it is delivered and reported, at p=quarantine it is junked, at p=reject it is refused. If your alignment work is done properly, tightening the policy is invisible to your recipients and your senders. The only people who notice are the ones forging your domain, and what they notice is that it stopped working.
What we actually watch at each stage
The number that matters most is your legitimate pass rate. We are looking for it to sit at effectively 100% before any tightening. That figure comes straight from the aggregate reports: every receiver tells you how many messages claiming to be from your domain passed DMARC, and from which IP addresses. When we can map every passing source to a system you recognise, and the volume of failing mail is either zero or clearly attributable to abuse, you are ready to move up.
The failing column is the other half of the picture. Early on it usually contains a mix of two things: legitimate senders that are not yet aligned, which you must fix, and genuine spoofing, which is exactly what you want the policy to catch. The job of the monitor stage is to separate those two so that when you enforce, you are only ever blocking the second kind. We cover how to read these reports and spot the difference on how monitoring works.
The pct tag: a gradual percentage rollout, and the honest trade-off
DMARC includes a pct tag that applies your policy to only a percentage of failing mail. A record like v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourcompany.com tells receivers to quarantine roughly a quarter of failing messages and treat the rest as p=none. The idea is to dip a toe in: enforce on a slice, watch for fallout, then raise the percentage to 50, 75, and finally 100 before changing the policy word itself.
There is a genuine debate about whether pct is worth using, and it is fair to lay out both sides.
The case for pct
For a large or complicated estate, where you cannot be fully certain you have catalogued every sender, a partial rollout limits the blast radius. If a source you missed turns out to be unaligned, only a fraction of its mail is affected while you spot the problem in the reports and fix it. For risk-averse organisations sending high volumes, that cushion has real value.
The case against pct
The counter-argument is that pct mostly delays the moment of truth rather than removing the risk. If a sender is unaligned, you will see it in the reports at p=none already, before any mail is quarantined. Thorough monitoring tells you everything pct would tell you, without ever junking a single legitimate message. Receivers also handle the percentage maths inconsistently, so your real-world enforcement rate may not match the number you wrote. And the newer DMARC specification work has deprecated pct altogether, a signal that the industry is moving away from it.
pct entirely, because thorough monitoring already gives us the certainty it is meant to provide. For a genuinely large or messy estate we will use it as a temporary safety belt, then remove it. Either way, pct is a transitional tool, never a destination.Subdomain policy and locking down what you do not use
An attacker who cannot spoof yourcompany.com will happily try marketing.yourcompany.com or some invented subdomain like accounts-payable.yourcompany.com, hoping a recipient will not notice the difference. By default, subdomains inherit the organisational domain policy, but the sp tag lets you set a separate, often stricter, policy for them.
The pattern we recommend is straightforward. Subdomains that actually send mail, such as a dedicated mail.yourcompany.com for a marketing platform, get their alignment fixed and follow the same staged path as the parent. Subdomains that send no mail at all, which is the vast majority of them, should be set to reject from the outset. There is no legitimate mail to break, so there is no downside, and you close off an entire category of look-alike abuse. A record such as v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourcompany.com enforces on both the parent and its subdomains. While you are at it, any domain you own but never send from, the classic parked domain, should publish p=reject immediately, because every message from it is by definition forged.
A typical timeline
People assume enforcement takes months. For a clean, standard setup it is closer to a week. The work is front-loaded into the monitoring stage, because that is where you discover and fix sources. Once alignment is in place, advancing the policy is a single DNS edit and a short observation window.
Complex estates take longer for one reason: each unaligned sender adds time, because someone has to configure DKIM or a custom return path inside that platform, and you have to wait for fresh reports to confirm the fix. The timeline is set by the slowest sender, not by DMARC itself. A business that mails through one provider can be at p=reject inside a week. A group with a dozen marketing tools, several regional offices, and a payroll system from 2009 will take a few weeks, and that is normal.
Holding at quarantine, then moving to reject
Quarantine is the stage where we deliberately slow down. The difference between quarantine and reject is the difference between a recoverable mistake and a hard bounce. If something legitimate is misclassified at quarantine, it lands in the recipient's spam folder, where it can still be found and rescued. At reject, the same message is refused at the SMTP layer and is simply gone. So we hold at quarantine until the reports show a stable, effectively 100% legitimate pass rate, with no surprises, across a representative window of normal sending.
Only then do we change the single word from quarantine to reject. Because the pass rate is already proven, this final step changes nothing for your real mail. It changes everything for the forgeries.
Quarantine is where you build confidence. Reject is where you cash it in. Never reach for the second until the first has gone quiet.
What enforced reject actually achieves
It is worth being concrete about what you get for the work, because p=none and p=reject can look like cosmetic variants of the same record. They are not. At p=none you can see spoofing in your reports, but you cannot stop it. The forged invoice from accounts@yourcompany.com still reaches the customer's inbox; you just get a report telling you it happened after the fact.
At p=reject, the receiving mail server refuses that forged message before it is ever delivered. The spoofer's email to your customer does not land in spam, it does not land at all. That is the mechanism that stops domain impersonation, and it is the entire reason DMARC exists. Everything before reject is preparation. Reject is the control doing its job.
Enforcement also opens up benefits that are not available at p=none. BIMI, which displays your verified logo next to your messages in Gmail, Apple Mail and Yahoo, requires DMARC enforcement at quarantine or reject before it works at all. Compliance frameworks expect it too. PCI DSS 4.0 requirement 5.4.1 made anti-phishing controls mandatory from 31 March 2025, and a monitor-only record does not meet the spirit of that. The bulk-sender rules from Google and Yahoo, in force since 1 February 2024, and the equivalent tightening Microsoft began applying for high-volume senders to Outlook.com, Hotmail and Live, all assume genuine authentication. Reaching enforcement puts you on the right side of every one of these.
Rollback safety: loosening instantly if anything is caught
The fear that keeps domains at p=none is the fear of an irreversible mistake. DMARC is not irreversible. Your policy lives in a single DNS TXT record, and changing it is one edit that propagates within minutes once caches expire. If you ever saw a legitimate source being affected, you would loosen the policy immediately, dropping from reject back to quarantine, or from quarantine back to none, while you fixed the underlying alignment. Nothing about enforcement traps you.
The honest caveat is that with alignment done properly, you should never need to. The reason we hold at quarantine and watch the pass rate is precisely so that the move to reject is a formality rather than a gamble. Rollback is the safety net you keep in your pocket and, in a well-run rollout, never have to use. But it is there, and knowing it is there is what makes it reasonable to enforce rather than hide at monitor forever.
p=none is not safe, it is merely watching its own impersonation in slow motion. The forged invoices still arrive. Enforcement is the only state that actually stops them.Where to begin
If you do not yet know which stage you are at, start by reading your current record. Run a free scan and it will show your policy value, whether you have a subdomain policy set, and whether your record is even being found. From there the path is the same for everyone: prove your senders align, watch the reports at p=none until the picture is clear, tighten to quarantine, hold until the pass rate is stable, then move to reject.
Enforcement is not a leap of faith. It is a sequence of small, observed, reversible steps, each taken only once the reports say it is safe. The destination, p=reject with an aligned set of senders and unused subdomains locked down, is the only configuration that genuinely stops people from sending mail in your name. Getting there is the whole job, and staged correctly, it is far less frightening than the spoofing it prevents.