From p=quarantine to p=reject without blocking real mail
How to tighten a DMARC policy in stages: move to p=quarantine, watch the reports, use t=y to test, and only reach p=reject once nothing legitimate is failing.
You reach p=reject by climbing, not jumping. Move from monitoring to p=quarantine, watch your reports until they are clean, then move to p=reject. Each step up only happens when the data says your own mail is safe. Rushing it is how businesses block their own invoices and newsletters, and it is entirely avoidable.
Why gradual beats fast
A DMARC policy (p=) tells receiving mail servers what to do with messages that claim to be from you but fail authentication. p=quarantine sends that failing mail to spam; p=reject refuses it outright so it never arrives. Both stop impersonation. The risk is not the attacker’s mail, it is yours: any legitimate sender you have not yet authenticated correctly gets caught in the same net.
Climbing in stages gives you a safety margin at every point. Under p=quarantine, a message you accidentally break lands in the recipient’s spam folder, where it can still be found and where you will see the failure in your reports. Under p=reject, that same message is gone. So you use quarantine as the rehearsal: if a stream of your mail is going to fail, you would much rather discover it as spam than as a bounce.
The staged path
Assuming you have already spent a few weeks on p=none collecting aggregate reports, which is covered in start with p=none, the sequence from here is short.
Step one: move to p=quarantine
Change your record’s policy tag to p=quarantine. A typical record at this stage reads:
v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com
Now receivers begin routing failing mail to spam. Watch the aggregate reports closely for a couple of weeks. What you are checking is simple: is any legitimate source now failing? If your marketing platform or your accounting tool suddenly shows failures, that is a sender you have not authenticated properly, and it needs fixing before you go further. If the reports stay clean, meaning the only failures are mail you do not actually send, you are ready for the last step.
Step two: move to p=reject
Change the tag to p=reject:
v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com
This is the goal. Failing mail is now refused at the receiver, so a spoofed message using your domain never reaches the inbox. Keep the reports running even after you get here, because your sending setup changes over time. A new tool, a migrated mail server, or an expired DKIM key can all reintroduce failures, and the reports are how you catch them.
Testing with t=y
DMARCbis, the current version of the standard published in May 2026 (RFC 9989 and its companions), gives you a dedicated way to say “I am still testing this policy”: the t= tag. Setting t=y signals to receivers that you are in a testing phase, so they can apply your policy while treating it as provisional. You might publish:
v=DMARC1; p=reject; t=y; rua=mailto:reports@yourdomain.com
That says: my policy is reject, but I am testing, so tread carefully. Once you are confident, you drop the tag (or set t=n, the default) and the policy stands on its own.
What happened to pct
If you have read older DMARC guides, you will have seen the pct tag, which let you apply a policy to only a percentage of mail, say 10 percent at first, then more. DMARCbis removed pct from the standard entirely. It is not deprecated, it is gone, along with ri and rf. The t=y testing signal is the replacement for that staged-rollout behavior: instead of gambling a slice of your mail, you tell receivers plainly that you are testing.
One honest caveat. Because DMARCbis is recent, not every receiver has updated, and some older ones may still honor a pct tag if you publish one during a transition. So you may see guidance that still uses it. Treat pct as a legacy fallback that some receivers respect and others ignore, and treat t=y as the correct, standards-based way to signal testing going forward. Do not rely on pct alone to protect you, because a modern receiver will simply skip it and apply your full policy.
Only move up when the reports are clean
This is the one rule that matters more than the rest. Do not advance to the next policy level on a schedule or a hunch. Advance when the aggregate reports show that every legitimate source is authenticated and aligned, and the only mail failing is mail you did not send.
“Clean” is worth defining precisely, because it is easy to fool yourself. It does not mean zero failures. There will almost always be some failing mail, because spoofers and misconfigured forwarders exist and you cannot make them stop appearing in your reports. Clean means every failure you can trace back to a real system of yours has been fixed, and what remains is mail you do not recognize. If you are staring at a source that is failing and you cannot tell whether it is yours, you are not ready to tighten. Resolve it first.
The trap here is that reading raw reports to make that judgment is genuinely hard, and plenty of rollouts stall at exactly this point because the data is too painful to interpret. That is where a monitoring service earns its place: it turns the reports into a plain answer to the only question that matters, which is “is it safe to tighten yet?” We make the case for that in why use a DMARC service.
The finish line
p=reject is where impersonation actually stops. Everything before it, p=none and p=quarantine, is preparation and safety. Take the climb one rung at a time, let the reports tell you when to step up, and use t=y while you are testing. The full journey with each checkpoint is mapped out in the path to p=reject. Done this way, reaching enforcement is a controlled process, not a leap of faith.