DMARC Policy Explained: None, Quarantine, and Reject

Your DMARC policy tells email providers what to do when someone sends an email that fails authentication. Choose the wrong policy and you might block your own legitimate email. Choose too weak a policy and you're not actually protected.

Here's how to pick the right one.

The Three DMARC Policies

Every DMARC record includes a policy tag (p=) that specifies how receiving servers should handle emails that fail DMARC checks. There are exactly three options:

p=none - Deliver the email anyway. The receiving server logs the failure but takes no action. You get reports about what's happening.

p=quarantine - Treat the email as suspicious. It typically ends up in the spam or junk folder instead of the inbox.

p=reject - Block the email entirely. It never reaches the recipient at all.

Each policy represents a different level of enforcement, from passive monitoring to active blocking.

What Each Policy Actually Does

Policy: None (p=none)

When you set p=none, you're telling email providers: "Even if this email fails authentication, deliver it anyway."

This sounds useless, but it's actually the most important starting point. With p=none, you can:

• Collect DMARC reports without risking email delivery
• Identify all the services sending email as your domain
• Catch authentication problems before they block legitimate mail

The p=none policy is monitoring mode. You're gathering intelligence, not enforcing rules.

Policy: Quarantine (p=quarantine)

With p=quarantine, failing emails get flagged as suspicious. Most email providers will:

• Move the email to spam or junk
• Add warning banners in some email clients
• Reduce the sender's reputation score

Recipients can still find the email if they check their spam folder, so legitimate messages aren't completely lost. This gives you some protection while leaving room for recovery if something goes wrong.

Quarantine is a good middle step when you're confident in your setup but not quite ready for full enforcement.

Policy: Reject (p=reject)

The p=reject policy tells receiving servers to block failing emails outright. The email never reaches the recipient, not even in spam.

This is the strongest protection against spoofing. If someone tries to send fake emails using your domain, those emails simply won't be delivered.

But it's also unforgiving. If your legitimate email fails authentication for any reason, it gets blocked too. That's why you need confidence in your setup before enabling reject.

The Journey from None to Reject

Most organizations follow a progression:

Phase 1: Discovery (p=none) Start with p=none and collect reports for at least 2-4 weeks. Review the reports to identify:

• All legitimate services sending email as your domain
• Any SPF or DKIM misconfigurations
• Third-party services that need authentication setup

Phase 2: Gradual enforcement (p=quarantine) Once you've fixed authentication issues, move to p=quarantine. Monitor for any legitimate email ending up in spam. Address any problems that surface.

Phase 3: Full enforcement (p=reject) After running quarantine without issues, upgrade to p=reject. Your domain is now fully protected against spoofing.

You can also use the pct= tag to apply your policy to only a percentage of failing emails. For example, pct=10 applies your policy to 10% of failures, letting you test gradually.

Subdomain Policies (sp=)

DMARC lets you set a separate policy for subdomains using the sp= tag:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

In this example, the main domain uses reject but subdomains use quarantine.

If you don't specify sp=, subdomains inherit the main policy. This can be a problem if you have subdomains with different email needs.

Common scenarios:

Stricter subdomain policy: You might set sp=reject even when your main domain is on sp=quarantine, especially if subdomains shouldn't be sending email at all.

Looser subdomain policy: If a specific subdomain uses third-party email services that are still being configured, you might want less strict enforcement there.

Common Policy Mistakes

Jumping straight to reject: Moving to p=reject without monitoring first almost always blocks legitimate email. Some service you forgot about will fail authentication, and important emails won't be delivered.

Staying on none forever: If you never move past p=none, you're not getting any protection. Spoofers can still send fake emails as your domain.

Ignoring subdomain policy: Your main domain might be secure, but if sp= is set to none (or not set at all), attackers can spoof your subdomains.

Not monitoring after changes: Even after reaching p=reject, you need ongoing monitoring. New email services, DNS changes, or configuration drift can break authentication.

Choosing Your Policy

Here's a simple decision framework:

Use p=none when:

• You're just setting up DMARC
• You're adding new email services
• You need to diagnose authentication problems

Use p=quarantine when:

• You've reviewed reports and fixed major issues
• You want protection but need a safety net
• You're testing before full enforcement

Use p=reject when:

• You've run quarantine without problems
• You're confident all legitimate email is authenticated
• You want maximum protection against spoofing

If you need to create or update your DMARC record, DMARC Creator can help you build the right policy.

Monitor Your DMARC Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.