DMARC p=quarantine vs p=reject: Which Policy Should You Use?

What the two policies actually mean

A DMARC record tells receiving mail servers what to do when a message fails SPF and DKIM alignment. The p= tag has three valid values: none, quarantine, and reject. The first is a monitoring mode and does not protect anything. The other two are enforcement.

The practical difference is visibility. With quarantine, a legitimate mail that somehow ends up failing alignment still lands somewhere the recipient can recover it. With reject, the message is gone, and the sending user is responsible for spotting the bounce. For phishing protection that difference is exactly what you want, but during a rollout it can be dangerous.

Why most teams start with quarantine

Even when you have spent weeks cleaning up SPF and DKIM, there is almost always a legitimate sender you have missed. A third party payroll provider, a board member forwarding from a personal Gmail, an old e commerce platform that nobody remembers signing up to. The first few weeks at enforcement will surface these, and you want them to land somewhere recoverable.

Quarantine is the forgiving option. If you miss a legitimate sender, the mail goes to junk instead of vanishing. Users notice, report it, and you add the source to your authorised list. With reject, the first you hear about the problem is an angry phone call from someone who missed an invoice.

For organisations moving from p=none for the first time, quarantine is the right first enforcement stage. The safer approach is not to ramp pct= blindly, but to keep monitoring your aggregate reports after the switch and catch any legitimate sender that is still failing alignment. ShieldMarc flags these for you automatically so you do not have to dig through raw XML.

When reject is the right answer

Reject is the policy you want for domains where the risk of spoofing outweighs the cost of a false positive. That is the case more often than people assume. Specifically:

• Parked and alias domains. If a domain does not send legitimate email at all, it should be at p=reject from day one. There is nothing to break. Anyone sending from it is, by definition, an attacker. Our guide on parked domain protection covers this in more detail.
• Transactional only domains. If a domain is used exclusively by a tightly controlled transactional provider (for example, receipts.yourbrand.com via SendGrid), you can safely reach reject quickly because the authorised sender set is small and stable.
• Public sector and financial services. The downside of a phishing incident (regulatory reporting, reputation damage, fines) dwarfs the inconvenience of a missed legitimate email. Reject should be the target state.
• Any domain that is a frequent phishing target. If your brand shows up in phishing reports or your users receive spoofed mail, quarantine is not enough. Users do read their junk folder. Reject is the only policy that eliminates the message entirely.

The sp= tag: the trap everybody misses

The p= tag only applies to the organisational domain itself. Sub domains are governed by a separate tag, sp=. If you do not set sp, DMARC applies the same policy as p, but only for domains without their own DMARC record. This is where most enforcement strategies have a hole.

Consider a DMARC record like this:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com

This looks strong. The organisational domain is at reject, sub domains inherit that policy. But the moment an attacker targets unused.yourdomain.com, some receivers may still apply a more lenient default if the inheritance is ambiguous. The safest record sets the subdomain policy explicitly:

v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourdomain.com

Explicit sp=reject closes the inheritance gap and is the part we recommend for any mature deployment. Strict alignment (adkim=s, aspf=s) is an optional extra that eliminates some subdomain spoofing tricks, but add it only once your reports confirm every legitimate sender aligns exactly. The relaxed default (adkim=r, aspf=r) is safer for domains that rely on third-party senders, which often align on the organisational domain rather than the exact subdomain.

The rollout sequence we recommend

ShieldMarc's approach to enforcement is driven by actively reading the DMARC reports you are already receiving, not by ramping pct= blindly. The platform parses every incoming aggregate report, classifies every sender, and tells you exactly when the next stage is safe. The full step-by-step enforcement journey from p=none to p=reject looks like this:

1. Publish p=none and point rua at ShieldMarc. From the moment the record is live, aggregate reports land in your reports dashboard and are parsed automatically. You see every sender using your domain, aligned or not, within hours of the first report arriving.
2. Work the report inbox, not the clock. Instead of waiting a fixed number of weeks, actively read the reports as they arrive. ShieldMarc's threat scoring separates misconfigured legitimate services, forwarders, and genuine spoofing attempts so your team only acts on the senders that actually need attention. Authorise each legitimate source in the platform, fix its SPF or DKIM, and watch subsequent reports confirm the fix.
3. Move to p=quarantine when the reports are clean. Clean means every authorised sender is aligning, any unknown sender is either a threat or an edge case you have consciously accepted, and ShieldMarc has collected enough data to be confident (at least 10 reports over 14+ days). The platform flags readiness for you so you are not guessing.
4. Keep reading reports at quarantine. Moving policy does not mean you stop monitoring. New senders appear as services are added, providers rotate IPs, and forwarding patterns change. The ShieldMarc reports dashboard is where you notice these changes before they become a problem.
5. Move to p=reject when quarantine is stable. Same gate: reports clean, no unresolved unauthorised senders, and the readiness check in ShieldMarc is green. Set sp=reject at the same time to close the sub domain gap.
6. Keep the rua feed active indefinitely. DMARC is not a deploy-and-forget control. At reject, the reports are your early warning system for new spoofing attempts, broken third party senders, and policy regressions. ShieldMarc keeps the history so you can audit any change after the fact.

This sequence is the foundation of our a strong Security Grade path and is the approach we take for every domain onboarded to ShieldMarc.

What about pct= with reject?

A pattern you will see in older guides is p=reject; pct=50. This sounds like half of failing mail gets rejected, but the actual behaviour is more subtle. When pct is less than 100, the DMARC specification says receivers should apply the next softer policy to the remaining fraction. So p=reject; pct=50 is effectively 50 percent reject, 50 percent quarantine, not 50 percent reject and 50 percent deliver.

We do not recommend pct ramping as a rollout strategy. It hides real problems behind a probability and makes reports harder to read because the same sender can appear aligned or unaligned on different rows depending on which bucket the receiver randomly placed it in. If you know exactly how each legitimate sender is aligning, because you have been reading the reports, you do not need pct at all. Move when the data says it is safe, not when a percentage feels comfortable.

DMARCbis settles the argument for good. The pct tag is removed entirely (Appendix A.6 of RFC 9989) and replaced by a binary t= testing tag, where t=y tells receivers to apply the policy one step softer than stated (so p=reject; t=y is treated as quarantine). There is no percentage to ramp, which is exactly why the report-driven approach is the only one that still makes sense.

When you should stay at quarantine permanently

Quarantine can be a permanent destination. Some organisations choose to remain at quarantine as their terminal state, and that is a reasonable decision when:

• You have a long tail of low volume legitimate senders that are difficult to catalogue completely.
• You cross forward mail heavily through mailing lists or aliases (forwarding tends to break SPF, and DKIM survives only if signatures are not modified).
• Your users are technical and comfortable checking junk when something goes missing.
• Regulatory or audit requirements only mandate enforcement, not specifically reject.

Quarantine plus strict alignment still blocks the vast majority of spoofing attempts. The last few percent of hardening you get from reject is worth chasing when you can, but it is not an absolute requirement.

Next steps

• Check your current DMARC record with our free DMARC Checker. It tells you what policy you are on and whether your sp, adkim, and aspf tags are set correctly.
• Use the DMARC Generator to build a correct record with the right sp, pct, and alignment settings.
• Read our full guide on reading DMARC aggregate reports so you can make informed ramp decisions.
• Run a full Security Grade check to see where you sit across every email security layer.