DMARC Quarantine vs Reject — Which Policy Should You Use?

Once you move past p=none and start enforcing your DMARC policy, you face a choice: quarantine or reject. Both stop spoofed emails from reaching the inbox, but they handle failures differently and carry different levels of risk.

Quarantine sends failing messages to spam. Reject blocks them entirely. The right choice depends on how confident you are in your email authentication setup and how much risk you can tolerate. If you need a refresher on all three policy levels including p=none, start with our guide on DMARC policy levels. This guide breaks down both enforcement policies, explains when to use each one, and shows you how to transition safely.

What Quarantine Does

When your DMARC record is set to p=quarantine, receiving mail servers treat messages that fail authentication as suspicious. In most cases, that means the message goes to the recipient's spam or junk folder instead of the inbox.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com;

The message is still delivered — it just lands in a place where the recipient is less likely to see it and interact with it. If a legitimate email is accidentally quarantined because of a misconfigured service, the recipient (or their IT team) can find it in spam and recover it. That is the safety net quarantine provides.

The exact behavior varies by email provider. Gmail moves quarantined messages to the spam folder. Microsoft 365 may route them to the built-in quarantine or junk folder depending on the organization's settings. Smaller providers generally send them to spam.

Quarantine is effective against casual spoofing. Most phishing campaigns rely on messages landing in the inbox where recipients engage with them reflexively. Moving spoofed messages to spam dramatically reduces the chance that someone clicks a malicious link or replies with sensitive information. It does not eliminate the risk entirely — some people do check their spam folder — but it removes the message from the flow of normal email.

What Reject Does

When your DMARC record is set to p=reject, receiving mail servers block messages that fail authentication. The message is not delivered to the inbox, the spam folder, or anywhere else. It is refused at the server level.

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

The sending server receives a bounce notification explaining that the message was rejected due to DMARC policy. The intended recipient never knows the message existed. From a security standpoint, this is the strongest possible protection — spoofed messages simply do not get through.

Reject is the gold standard for domain protection. Security frameworks, vendor assessments, and email providers all recognize p=reject as full DMARC enforcement. If you are going through a SOC 2 audit, filling out a security questionnaire, or trying to qualify for cyber insurance, p=reject is what evaluators look for.

The tradeoff is that there is no recovery. If a legitimate message fails DMARC because of a misconfigured email service, an expired DKIM key, or an SPF record issue, that message is gone. The recipient never receives it, and you may not realize it was blocked until someone asks why your email never arrived.

Side-by-Side Comparison

When to Use Quarantine

Quarantine is the right choice when you are moving from monitoring to enforcement and want a safety net while you build confidence. Here are the specific scenarios where quarantine makes sense.

You are enforcing DMARC for the first time. After spending a few weeks at p=none collecting reports, quarantine is the natural next step. It starts protecting recipients from spoofed email while giving you room to catch any legitimate senders you might have missed.

You have a complex email setup. If your organization sends email through many different services — marketing platforms, CRM, transactional email, helpdesk tools, invoicing systems — there are more places where authentication can break. Quarantine lets you enforce without the risk of silently losing legitimate messages.

You have shared or third-party infrastructure. Some email services make it difficult to configure perfect SPF and DKIM alignment. If you are working with a provider that uses shared sending infrastructure or does not support custom Return-Path domains, quarantine gives you enforcement while you sort out the details.

You are not sure all your senders are authenticated. If there is any uncertainty — a recently added service, a legacy system, or a team that sends email from a tool you do not manage — quarantine protects you while you verify.

When to Use Reject

Reject is the right choice when you have full confidence in your authentication setup and want maximum protection. Here is when to use it.

All legitimate senders are passing DMARC. You have run at quarantine for several weeks, reviewed your aggregate reports, and confirmed that every legitimate email source is passing SPF or DKIM with proper alignment. No failures, no edge cases, no surprises.

You need maximum brand protection. If your domain is a target for phishing — financial services, healthcare, government, ecommerce, or any business where trust is critical — reject is the appropriate policy. It ensures that no spoofed message reaches any recipient, anywhere.

You are meeting compliance requirements. Security audits, vendor assessments, and regulatory frameworks often require p=reject specifically. For a full list of who mandates enforcement, see DMARC enforcement requirements. If you need to demonstrate full DMARC enforcement to a customer, auditor, or insurance provider, quarantine may not satisfy the requirement.

The domain does not send email. Parked domains, redirect domains, and domains you own but do not use for email should go straight to p=reject. There is no legitimate email to protect, so there is no risk. Publishing v=DMARC1; p=reject; on non-sending domains prevents attackers from using them for spoofing.

The Safe Path: None to Quarantine to Reject

The recommended approach is a gradual progression that minimizes risk at every stage.

Start at p=none. Collect aggregate reports for two to four weeks. Identify every service and IP address sending email as your domain. Fix any authentication issues you find — add missing services to your SPF record, configure DKIM signing, and verify alignment.

Move to p=quarantine with pct. Use the pct tag to roll out quarantine gradually:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com;

This applies quarantine to only 10 percent of failing messages. The rest are treated as if the policy were none. Monitor for a week. If nothing breaks, increase to 25 percent, then 50, then 100. Each step should include a week of monitoring.

Move to p=reject with pct. Once quarantine is at 100 percent with clean reports, start the same gradual process with reject:

v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@yourdomain.com;

Ramp up over several weeks until you reach pct=100 or remove the tag entirely (100 is the default). At this point, your domain is fully protected.

The entire progression typically takes 8 to 12 weeks for a straightforward setup. Organizations with many email sources or complex infrastructure may need longer.

Using pct for Gradual Rollout

The pct tag is the mechanism that makes safe transitions possible. It controls what percentage of messages that fail DMARC are subject to your policy. Messages not covered by the percentage are treated as if the policy were one level lower.

With p=quarantine; pct=25;, 25 percent of failing messages are quarantined and 75 percent are delivered normally. With p=reject; pct=25;, 25 percent are rejected and 75 percent are quarantined (not delivered normally — they drop to the quarantine level).

This means you are never jumping from no enforcement to full enforcement in one step. You are gradually increasing the scope while monitoring for problems in your DMARC reports. Our guide on how to read DMARC reports explains what to look for at each stage.

Check Your Current Policy

If you already have a DMARC record and are not sure what policy you are running, check it at dmarcrecordchecker.com. Many domains were set up with p=none years ago and never progressed. If that describes your domain, review your aggregate reports and start planning the move to enforcement.

For a deeper look at all three DMARC policy levels including p=none, see our guide on DMARC policy levels.

Monitor Your Email Authentication

You've set up your email authentication — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.