DMARC Policy Explained: none, quarantine, and reject (2026)

The single most misunderstood part of DMARC is also the most consequential: the policy tag. Set it wrong and you either leave your domain completely unprotected or accidentally block legitimate email from your own customers. Get it right and your domain is shielded from spoofing, your inbox placement improves, and you are compliant with every major mailbox provider's 2026 sender requirements.

DMARC has three policy levels — p=none, p=quarantine, and p=reject — and each one does something fundamentally different. This guide explains exactly what each policy does, what happens to email at each level, how to know when you are ready to move from one to the next, and the specific mistakes that cause legitimate email to get caught in enforcement.

What Is a DMARC Policy?

A DMARC policy is an instruction published in your domain's DNS that tells receiving mail servers what to do when an email claiming to come from your domain fails DMARC authentication.

DMARC authentication fails when an email does not satisfy either of these two conditions:

• SPF alignment — the domain in the From: header matches the domain in the SPF envelope-from, and SPF passes
• DKIM alignment — the domain in the From: header matches the d= domain in the DKIM signature, and DKIM passes

An email only needs to satisfy one condition to pass DMARC. If neither passes with alignment, the email fails DMARC — and the policy tag determines what happens next.

The policy tag lives inside your DMARC DNS record at _dmarc.yourdomain.com:

The p= value is the policy. It has exactly three valid options.

The Three DMARC Policy Levels

p=none — Monitor Only

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

What it does: Receiving mail servers evaluate the email against DMARC authentication rules but take no action based on the result. Emails that fail DMARC are delivered exactly the same as emails that pass. The only active function of p=none is generating aggregate reports — daily XML summaries sent to your rua= address showing every source that sent email using your domain, along with pass/fail results.

What it does NOT do: p=none provides zero protection against spoofing. An attacker sending phishing emails using your domain will pass straight through p=none with no interference. It is monitoring mode only.

When to use it: Always start here. p=none is the mandatory first step of every DMARC implementation. It gives you 2–4 weeks of report data to identify every legitimate sending source before you apply any enforcement that could affect real email.

Common misconception: Many senders publish p=none and consider DMARC "done." It is not done — it has not started. p=none is a data collection phase, not a security posture.

p=quarantine — Send Failing Email to Spam

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

What it does: Receiving mail servers take emails that fail DMARC and direct them to the recipient's spam or junk folder instead of the inbox. The email is still delivered — it is not rejected — but it is separated from legitimate inbox traffic.

What it does NOT do: p=quarantine does not block email. A determined attacker's spoofed emails still reach the recipient's mailbox — just in the spam folder, where most recipients never look. It is a significant improvement over p=none but not full protection.

When to use it: After 2–4 weeks of p=none monitoring, once your aggregate reports show that all legitimate sending sources are passing DMARC authentication consistently. Use p=quarantine as a two-week transition step before moving to p=reject — it catches any legitimate senders you may have missed during the monitoring phase.

Effect on inbox placement: Moving to p=quarantine sends a positive signal to inbox providers that you are actively managing your domain's email security. Gmail in particular has documented that authenticated domains with DMARC enforcement receive better inbox placement treatment than unenforced domains.

p=reject — Block Failing Email Entirely

What it does: Receiving mail servers reject emails that fail DMARC at the SMTP level — before the email is even delivered to any folder. The sending server receives a rejection notice (a 5xx SMTP error), and the email is never seen by the recipient. This is complete protection against domain spoofing.

What it does NOT do: p=reject cannot protect against lookalike domain attacks (e.g., an attacker registering m1gomail.com to impersonate migomail.com). It only protects your exact domain.

When to use it: After a successful p=quarantine period with no legitimate email caught, no new failing sources appearing in reports, and all known sending sources confirmed as passing. This is your end goal — the gold standard for domain protection.

Effect on inbox placement: Major inbox providers — Gmail, Outlook, Yahoo — give demonstrably better inbox placement treatment to p=reject domains. Google's Postmaster Tools v2 (2026) includes DMARC enforcement level as part of domain compliance scoring. Senders at p=reject are treated as the most trustworthy senders; senders at p=none are treated the same as unauthenticated domains for reputation purposes.

