--- title: "DMARC Policy Guide: none vs Quarantine vs Reject | SendHQ" description: A technical guide for engineers on implementing DMARC policies. Learn the rollout order, monitoring strategies, and how to avoid blocking legitimate email. canonical: https://sendhq.cc/blog/dmarc-policy-p-none-quarantine-reject last-updated: 2026-09-21 --- # DMARC p=none vs Quarantine vs Reject: An Operator's Guide Choosing the right DMARC policy is a balancing act between security and deliverability. Learn the safe rollout path from p=none to p=reject to prevent spoofing without blocking legitimate mail. ## 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](https://sendhq.cc/terms/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](https://sendhq.cc/tools/email-dns-checker.md) 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](https://sendhq.cc/terms/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](https://aws.amazon.com/ses/pricing/) (at 0.10 USD per 1,000 emails), whereas [Postmark](https://postmarkapp.com/pricing) 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](https://resend.com/pricing), which offers a free tier of 3,000 emails per month (capped at 100 per day), or [Mailgun](https://www.mailgun.com/pricing/) starting at 15 USD per month for 10,000 emails. [SendGrid](https://sendgrid.com/pricing) 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](https://sendhq.cc/guides/email-dkim-spf-dmarc.md). 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. ## Keep reading - [SPF Flattening: Fixing the 10-Lookup Limit](https://sendhq.cc/blog/spf-flattening-lookup-limit): Stop the 'permerror' caused by too many DNS lookups. Learn how SPF flattening works, why the 10-lookup limit exists, and how to resolve incl Read article → - [How to Receive Email with Amazon SES: S3 and Lambda](https://sendhq.cc/blog/receive-email-amazon-ses-s3-lambda): Build a production-ready inbound email pipeline with Amazon SES, S3, and Lambda, including MIME safety, tenant routing, idempotency, retries Read article → - [Amazon SES Pricing Tiers Explained (July 2026)](https://sendhq.cc/blog/amazon-ses-pricing-tiers-2026): Amazon SES shifted from a simple a la carte model to tiered plans (Essentials, Pro, Enterprise) on July 21, 2026. Here is the cost breakdown Read article →