DMARC Policy Levels: None vs Quarantine vs Reject

Every DMARC record has a policy tag that tells receiving mail servers what to do when an email fails authentication. There are exactly three options: none, quarantine, and reject. Choosing the right one — and knowing when to move between them — is the most important decision in your DMARC implementation.

Pick too aggressively and you block your own legitimate emails. Stay too cautious and spoofed messages keep reaching your customers' inboxes. This guide explains each level in plain language, helps you decide which one to start with, and shows you how to safely move toward full protection.

The Three DMARC Policy Levels

p=none — Monitoring Only

The none policy tells receiving mail servers to take no action on emails that fail DMARC checks. Messages are delivered normally regardless of whether they pass or fail SPF and DKIM alignment.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

This might sound pointless, but it is the most important starting point. With p=none and a rua reporting address, you start receiving aggregate reports from every major mail provider. These reports tell you which IP addresses are sending email as your domain and whether those messages are passing authentication.

Who should use p=none: Anyone setting up DMARC for the first time. If you have never had a DMARC record before, you do not know which services are sending email on your behalf. Your marketing platform, CRM, transactional email service, helpdesk tool, and invoicing system may all be sending as your domain. Jumping past none risks breaking all of them.

How long to stay at p=none: At least two to four weeks. You need enough time to receive reports from all major mailbox providers and identify every legitimate sender. If your organization sends email from many different services, you may need six to eight weeks to catch everything.

p=quarantine — Suspicious Emails Go to Spam

The quarantine policy tells receiving servers to treat failing messages as suspicious. In practice, this usually means routing them to the recipient's spam or junk folder instead of the inbox.

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

This is the middle ground between doing nothing and blocking messages outright. Your legitimate recipients can still find quarantined emails in their spam folder if something goes wrong with your authentication setup. It gives you a safety net while you enforce your policy.

Who should use p=quarantine: Organizations that have reviewed their DMARC reports at p=none, confirmed that all legitimate senders are passing SPF or DKIM, and are ready to start enforcing. This is the natural second step.

What happens to failing emails: The receiving server marks them as spam. The exact behavior varies by provider. Gmail moves them to the spam folder. Microsoft 365 may move them to junk or quarantine depending on the tenant settings. Some smaller providers may handle quarantine differently, but the message is never silently delivered to the inbox.

p=reject — Failing Emails Are Blocked

The reject policy is the strictest option. It tells receiving servers to refuse delivery of any email that fails DMARC alignment. The message is not delivered to the inbox, spam folder, or anywhere else. It is simply blocked.

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

This is the goal for every domain. When you reach p=reject, anyone who tries to spoof your domain will have their messages blocked before they ever reach a recipient. This protects your customers, your brand, and your domain's sending reputation.

Who should use p=reject: Organizations that have successfully run at p=quarantine for several weeks with no reports of legitimate email being affected. Also, any domain that does not send email at all — parked domains, redirects, and unused domains should go straight to p=reject since there is no legitimate mail to protect. For a deeper look at how these two enforcement levels compare in practice, see our quarantine vs reject comparison.

What happens to failing emails: They are dropped. The sending server receives a bounce notification explaining that the message was rejected due to DMARC policy. The intended recipient never sees the message at all.

Comparing the Three Levels

The Path from None to Reject

Moving from p=none to p=reject is not something you do overnight. It is a process that should take several weeks to a few months depending on the complexity of your email setup. Here is the recommended path.

Phase 1: Monitor with p=none (Weeks 1-4)

Set your initial DMARC record to p=none with reporting enabled. Collect aggregate reports and identify every service and IP address sending email as your domain. For each sender you find, verify it is legitimate and confirm it is passing either SPF or DKIM alignment.

Common legitimate senders you might discover include your email marketing platform (Mailchimp, Constant Contact, SendGrid), your CRM (HubSpot, Salesforce), transactional email services, helpdesk tools, and your web hosting or application server. Ecommerce businesses often have more sending sources than expected because of order notifications, shipping updates, and review requests that each require authentication.

For any sender that is failing, fix the authentication. Add their IP ranges to your SPF record or configure DKIM signing through that service. You can verify your current record at any time using dmarcrecordchecker.com.

Phase 2: Gradual Quarantine (Weeks 5-8)

Once all legitimate senders are passing, move to quarantine with a low percentage:

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

The pct=10 tag means only ten percent of failing messages get quarantined. The other ninety percent are still delivered normally. This limits the damage if you missed a legitimate sender.

Monitor for a week. If no one reports missing emails, increase to pct=25, then pct=50, then pct=100. Each increase should come with a week of monitoring.

Phase 3: Move to Reject (Weeks 9-12)

After running at p=quarantine; pct=100; with clean reports, switch to reject with a low percentage:

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

Follow the same gradual increase. Once you reach p=reject; pct=100; you can drop the pct tag entirely since 100 is the default:

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

This is your final state. Your domain is now fully protected against spoofing.

Using the pct Tag for Gradual Rollout

The pct tag is your safety valve during enforcement. It controls what percentage of failing messages the policy applies to. Messages not covered by the percentage are treated as if the policy were one level lower — so p=reject; pct=50; means fifty percent of failures are rejected and fifty percent are quarantined.

This is why gradual rollout works. You are never going from zero enforcement to full enforcement in one step. You are slowly increasing the scope while watching for problems.

When to Check Your Current Policy

If you already have a DMARC record and are not sure what policy you are running, check it with dmarcrecordchecker.com. Many domains were set up with p=none years ago and never moved forward. If that is you, now is a good time to review your reports and start the path toward enforcement.

If you are setting up DMARC from scratch, our DMARC setup guide covers the full end-to-end process. And if you need to understand the technical structure of DMARC records before choosing a policy, start with our what is DMARC overview. Agencies managing DMARC policies across client domains can find tailored guidance in our DMARC for agencies guide.

Monitor Your New DMARC Record

You've created your DMARC record — 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.