Compliance requirement: As of 2026, Google, Yahoo, and Microsoft all recommend p=reject for all bulk senders. p=quarantine meets the minimum bar; p=reject is the recommended standard.

Side-by-Side Comparison

The Correct Progression: How to Move Through All Three Levels

The single rule that prevents every major DMARC implementation mistake: never skip a level, and never rush a level.

Phase 1 — p=none (2–4 weeks)

Publish your DMARC record at p=none with a valid rua= address. Let the reports accumulate for at least two weeks — ideally four. During this phase, your job is to read the reports and identify every source sending email using your domain.

What to look for in your aggregate reports:

Every report entry shows a source IP address, the volume of email from that source, and whether SPF and DKIM passed or failed with alignment. Group your findings into three categories:

Category A — Legitimate sources, passing: Your ESP (Migomail), Google Workspace, and any other tools you have already configured SPF and DKIM for. These entries need no action.

Category B — Legitimate sources, failing: A CRM, a customer support tool, a newsletter platform, or any service you use to send email but have not yet authorised in your SPF record or configured DKIM for. These need to be fixed before you progress to enforcement. Add their SPF include to your SPF record and configure DKIM in each tool.

Category C — Unknown sources: IP addresses you do not recognise. These could be attackers spoofing your domain, or services you genuinely forgot about. Investigate each one. If you cannot identify a source as legitimate, it stays in this category and will be caught by enforcement — which is exactly what you want.

Do not progress to p=quarantine until Category B is empty — all legitimate sources must be passing before you enforce anything.

Phase 2 — p=quarantine (1–2 weeks)

Update the p= tag to quarantine. Continue monitoring your aggregate reports. For the first week, also check your own spam and junk folders daily — any legitimate email caught by quarantine will appear there.

Using pct= for a gradual rollout:

If you want extra caution moving from p=none to p=quarantine, use the pct= tag to apply the policy to only a percentage of failing emails:

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

This applies quarantine to 10% of failing emails — letting you see the effect before committing to 100%. Increase to pct=50 after 3–5 days, then pct=100 before moving to p=reject. Note: pct= only ever affects failing emails — your authenticated legitimate email is never touched regardless of the percentage.

Signs you are ready to move to p=reject:

• No legitimate email appears in your spam folder
• Aggregate reports show no new Category B sources
• Category C sources (unknown/spoofing) are consistently failing — as expected

Phase 3 — p=reject (ongoing)

Update the p= tag to reject. Continue monitoring reports indefinitely — new sending tools added to your tech stack, platform migrations, or DNS misconfigurations can introduce new failing sources at any time.

At p=reject, your aggregate reports shift character. Instead of showing you what to fix, they show you what is being blocked — giving you ongoing visibility into spoofing attempts against your domain.

What Happens to Your Legitimate Email During Enforcement

This is the question that keeps most senders at p=none indefinitely — fear of blocking legitimate email. Here is the reality:

Your legitimate email is completely safe at any policy level as long as it is properly authenticated. If Migomail is sending your campaigns and DKIM is configured in Migomail's authentication dashboard, every email Migomail sends using your domain passes DKIM alignment — and DMARC passes on that basis alone, regardless of SPF. You could set p=reject today and your Migomail campaigns would be completely unaffected.

The risk comes from sources you have not yet authenticated. The category B sources from your monitoring phase — the CRM that sends customer notifications, the support tool that sends ticket responses, the billing platform that sends invoices. If those are not passing SPF or DKIM alignment when you enforce, their emails will be quarantined or rejected.

This is why the monitoring phase exists. Fix category B completely before enforcing, and enforcement will never affect legitimate email.

The one situation where enforcement can surprise you: A new tool is added to your tech stack after you reach p=reject, and the person who adds it does not know it needs to be authorised in your SPF and DKIM configuration. Set up an alert in Migomail's hosted DMARC service so you are notified immediately whenever a new sending source appears in your reports — whether it is a new legitimate tool or a spoofing attempt.

The pct= Tag: Gradual Policy Rollout

