The question comes up constantly in IT forums, sysadmin Slack channels, and support tickets: “We’ve been on p=quarantine for months. Is it safe to move to p=reject yet?”
The honest answer is: it depends on what your aggregate reports are telling you. And most organisations are not reading them closely enough to know.
This is not a knock on IT teams. DMARC reports are dense XML files that were designed for machines, not humans. But the consequence of ignoring them is staying parked at quarantine indefinitely, under the assumption that something might break if you move forward. What organisations do not always consider is what continues to break while they wait: spoofed emails hitting their customers’ inboxes, brand impersonation going unchecked, and an increasingly thin justification as mailbox providers tighten enforcement.
As of Q2 2025, only around 4% of the world’s ten million most-visited domains have a fully enforced reject policy. More than half of all domains that have DMARC records at all are sitting at p=none. That is a significant gap between awareness and actual protection, and it matters more now than it did two years ago.
Why Quarantine Was Never Meant to Be a Destination
When DMARC was designed, the policy progression was intentional: start at none to gather data, move to quarantine to test enforcement with some safety margin, then advance to reject once you are confident in your mail flows. Quarantine was a proving ground, not a permanent home.
The reason organisations stall there is understandable. Reject is unforgiving. A message that fails DMARC under a reject policy is gone; it does not land in spam, it does not get reviewed by an admin, it simply does not arrive. That consequence feels heavy when you are not entirely sure every legitimate sender has been accounted for. A missed Salesforce subdomain, a payroll platform that was set up quietly by HR, an external agency sending campaign emails under your brand domain. Any of these can become a false positive under strict enforcement if they were never properly aligned.
So teams stay at quarantine. Months pass. The reports pile up in an inbox somewhere.
What is often not appreciated is that quarantine has its own failure mode. A failed message under quarantine does not disappear; it lands in spam, which means your customers might still read it, your recipients might still click it, and your domain still gets associated with junk. The impact on legitimate but non-compliant email can go unnoticed for long periods because the source never gets a hard bounce. Deliverability quietly degrades while no one is looking.
There is also a compliance dimension that did not exist a few years ago. As of 2025, DMARC is mandatory under PCI DSS v4.0 for organisations processing payment card data, and CISA BOD 18-01 requires p=reject for US federal domains. Microsoft began rejecting non-compliant email from high-volume senders in May 2025, joining Google and Yahoo who enforced the same requirements in 2024. Cyber insurance underwriters are now asking about DMARC policy levels during renewals. Staying at quarantine is a defensible starting point; staying there for two years is harder to justify.
What You Actually Need to Review Before Moving to Reject
The decision to move from quarantine to reject should be driven by data, not confidence. Confidence can be wrong. Data tells you where the gaps are.
Before making the switch, your aggregate reports need to show a clear picture across three dimensions.
Source coverage: Every IP address that sends email as your domain needs to be identified and either authorised or flagged as illegitimate. Look for sources that appear inconsistently: once a month, quarterly, during campaign periods only. These are the senders that get missed during initial audits because they are not active when you are looking. A minimum of 90 days of monitoring data is generally recommended before enforcing, specifically to catch monthly senders like invoicing systems, quarterly report distributions, and seasonal campaigns.
Alignment rate: Your aggregate reports will show you what percentage of mail from each identified source is passing SPF or DKIM alignment. Any legitimate source consistently failing alignment needs to be fixed before you flip to reject, not after. The fix is usually straightforward: adding the sending service’s domain to your SPF record, enabling custom DKIM signing in the platform, or updating the From header configuration. But it must happen first.
Subdomain behaviour: This is where many organisations make their most expensive mistake. If you set p=reject on your parent domain but leave subdomains unaddressed, attackers can continue spoofing subdomains instead. The sp tag controls subdomain policy separately and needs to be considered explicitly. A common and sensible configuration is to run p=reject on your primary domain while keeping sp=quarantine on subdomains during a transition period, especially if different teams manage different subdomains with different sending patterns.
The pct Tag and Why More Teams Should Use It
Most organisations treat the jump from quarantine to reject as a binary switch. It does not have to be.
The pct tag in a DMARC record lets you apply your enforcement policy to a specified percentage of failing messages. At pct=20 with p=reject, only 20% of messages that fail DMARC will be rejected; the rest fall back to quarantine. This gives you a controlled ramp-up where the consequences of any misconfiguration are limited.
The practical sequence looks like this: move to p=reject with pct=10, watch your reports for a week, increase to pct=25, watch again, then 50, then 100. Most well-prepared domains will see nothing alarming across that progression. The ones that do catch something will catch it at pct=10 rather than at pct=100, which is a considerably better place to find a problem.
This approach is particularly useful in large organisations with multiple business units, inherited domains from acquisitions, or complex third-party sender relationships. The pct ramp costs you almost nothing in complexity and buys you real insurance against the blind spots in your source inventory.
When Legitimate Mail Breaks Under Reject (And How to Interpret It)
Even with thorough preparation, some organisations will see legitimate mail fail under p=reject. The question is what to do about it.
The most common culprits are email forwarding and mailing lists. When email is forwarded, SPF alignment often breaks because the forwarding server is not in your SPF record. DKIM can also be invalidated if the forwarding host modifies the message body or certain headers. This is a known limitation of the current authentication infrastructure, and it is one of the problems that ARC (Authenticated Received Chain) was designed to address. If your organisation has significant inbound forwarding flows, particularly from partner organisations, distribution lists, or government recipients, this is worth investigating before you move to reject.
Mailing list behaviour is related. Many list management systems rewrite the From address or add footers that break DKIM signatures. The standard guidance is to ensure your outbound mail to these systems uses a domain that either supports DKIM re-signing or routes through an ARC-aware infrastructure.
None of these are reasons to stay at quarantine permanently. They are reasons to be specific about what you are fixing before you proceed. A broken forwarding path is a solvable problem. An unsolved forwarding path at p=reject is a deliverability incident.
The Pressure to Move Is Now Institutional, Not Just Technical
There is a broader shift happening in how DMARC policy levels are being treated by the industry. What was once a recommendation from security practitioners has become a hard requirement from infrastructure providers and regulators.
In May 2025, Microsoft began rejecting emails from high-volume senders that fail authentication, returning error 550 5.7.515 to non-compliant domains. Google and Yahoo implemented equivalent enforcement in February 2024. The three largest mailbox providers now all require authentication for bulk senders. If your domain is still at p=none, you are already behind. If you are at quarantine, you are compliant with the baseline, but you are not protected.
The data on enforcement outcomes makes this concrete. In the US, where government DMARC mandates exist, the percentage of phishing emails successfully reaching inboxes dropped from 68.8% in 2023 to 14.2% in 2025. In Qatar, where enforcement guidance is minimal, phishing exposure remained essentially unchanged over the same period. The difference is not the quality of the threat actors. It is the enforcement policy.
For organisations in the UAE and broader GCC, this context carries particular weight. The DESC (Dubai Electronic Security Centre) and national cybersecurity frameworks increasingly align with international best practices on email authentication. Financial institutions, government contractors, and enterprises handling sensitive customer data face a narrowing window before these requirements become mandatory rather than recommended.
A Practical Decision Framework
If you are trying to decide whether your domain is ready to move from quarantine to reject, the following questions will help you make a defensible case either way.
Have you been actively reading your aggregate reports for at least 90 days? If the honest answer is no, that is your first task, not your policy setting.
Are all sources sending above a meaningful volume threshold identified and documented? Shadow senders are the most common cause of false positives under reject. If you have not used a reporting platform to build a complete sender inventory, do that before you change your policy.
Is the alignment pass rate for your known legitimate senders consistently above 95%? If any legitimate source is failing regularly, fix the source. Do not move to reject with known alignment failures outstanding.
Have you considered the sp tag and made an explicit decision about subdomain policy? If you have not touched sp, moving the parent domain to reject may leave your subdomains exposed to continued spoofing.
If you can answer yes to all of these, your domain is ready. Use pct to ramp gradually, monitor your reports through the ramp, and move to pct=100 once you have confirmed there are no surprises.
The Cost of Getting This Wrong in Both Directions
There are two failure modes here, and they do not get equal attention. Most teams worry about the consequences of moving to reject too quickly and blocking legitimate mail. That is a real risk and a valid concern. But the consequences of staying at quarantine too long are just as real, and they are less visible.
Business Email Compromise losses reached $3.05 billion in 2025 according to the FBI’s IC3, making it the most financially damaging enterprise-targeted cybercrime for yet another consecutive year. The majority of BEC attacks exploit the trust that recipients place in sender identity. A domain at p=quarantine cannot stop an attacker from spoofing that domain. The message will reach the recipient’s spam folder. In a business context where people are under pressure and scanning quickly, that distinction matters less than it should.
A phishing email that lands in junk is not a phishing email that was stopped. It is a phishing email that arrived.
DMARCS gives you the aggregate report visibility you need to make this decision with confidence rather than instinct. Our dashboard translates raw XML data into a clear sender inventory, alignment scores by source, and a readiness assessment that shows you exactly what needs to be resolved before moving to enforce. If you are managing a domain in the UAE or GCC and want a clear view of where you stand before making a policy change, the dmarc analyser is a reasonable starting point.
