DMARC Quarantine vs Reject: Which Policy to Run While Sending Cold Email
Quarantine is recoverable and reject is not. What each does to failing mail, and why your outbound domains can carry a different policy from your primary.
DMARC quarantine tells receivers to accept failing mail but mark it, usually into spam. Reject tells them to refuse it outright. Quarantine is recoverable because a missed legitimate sender lands in a folder, while reject means that mail is gone, which is why enforcement moves through quarantine first.
Key takeaways
- Quarantine sends failing mail to spam, where a sender you missed is recoverable. Reject discards it, and nobody finds out until someone reports a missing message.
- Your outbound sending domains and your primary company domain can and should carry different policies, because they carry different risk.
- Microsoft records the outcome in Authentication-Results as action=quarantine or action=oreject, so you can confirm what a receiver actually did.
- Stage by subdomain and by time rather than by percentage: pct is deprecated in the 2026 specification even though vendor documentation still recommends it.
Reviewed and updated August 10, 2026
Your aggregate reports have been clean for a month, every legitimate sender signs with DKIM, and the next change to the DNS record is a choice between two words. p=quarantine and p=reject are both enforcement. They are not interchangeable, and the difference between them shows up on the day you get something wrong rather than on the day you publish.
This assumes you are already past monitoring. What each policy value instructs receivers to do, and why p=none is the correct place to start, is covered in DMARC policy not enabled. What follows starts from the point where you have decided to leave monitoring behind and have to pick the landing spot.
What each policy does to a failing message
The two instructions differ in one respect that determines everything else: whether the message still exists somewhere after the receiver applies the policy.
Under p=quarantine, the receiving server accepts the message and treats it as suspicious. At consumer mailbox providers that usually means the junk folder. In corporate environments it can mean an administrative quarantine that a mail admin reviews. Either way the message was delivered, it is sitting somewhere, and a person can go and get it.
Under p=reject, the receiving server refuses the message. The sending side gets a bounce, the recipient is never told anything happened, and there is nothing to retrieve. The message stops existing at the boundary.
- Receiver accepts the message and marks it suspicious
- Lands in junk, or an admin quarantine in corporate tenants
- A recipient who goes looking can find it
- A missed legitimate sender surfaces as a complaint, which is information
- Spoofed mail still reaches the mailbox, just not the inbox
- Receiver refuses the message during the SMTP conversation
- Nothing is delivered and nothing is stored
- The recipient is never aware a message was sent
- A missed legitimate sender surfaces as a bounce on the sending side, if anyone is watching
- Spoofed mail claiming your domain does not arrive at all
The security difference is real and it favours reject. If somebody is spoofing your domain to phish your customers, quarantine still puts the phishing attempt in their mailbox where a determined person can dig it out of junk. Reject removes it.
The operational difference favours quarantine, and it is the one people underweight. Enforcement failures are almost never dramatic. They are a payroll notification, a booking confirmation from a tool a department signed up for in 2023, or an invoicing platform whose DKIM key rotated. Under quarantine, somebody eventually says the invoice went to spam and you fix it. Under reject, the same message vanishes and the complaint arrives weeks later as a question about why a customer never received their receipt.
What the receiver actually records
The policy value is your instruction. What matters for diagnosis is what the receiving server writes down about applying it, and Microsoft documents its side of that explicitly in the Authentication-Results header it stamps on inbound mail.
The action values Microsoft records are action=none, action=quarantine, action=oreject (where the "o" stands for origin), action=pct.quarantine and action=pct.reject. A related value worth recognising is dmarc=bestguesspass, which means no DMARC record was published for the From domain at all and Microsoft inferred a pass from the other signals.
Two things fall out of that list. The first is that the header tells you which policy was applied, so a message you expected to be rejected and which shows action=quarantine is telling you the receiver read a different record than the one you think you published. The second is the existence of the pct. prefixed values, which exist because percentage-based staging was part of the original specification, and which lead directly into the most annoying open question in a 2026 rollout.
The pct problem, stated honestly
The classic rollout advice is to publish p=quarantine; pct=10, watch, then step through 25, 50, 75 and 100 before touching p=reject. Microsoft's own configuration documentation still recommends exactly that, and still cites RFC 7489.
The IETF published the updated DMARC specification on 20 May 2026: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting, together obsoleting RFC 7489. In that revision, pct= is deprecated, along with rf= and ri=.
Both of those statements are true at once, and it is a genuine tension rather than a documentation lag you can safely ignore. Deprecated tags are ignored by receivers rather than treated as errors, so a record containing pct= keeps working today and will keep working for a long time. Building a new rollout plan on a deprecated tag is still a bad trade, because the whole point of percentage staging is to control blast radius, and a control that some receivers honour and others discard is not a control.
There are two staging axes that survive the deprecation, and between them they do the job that pct= was doing.
- Step 1A low-volume subdomain first
Pick a subdomain that sends something real but small, such as notifications or a single internal tool, and enforce there. Microsoft recommends this order explicitly.
- Step 2Your outbound sending domains next
Each one has a single sending platform behind it, so the set of things that can break is small and known.
- Step 3Sit at quarantine and read reports
A fortnight is the usual minimum. This is the window where a sender nobody remembered shows up as recoverable junk rather than as a bounce.
- Step 4The parent domain last
It carries the most senders, the most history and the most risk, which is exactly why it goes at the end rather than the beginning.
Staging by domain gives you a defined population per step. Staging by time gives every receiver a chance to report before you tighten again. Neither depends on a tag whose future is settled against it.
The cold email wrinkle: your domains do not have to agree
This is the part that changes the decision for anyone running outbound, and it gets missed because the question is usually framed as though a company has one domain and one policy.
Outbound sending belongs on domains that are separate from your primary company domain, so that a reputation problem in one place cannot reach the other. DMARC is published per domain. Those two facts together mean your primary domain and your sending domains can carry different policies, and in most cases they should.
On the primary domain, the argument for reject is strong. It is the domain your contracts, invoices and support replies come from, it is the one worth spoofing, and after a proper monitoring phase you know every service that sends as it. The recoverability of quarantine matters most here, which is why the parent goes last, but reject is the destination.
On a dedicated sending domain, the calculation inverts in an interesting way. That domain has one sending platform, one SPF include and one DKIM key. Almost nothing can legitimately send as it except the tool you pointed at it. The population of senders you might have missed is close to empty, which is the whole reason enforcement is easy there.
The failure mode is also louder. If DKIM breaks on a sending domain under reject, your sending platform starts logging bounces immediately and the campaign visibly stops. Under quarantine, the same break sends the entire campaign to junk, and low reply rates look identical to ordinary deliverability decay for a week or two before anyone diagnoses it. Reject on a single-purpose sending domain buys you a fast, unambiguous alarm.
- Yes: Reports have been arriving for at least a month and somebody has read them
- Yes: Every source with real volume has been identified and authenticated
- Yes: The domain has sat at p=quarantine long enough for a full reporting cycle
- Yes: SPF on this domain resolves inside the ten-lookup limit
- Yes: Someone owns the reports after the change, not only before it
- No: The plan depends on pct= stepping to control blast radius
- No: This is the parent domain and the subdomains have not been done yet
- Depends: A subdomain policy via sp= is needed because subdomains differ from the parent
The SPF line in there deserves a note, because it is the failure that turns a routine enforcement change into an outage. DMARC passes when either SPF or DKIM passes and aligns. A permerror on SPF removes half of that redundancy and leaves DMARC resting on DKIM alone, so a key rotation that would otherwise have been survivable takes the domain to zero under reject. The lookup arithmetic behind permerror is in SPF records for cold email, and it is worth checking before rather than after.
Parked domains are the easy case
Domains you own and never send from are the one situation with no tradeoff at all. There is no legitimate mail to break, so there is nothing to recover, so the recoverability argument for quarantine does not apply. Microsoft's guidance for parked and unused domains is to publish v=DMARC1; p=reject; directly.
If you buy domains for outbound in batches and only ever activate some of them, the inactive ones are parked domains and should be at reject from the day you register them. This is the cheapest security win in the whole exercise and it is skipped constantly, because a domain nobody sends from is a domain nobody thinks about.
Making the decision
Reject is the destination for every domain you own. The only real question is how long you spend at quarantine on the way there, and the answer is set by how many distinct services can legitimately send as that domain.
For a parked domain, the answer is zero and you can publish reject today. For a purpose-built outbound sending domain with one platform behind it, quarantine for a reporting cycle is enough, and the fast bounce feedback under reject is an argument for not lingering. For a primary company domain that has accumulated a decade of tools, quarantine is where you find out what you missed, and rushing past it is how a legitimate sender disappears silently.
The reporting side is what makes any of this decidable, and it has its own setup traps that stop reports arriving at all. Getting the pipeline working is covered in DMARC aggregate reports, and the field-by-field walkthrough of what arrives is in how to read DMARC reports. If your mail runs through Microsoft 365, the tenant-specific procedure and its inheritance gotcha are in setting up DMARC on Microsoft 365.
The short version
Quarantine and reject are both enforcement, and the difference is recoverability. Quarantine delivers a failing message somewhere retrievable, so a legitimate sender you missed becomes a complaint you can act on. Reject refuses it at the boundary, so the same mistake is invisible to the recipient and shows up only as a bounce on the sending side. Microsoft records which was applied in the Authentication-Results header, using action=none, action=quarantine, action=oreject, action=pct.quarantine and action=pct.reject.
Microsoft still recommends pct= staging while the May 2026 RFCs deprecate the tag, so stage by subdomain and by time instead: a low-volume subdomain first, outbound sending domains next, a full reporting cycle at quarantine, and the parent domain last. Because DMARC is published per domain, your outbound sending domains and your primary domain can sit at different policies, and a single-purpose sending domain reaches reject far sooner than a domain carrying a decade of tools. Parked domains go straight to p=reject.
We run sending domains, authentication and the reporting that sits behind these decisions as part of our outbound engagements. You can see what a campaign would look like for your market.
Microsoft 365 behaviour and recommendations are per Microsoft's DMARC configuration documentation as of August 2026. Specification details are per RFC 9989, 9990 and 9991, published 20 May 2026. Verify current guidance with the official sources before making DNS changes.
Sources: Set up DMARC to validate the From address domain, Microsoft Learn, IETF publishes updated DMARC specification, dmarc.org
Frequently asked questions.
Frequently asked questions- Should I use DMARC quarantine or reject?
- Move to quarantine first and stay there long enough to see a full sending cycle in your reports. Quarantine puts failing mail in spam, so a legitimate sender you missed is recoverable. Reject discards the message outright, which is only safe once your reports show no unexplained sources.
- What is the difference between p=quarantine and p=reject?
- Quarantine asks the receiving system to accept the message but treat it as suspicious, typically delivering it to the junk folder. Reject asks the receiver to refuse the message during the SMTP conversation, so it is never delivered anywhere. Both apply only when DMARC fails.
- Can different domains have different DMARC policies?
- Yes, and they usually should. A strict reject policy suits the domain your contracts and invoices come from. Outbound sending domains are separate precisely so a problem in one cannot reach the other, and each domain publishes its own record independently.
- Is pct still the right way to roll out DMARC?
- It is widely documented and now deprecated. The 2026 specification makes pct historic, while some vendor documentation still recommends stepping through percentages. Receivers ignore deprecated tags rather than rejecting the record, but new rollouts should stage by subdomain and by elapsed time instead.
About the author.
Tim Carden is CMO / CTO at RevenueFlow, which builds and operates outbound revenue engines for B2B companies. Studied at McGill University.
Tim Carden · CMO / CTO
Connect on LinkedIn →Explore more.
Ready to scale your outreach?
We build GTM engines that book real meetings. See the receipts.
Related articles.
Why Your DMARC Is Failing: The Six Causes in Order of Likelihood
Six causes of DMARC failure, ordered by how often they occur, with the symptom in reports and the fix for each. Alignment accounts for most of them.
Set Up DMARC on Microsoft 365: The Records, the Rollout, and the Gotchas
Microsoft manages DMARC for onmicrosoft.com domains and not for your custom ones. The records, the rollout order, and the subdomain rule that differs from SPF.