The pct= tag (percentage) applies your policy to only a portion of failing emails. It is useful during the transition from p=none to p=quarantine, and from p=quarantine to p=reject, for senders who want to validate each step before committing fully.

How it works: Receiving servers randomly apply your policy to the specified percentage of failing emails. The remaining percentage is treated as if the policy were p=none. So p=quarantine; pct=25 quarantines 25% of failing emails and delivers the other 75% normally.

Important: pct= does not affect emails that pass DMARC. It only applies to the subset of emails that are already failing authentication. Your legitimate authenticated email is never affected by any pct= value.

Recommended rollout schedule:

Once you reach pct=100 at p=reject, you can remove the pct= tag entirely — it defaults to 100 when absent.

The sp= Tag: Subdomain Policy

By default, your root domain DMARC policy does not automatically apply to subdomains. An email from phishing@mail.yourdomain.com is evaluated against any DMARC record published at _dmarc.mail.yourdomain.com — not your root domain record — unless you use the sp= tag.

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

The sp= tag sets the policy applied to subdomains that do not have their own DMARC record. Setting sp=reject closes the subdomain spoofing gap — attackers cannot forge anything@subdomain.yourdomain.com and bypass your root domain's enforcement.

When subdomain-specific records override sp=: If a subdomain has its own DMARC record (e.g., _dmarc.newsletter.yourdomain.com), that record takes precedence over the sp= tag in the root domain record. Use subdomain-specific records when a subdomain has a different sending infrastructure or needs a different policy level.

Common DMARC Policy Mistakes

Staying at p=none permanently The most common mistake. p=none is a starting point, not a destination. It provides zero protection and zero inbox placement benefit. If your domain has been at p=none for more than four weeks without progressing, you are running DMARC without any of its actual benefits.

Jumping from p=none directly to p=reject Skipping p=quarantine leaves no safety net to catch legitimate sources you missed during monitoring. Even one overlooked sending tool — an invoice platform, an automated notification service — can result in business-critical email being rejected. Always use p=quarantine as a transition step.

Not reading the reports at p=none Publishing p=none without a valid rua= address, or setting one up but never reading the reports, means you are running DMARC blind. The reports are the entire point of the monitoring phase. If raw XML is difficult to process, Migomail's hosted DMARC service parses and presents them in a clean dashboard automatically.

Setting sp=none while at p=reject If your root domain is at p=reject but your sp= tag is none (or absent), subdomains are unprotected. An attacker can forge emails from any subdomain of yours without being blocked by enforcement. Always match your sp= level to your root p= level, or publish individual records per subdomain.

Thinking p=reject is too risky It is not — as long as the monitoring phase was completed properly. The risk of p=reject on a well-prepared domain is near zero. The risk of staying at p=none on a domain that appears in phishing campaigns is extremely high: damaged brand trust, potential blacklistings of your domain, and customer complaints about receiving phishing emails that appear to come from you. The risk calculation strongly favours enforcement.

DMARC Policy and Inbox Placement

Beyond security, DMARC policy level is a measurable deliverability signal. Here is how each level is treated by the major US inbox providers in 2026:

Gmail (Google) Google Postmaster Tools v2 includes a domain compliance score. Domains at p=reject with full SPF and DKIM alignment receive the highest compliance scores and are treated as the most trusted senders. Domains at p=none are scored the same as unauthenticated domains for reputation purposes — meaning the investment in DMARC setup delivers zero inbox placement benefit until enforcement begins.

Microsoft Outlook Microsoft's enforcement requirement (May 2026) means that bulk senders without at least p=quarantine face filtering. Domains at p=reject receive preferential treatment in Microsoft's Smart Network Data Services reputation scoring.

Yahoo Mail Yahoo treats p=reject as a strong positive trust signal. Combined with a clean complaint rate and consistent sending patterns, p=reject domains consistently achieve higher inbox placement rates at Yahoo than equivalent p=none domains sending identical content.

The practical implication: reaching p=reject is not just a security milestone — it is a deliverability upgrade. For more on how authentication interacts with inbox placement, see our email deliverability best practices guide.

Quick Reference: DMARC Policy Decision Guide

Use this to determine which policy level you should be at right now:

You should be at p=none if:

