DMARC Policies Explained: p=none, p=quarantine, and p=reject

Every DMARC record contains a policy tag. That tag tells receiving mail servers what to do when they receive an email that fails DMARC authentication. Three options: doing nothing, marking the message, or blocking it entirely.

This post explains what each policy does in practice, what changes at each level, and how to move from a permissive policy to a strict one without breaking legitimate email.

What the DMARC policy tag does

The policy tag is the p= value in your DMARC DNS record. When a receiving server evaluates an incoming email, it checks SPF, DKIM, and DMARC alignment. If all of those pass, the email is delivered normally. If any of them fails, the receiving server checks your DMARC policy tag and decides what to do next.

Three values: p=none, p=quarantine, p=reject.

p=none: monitoring without action

p=none tells the receiving server to take no specific action on failing email. The message goes through normal handling, which usually means it gets delivered.

This is the policy most organizations start with. It is useful for collecting aggregate reports and understanding your email landscape before making any changes. With p=none, you get data on what is sending as your domain without affecting delivery.

There is a common misconception that p=none means nothing happens. That is not quite right. What happens is the normal thing: the email gets delivered. The policy simply does not add any special handling for authentication failures.

The real purpose of p=none is measurement, not security. You are watching what your domain is doing before you decide whether anything needs to change.

p=quarantine: failing email gets marked

p=quarantine tells the receiving server to treat failing email differently from normal email. What "differently" means varies by provider.

At Google and Gmail, failing email gets routed to the spam folder. At Microsoft and Outlook, it typically goes to the junk folder or gets held in quarantine depending on the tenant settings. Other providers may defer the message, mark it with a warning header, or handle it differently.

This matters because "quarantine" is not a standardized action across the industry. When you set p=quarantine, you are handing each provider a vague instruction. Some deliver it to spam. Some hold it. Some do something else.

If you rely on p=quarantine to protect your users from fraudulent email, know that the protection is uneven and inconsistent. A message that lands in someone's spam folder at Gmail might land in their inbox at another provider.

The practical use of p=quarantine is as a transitional policy. You use it after you have reviewed aggregate reports and identified legitimate senders, but before you are confident enough to move to p=reject.

p=reject: failing email gets blocked

p=reject is the strictest DMARC policy. When a receiving server receives an email that fails DMARC authentication, it refuses to deliver it. The message is bounced back to the sender. No delivery attempt is made.

This is the policy you want if your goal is to prevent email spoofing of your domain. When p=reject is in place and working correctly, no email that fails DMARC alignment reaches any recipient at a participating domain.

The catch is that p=reject only protects against DMARC failures. If SPF and DKIM are both passing and aligned, the email is delivered normally regardless of the policy setting. p=reject does not make good email bad. It only blocks the bad email that fails authentication.

For most organizations, p=reject is the target policy. The reason not everyone sets it immediately is that email breakages are common when legitimate senders are not fully authenticated. Jumping to p=reject without preparation will break legitimate email.

The safe migration path

Most organizations follow a staged approach.

Stage 1: p=none. Publish p=none and collect aggregate reports for at least 4 to 8 weeks. Review the data. Identify all legitimate sources sending as your domain. Confirm that SPF and DKIM are passing for each one.

Stage 2: p=quarantine. Move to p=quarantine once you have documented your legitimate senders and resolved any authentication failures in the data. Stay here for 2 to 4 weeks minimum. Watch for any legitimate email that stops reaching its destination.

Stage 3: p=reject. Move to p=reject once p=quarantine produces no unexpected delivery issues and the aggregate reports show consistent authentication pass rates for your legitimate senders.

The timeline varies by organization. A small business with a single email provider might complete this in a month. A large organization with multiple third-party senders, marketing platforms, and internal systems may need several months of monitoring at each stage.

Reading aggregate reports manually is time-consuming and easy to defer. That deferral is where most migration plans stall. The organizations that successfully reach p=reject are the ones that have automated the report parsing. DMARCFlow parses aggregate reports automatically, surfaces authentication failures, and tracks pass rates over time, so the migration decision is based on data rather than guesswork.

Warning signs before moving to p=reject

Before you switch to p=reject, the aggregate reports should show:

• All legitimate sending sources are passing SPF or DKIM alignment
• No unexpected spikes in authentication failures
• Third-party senders using your domain are properly authenticated
• No history of intermittent failures from cloud platforms or CRM tools

If you see anything unusual in the reports, resolve it before proceeding. The most common breakage after setting p=reject comes from marketing platforms, CRM systems, and internal tools that send email on behalf of your domain without proper authentication. These senders often go unnoticed until p=reject makes their failures visible.

What a DMARC failure looks like under each policy

Under p=none, a DMARC failure is invisible to the end recipient. The email arrives normally. The only evidence is in your aggregate reports.

Under p=quarantine, the recipient may not see the email arrive. At Gmail it goes to spam. At Microsoft it may go to junk or get held. You hear about it when someone asks why their expected email did not arrive.

Under p=reject, the email is blocked at the SMTP level. The sending server receives a bounce message. The recipient never sees the email. This is the most visible failure mode and the one most likely to generate complaints.

FAQ

Can I set p=reject immediately?

You can, but doing so risks breaking legitimate email that is not properly authenticated. Most organizations discover senders they did not know were using their domain once they start reviewing aggregate reports. Setting p=reject before identifying those senders means their email gets blocked without warning.

How long should I stay at p=none before moving to p=quarantine?

At minimum, collect enough data to account for all legitimate senders. This typically takes 4 to 8 weeks for organizations with regular email volume, longer if your sending patterns are complex or involve many third-party platforms.

What does p=quarantine actually do at Gmail versus Microsoft?

Gmail routes failing email to the spam folder. Microsoft routes it to junk or holds it in quarantine depending on tenant settings. Other providers handle it differently. The standard does not mandate a specific action, so behavior varies.

How do I know if p=reject will break legitimate email?

Review your aggregate reports thoroughly. If any legitimate sender has consistent authentication failures, resolve those before setting p=reject. Any sender that is not passing SPF or DKIM alignment represents a potential breakage.

Does p=reject stop all email spoofing?

It prevents email that fails DMARC from being delivered to participating domains. It does not prevent spoofing that passes DMARC alignment, and it does not protect recipients at non-participating domains. It is the strongest available DMARC policy, but it is not a complete solution to all email fraud.

Can third-party email senders break when I set p=reject?

Yes. Any third-party platform that sends email on behalf of your domain and is not properly authenticated will cause bounce-back failures when you set p=reject. Common examples include marketing automation platforms, CRM systems, and internal IT tools that relay email through external services.