Start with DMARC quarantine, then move to reject once you have confirmed that all legitimate email sources are properly authenticated. Jumping straight to reject without first validating your sending infrastructure can cause real email to be silently dropped, which means lost messages and potential revenue impact. The questions below walk you through exactly how to make this decision confidently.
What’s the difference between DMARC quarantine and reject?
DMARC quarantine and reject are two enforcement-level policies that tell receiving mail servers what to do with messages that fail DMARC authentication. Quarantine sends failing messages to the spam or junk folder, where recipients can still find them. Reject instructs the receiving server to refuse the message entirely, so it never reaches the inbox or spam folder at all.
Both policies sit above the default p=none policy, which only monitors and reports without taking any action on failing mail. Moving to quarantine is the first real enforcement step. It protects your domain from spoofing and phishing while still giving you a safety net. If a legitimate sending source was accidentally missed during setup, its messages land in spam rather than disappearing completely.
Reject is the strongest DMARC policy available. Once you apply it, there is no recovery path for a failing message. That makes it the most secure option, but also the one that demands the most preparation before you switch it on.
Why does the order of DMARC policies matter?
The order of DMARC policies matters because each level of enforcement has real consequences for your email deliverability. Moving through none, then quarantine, then reject is a deliberate progression that lets you identify and fix authentication gaps before they cause legitimate mail to be blocked permanently.
Email environments are rarely simple. Most organizations send mail from multiple sources, including marketing platforms, transactional email services, CRM tools, and internal mail servers. Each of these sources needs to be covered by your SPF and DKIM records before enforcement kicks in. If you skip quarantine and go straight to reject, any source you missed will have its mail silently dropped with no warning to the sender or recipient.
The quarantine phase acts as a diagnostic period. It enforces your policy firmly enough to deter attackers while still giving your team visibility into which sending sources are failing authentication. That visibility is what makes the eventual move to reject safe rather than risky.
When should you move from quarantine to reject?
You should move from quarantine to reject when your DMARC reports consistently show that all legitimate email traffic is passing authentication and the only failing messages are from unauthorized senders. In practice, this usually means monitoring your aggregate reports for several weeks until the data is clean and stable.
Before making the switch, work through this checklist:
- All authorized sending sources are covered by SPF or are signing with DKIM
- Your SPF record is accurate and does not exceed DNS lookup limits
- DKIM signatures are configured for every sending platform you use
- Aggregate DMARC reports show a consistently high pass rate for legitimate mail
- You have reviewed and resolved any forwarding issues that might cause false failures
There is no universal timeline. Some organizations are ready to move to reject within a few weeks. Others with complex sending environments or many third-party tools may need several months of monitoring at quarantine before the data is clean enough to proceed safely.
What risks come with jumping straight to reject?
Jumping straight to a DMARC reject policy risks blocking legitimate email from sources you did not know were sending on your behalf. Because reject is irreversible at the server level, those messages are permanently lost. Recipients never see them, and senders receive no useful error in many cases, making the problem hard to diagnose after the fact.
The most common scenarios where this causes real damage include:
- Forgotten sending services: A third-party tool set up years ago and still sending transactional or automated messages
- Forwarding configurations: Email forwarded from one domain to another often breaks SPF alignment, causing DMARC failures even for genuine messages
- Partner or vendor mail: Suppliers or agencies sending on your behalf without proper authentication in place
- Legacy infrastructure: Internal systems or older servers that were never configured with DKIM signing
Each of these issues is manageable when caught at the quarantine stage, because the mail still arrives somewhere and can be investigated. Under reject, the evidence disappears along with the message.
How do DMARC reports help you choose the right policy?
DMARC reports give you a source-by-source breakdown of which sending IPs are passing or failing authentication on your domain, which is exactly the data you need to decide when it is safe to move to a stricter policy. Without reading these reports, any policy decision is essentially a guess.
There are two types of DMARC reports to understand:
Aggregate reports (RUA)
Aggregate reports are sent daily by receiving mail servers and summarize authentication results across all messages claiming to be from your domain. They show you which IP addresses are sending in your name, how many messages passed or failed SPF and DKIM checks, and whether DMARC alignment was achieved. These are the primary tool for auditing your sending environment and tracking progress toward a clean authentication record.
Forensic reports (RUF)
Forensic reports are generated for individual failing messages and include more detail about the specific authentication failure. Not all receiving servers send them due to privacy considerations, but when they are available, they can help identify exactly why a particular source is failing. They are especially useful when you are trying to debug a specific sending platform or track down an unauthorized sender.
Reading DMARC reports in raw XML format is cumbersome. A dedicated reporting tool or email authentication service makes it far easier to interpret the data and act on it confidently.
Can you use DMARC quarantine and reject on different subdomains?
Yes, DMARC allows you to set different policies for your root domain and subdomains using the sp tag. This means you can apply reject to your primary domain while keeping quarantine on subdomains that have more complex or less predictable sending patterns, giving you granular control over enforcement levels.
This flexibility is particularly useful in a few situations. If your main corporate domain is fully locked down but a marketing subdomain uses several third-party tools that are still being audited, you can enforce reject on the root domain without risking legitimate marketing mail. Similarly, if you operate subdomains for different business units or regional operations, each can be tuned to the appropriate enforcement level based on how mature its authentication setup is.
One important nuance: if you do not specify an sp tag in your DMARC record, subdomains inherit the policy set for the root domain. That means a root-level reject policy automatically applies to all subdomains unless you explicitly override it. Always check your subdomain sending behavior before moving the root domain to reject, or use the sp tag deliberately to manage the difference.
How Email Industries helps with DMARC policy implementation
Getting DMARC right, especially the move from quarantine to reject, requires accurate data, careful analysis, and a clear view of your entire sending environment. That is exactly what we help with at Email Industries. Our team has spent more than two decades working on email deliverability and authentication for organizations across industries, including SaaS, eCommerce, healthcare, and finance.
Here is what we bring to your DMARC implementation:
- Full sending environment audit: We identify every source sending mail on your domain so nothing gets missed before enforcement tightens
- DMARC report interpretation: We translate aggregate and forensic report data into clear, actionable steps
- Policy progression support: We guide you from none to quarantine to reject at a pace that protects deliverability throughout
- SPF and DKIM alignment review: We make sure your authentication records are accurate, complete, and within technical limits
- Ongoing monitoring: Through our Deliverability Assurance Packages, we keep watch on your authentication health so problems surface before they become deliverability incidents
If you are unsure whether your domain is ready to move to reject, or if you have already enforced a strict policy and are seeing unexpected failures, we are here to help. Reach out and contact us to talk through your current setup and figure out the right next step together.
Related Articles
- How long does it take to fully implement a DMARC policy?
- Can weak DKIM keys put your email deliverability at risk?
- Can a broken SPF record cause your emails to land in spam?
- What happens if you don't have DMARC?
- How does SPF protect your email sender reputation?
- How does SPF work in emails?
- How do email advertising agencies handle creative development?
- What documentation do full service agencies require during setup?
- Can you warm up multiple domains at the same time?
- Why is domain warmup important for deliverability?
- What email marketing tools do ecommerce agencies use for online stores?
- What A/B testing methods do email agencies use?
- Can email marketing services agencies integrate with existing CRM systems?
- What causes email domains to get blacklisted?
- What is the difference between email marketing and email deliverability agencies?