• You set up DMARC less than 2 weeks ago
• You have not yet identified all sending sources in your aggregate reports
• You still have Category B sources (legitimate senders failing authentication) to fix

You should move to p=quarantine if:

• You have been at p=none for 2–4 weeks
• All legitimate sending sources are passing DMARC in your reports
• No new unknown sources have appeared in the last 7 days

You should move to p=reject if:

• You have been at p=quarantine for 1–2 weeks
• No legitimate email has appeared in spam or junk folders
• All sources in your reports are either passing (legitimate) or failing (unknown/spoofing)
• Your pct= rollout has reached 100% without issues

You should stay at p=reject and monitor if:

• You are already at p=reject
• Aggregate reports continue to show clean results for all legitimate sources
• Set up alerts for any new failing sources that appear

Frequently Asked Questions

What is the difference between DMARC p=none and p=reject?
p=none is monitoring mode — receiving mail servers evaluate DMARC authentication but take no action on failing emails, which are delivered normally. It provides zero spoofing protection but generates daily aggregate reports showing every source sending email using your domain. p=reject is full enforcement — emails that fail DMARC are rejected at the server level before reaching any inbox or spam folder. It provides complete protection against domain spoofing. p=quarantine sits between them, sending failing emails to spam rather than rejecting them entirely. All three levels generate reports; only p=quarantine and p=reject apply actual policy to failing mail.

Will DMARC p=reject block my legitimate email?
Only if a legitimate sending source has not been properly authenticated through SPF or DKIM. If all sources sending email on behalf of your domain are configured with SPF alignment or DKIM alignment, p=reject has no effect on your legitimate email whatsoever — those emails pass DMARC and are delivered normally. The monitoring phase at p=none exists specifically to identify and fix any misconfigured sources before enforcement. A properly executed DMARC implementation reaches p=reject without ever blocking legitimate mail.

How long should I stay at p=none before moving to p=quarantine?
A minimum of two weeks, ideally four. You need enough report data to see a representative picture of all sources sending email using your domain. Some sources send infrequently — a monthly billing email, a quarterly report — and you may not see them in the first week of reports. Four weeks of data gives you a much higher confidence that the sources you have identified are complete. If you manage a large number of sending tools or have a complex email infrastructure, allow a full 30 days at p=none before progressing.

What is the pct= tag in a DMARC record?
The pct= tag specifies what percentage of failing emails the policy should be applied to. For example, p=quarantine; pct=10 quarantines 10% of failing emails and delivers the other 90% normally. It is used to roll out enforcement gradually — starting at a low percentage to validate that no legitimate email is being caught, then increasing to 100% before moving to the next policy level. The pct= tag only affects failing emails; emails that pass DMARC are never affected by the percentage setting.

Does DMARC p=reject affect email I send, or email others send to me?
DMARC policy controls what receiving servers do with email that claims to come from your domain — it affects emails sent by others (or by attackers) that use your domain in the From: header. It does not directly control how your own outgoing email is handled by recipient servers, except that having DMARC in place makes your legitimate outgoing email more trusted by those servers. When you send email through Migomail with proper DKIM configuration, that email passes DMARC at the recipient's server — meaning p=reject on your domain helps your deliverability rather than hurting it.

Summary

DMARC's three policy levels serve distinct purposes at different stages of your implementation:

• p=none — collect data, identify all sending sources, fix authentication gaps. Provides zero protection. Maximum duration: 4 weeks.
• p=quarantine — transition enforcement. Failing emails go to spam. Use for 1–2 weeks to catch any sources missed during monitoring.
• p=reject — full enforcement. Failing emails are blocked entirely. This is your destination — it is where DMARC's security and deliverability benefits are fully realised.

The path from p=none to p=reject takes 4–8 weeks for most organisations. The only thing that slows it down is failing to read the aggregate reports during the monitoring phase.

Migomail's hosted DMARC service processes your aggregate reports automatically, presents every sending source in a clear dashboard, and sends alerts when new sources appear — removing the manual XML-parsing step that most teams find the biggest barrier to progressing through policy levels.

Start your free trial to run a full DMARC audit on your domain and get a clear view of where you stand across all three policy levels today.