DMARC p=none vs Quarantine vs Reject: An Operator's Guide

The Core Tradeoff

Choosing a DMARC policy is a choice between visibility and enforcement. p=none provides monitoring without affecting delivery. p=quarantine sends suspicious mail to the spam folder. p=reject blocks unauthenticated mail entirely. The safest path is a phased rollout: start with none to identify all legitimate senders, move to quarantine to test the impact, and finally reach reject to fully secure your domain against spoofing.

Why Policy Matters for the Incident Queue

As an engineer owning deliverability, your primary goal is to ensure that legitimate transactional mail reaches the recipient while preventing attackers from using your domain. If you jump straight to p=reject without a monitoring phase, you will likely trigger a high-priority incident when a forgotten legacy system or a third party marketing tool suddenly stops delivering mail.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) relies on the alignment of SPF and DKIM. If a message fails both, the p= tag tells the receiving mail server exactly what to do with that message.

The Three Policy Levels

1. p=none (Monitoring Mode)

In this mode, the receiver does nothing to the message regardless of authentication results. It is purely for data collection.

When to use it:

• Initial setup of DMARC.
• When you are unsure of all the services sending mail on your behalf.
• During a migration to a new email API.

The Payload:

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

The Tradeoff: You have zero protection against spoofing. Attackers can still send mail as your domain, but you will see it in your RUA (Aggregate) reports.

2. p=quarantine (Soft Enforcement)

Messages that fail DMARC are treated as suspicious. Most receivers will move these to the spam or junk folder.

When to use it:

• After you have analyzed p=none reports and verified all legitimate streams are aligned.
• As a safety buffer before moving to full rejection.

The Payload:

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

The Tradeoff: It reduces the visibility of spoofed mail but does not eliminate it. Some legitimate mail might still land in spam if your DKIM keys rotate incorrectly or SPF records hit the 10 DNS lookup limit.

3. p=reject (Full Enforcement)

This is the gold standard for domain security. The receiving server will outright refuse to accept the message if it fails DMARC.

When to use it:

• When your monitoring shows 99.9% alignment for all legitimate traffic.
• When the risk of domain spoofing outweighs the risk of occasional delivery failure.

The Payload:

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

The Tradeoff: There is no safety net. If a critical system is misconfigured, the mail is gone. You will see these failures in the RUA reports, but the user never receives the mail.

The Operator's Rollout Checklist

Do not move policies based on a feeling. Move them based on the data in your aggregate reports. Use a tool like the SendHQ Email DNS Checker to verify your records are propagating correctly before each shift.

Phase 1: Discovery (p=none)

1. Publish p=none with a rua address.
2. Wait 7 to 14 days to capture a full business cycle of emails (including weekly reports).
3. Analyze reports for "unaligned" traffic.
4. Identify legitimate third party senders (e.g., Zendesk, Salesforce, Shopify).
5. Configure DKIM for every identified sender. This is the most reliable way to ensure alignment.

Phase 2: Testing (p=quarantine)

1. Update policy to p=quarantine.
2. Monitor your support tickets for "I didn't get the email" or "The email is in spam."
3. Check RUA reports for any new spikes in failures.
4. If failures occur, fix the authentication and stay at quarantine for another week.

Phase 3: Hardening (p=reject)

1. Update policy to p=reject.
2. Verify that your most critical transactional flows (password resets, invoices) are still delivering.
3. Maintain monitoring. DMARC is not a "set and forget" configuration.

Handling Email as a Side Effect

For product engineers building AI agents or automated workflows, sending an email is an external side effect. This means it can fail for reasons outside your application logic (DNS issues, DMARC rejection, rate limits).

Idempotency and Approval

When an AI agent triggers an email, you must prevent duplicate sends during retries. Use an idempotency key in your API requests to ensure that a network timeout does not result in the customer receiving the same email five times.

Furthermore, agents should not have autonomous permission to send high-stakes emails. Implement an approval queue for agent-generated content to ensure the "From" address and content align with your brand and authentication policies.

The Cost of Delivery Infrastructure

Choosing your sending provider affects how you manage DMARC. Some providers make DKIM setup trivial, while others require manual DNS entries for every subdomain.

When evaluating costs, look at the total cost of ownership. For example, sending 50,000 emails costs approximately 5 USD on Amazon SES a la carte (at 0.10 USD per 1,000 emails), whereas Postmark tiers would cost about 66 USD for the same volume (15 USD for 10,000 plus overages between 1.20 and 1.80 USD per 1,000).

Other options include Resend, which offers a free tier of 3,000 emails per month (capped at 100 per day), or Mailgun starting at 15 USD per month for 10,000 emails. SendGrid now uses a 60-day trial for its free tier, with Essentials starting at 19.95 USD per month.

Regardless of the provider, the DMARC policy remains your domain's primary shield. If you use a provider that only supports SPF, you are at higher risk of delivery failure when moving to p=reject because SPF breaks during email forwarding. DKIM is the only way to maintain alignment through forwards.

Common Failure Modes

The Forwarding Trap

User A sends an email to User B. User B has an auto-forward to User C. The forwarding server often changes the envelope sender to its own domain to avoid being flagged as spam. This breaks SPF alignment. If you have p=reject and no DKIM signature, User C will never see the email.

The DNS Lookup Limit

SPF records are limited to 10 DNS lookups. If you add too many providers to your SPF record, the receiver will return a permerror. This causes a DMARC failure. To solve this, use a provider that encourages DKIM-first authentication or use SPF flattening.

The "Shadow IT" Problem

Marketing teams often sign up for new tools (e.g., a new newsletter service) without telling engineering. They send mail from your domain, it fails DMARC, and it gets rejected. This is why the p=none phase is non-negotiable.

Summary Table for Operators

Policy | Action | Risk | Visibility | Recommended Use

p=none | None | Low | High | Discovery and Audit

p=quarantine | Spam Folder | Medium | High | Testing and Transition

p=reject | Blocked | High | Medium | Full Production Security

For a deeper dive into the technical implementation of these records, see our guide on DKIM, SPF, and DMARC.

Managing these records manually is tedious. SendHQ simplifies this by providing verified-domain transactional sending and tools to ensure your infrastructure is agent-ready.

Learn more at https://sendhq.cc.