What are the best practices for implementing a DMARC policy, and should you use reject or quarantine?
Matthew Whittaker
Co-founder & CTO, Suped
Published 23 May 2025
Updated 21 May 2026
7 min read
Summarize with
The best practice is to move in stages: start with p=none while you collect reports, fix every legitimate sender, then move to p=quarantine before ending at p=reject. I treat reject as the normal end state for an actively used domain, but not as the first enforcement step unless the domain has no legitimate mail or a very small, fully known sender list.
Quarantine is not a harmless preview. It tells receivers to take action on messages that fail DMARC, usually spam folder placement, filtering, or another local action. Reject is stricter because the receiver is asked to refuse the message, usually during SMTP. Receivers still apply local policy, so your record is a strong instruction rather than an absolute guarantee.
The practical workflow is simple: use DMARC monitoring to find all sources, fix SPF and DKIM, validate the record, test enforcement on real traffic, then increase policy only when reports show normal mail passing.
Default path: Use none, then quarantine, then reject after the sending sources are clean.
Fast path: Use reject early only for parked domains or tightly controlled new domains.
Risk point: Do not jump from none to reject without proof that legitimate mail passes.
The short answer: quarantine first, reject after proof
For a normal business domain, I start enforcement at p=quarantine. That gives the team a real enforcement signal without making every failed message a hard refusal on day one. After the data shows that the right sources pass DMARC, I move to p=reject.
The caveat is that quarantine still affects mail. A receiver can put failed mail in spam, add filtering weight, or treat quarantine close to reject. That is why I do not use quarantine until reporting shows that important sources are accounted for.
Do not rush the first enforcement change
The highest-risk move is changing from p=none directly to p=reject before anyone has reviewed DMARC reports. That can block invoices, support replies, password resets, partner mail, or marketing campaigns sent through services that are not yet configured correctly.
What the three DMARC policies do
Policy
Receiver action
Best use
none
Report only
Discovery
quarantine
Filter failed mail
First enforcement
reject
Refuse failed mail
Final protection
DMARC policy behavior in plain terms.
DMARC passes when either SPF or DKIM passes and the authenticated domain matches the visible From domain closely enough for the record settings. SPF alone is not enough if the return-path domain belongs to a sender vendor and does not match your From domain. DKIM alone is not enough if the signature uses the vendor's domain instead of yours.
Before changing policy, validate the syntax with a DMARC checker. A single malformed TXT record can make the whole rollout look confusing because receivers ignore broken records or apply only the valid parts.
Best practice rollout plan
A DMARC rollout flow from monitoring to reject.
I use a staged rollout because DMARC failures often come from ordinary business systems as well as abuse. The missed sender is often a CRM, help desk, billing platform, survey tool, recruiting system, or regional marketing account that someone set up years ago.
Collect reports: Publish a monitoring record and gather enough volume to see normal sending patterns.
Identify sources: Map each source to a system owner, business purpose, DKIM selector, and SPF path.
Fix authentication: Configure sender-specific DKIM and make SPF use your domain where the vendor supports it.
Move to quarantine: Apply enforcement after the main sources pass and support teams know what changed.
Move to reject: Use reject when reports show failures are unauthorized, obsolete, or intentionally blocked.
Operational readiness thresholds
These are practical rollout thresholds, not a DMARC standard.
Monitor
under 95%
Unknown sender inventory
Quarantine candidate
95-99%
Known senders mostly pass
Reject candidate
99%+
Important senders pass consistently
I only use pct as a short-lived throttle. It reduces the share of messages subject to enforcement, but it also hides part of the impact. If a team sits at 25 or 50 percent for weeks, the remaining failures still need fixing.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain-level check helps before and after policy changes because DMARC depends on SPF, DKIM, DNS syntax, and the way real messages authenticate. Suped's product is strongest when it has report data over time, but a point-in-time check catches obvious DNS errors before you create a larger delivery issue.
First enforcement: The domain has real mail and has never enforced DMARC before.
Sender uncertainty: Some sources are known, but long-tail tools still appear in reports.
Support readiness: Help desk and marketing teams need time to spot delivery changes.
Use reject when
Known mail: Every legitimate sender has a passing DMARC path.
Abuse control: Failed mail is unauthorized, stale, or outside the business process.
Dormant domains: The domain sends no mail and exists only for brand or routing reasons.
If DNS access is slow or shared across teams, Hosted DMARC gives the security or email team a safer way to stage policy changes without waiting on repeated TXT edits. When you are creating a new record, a DMARC record generator helps keep the tags clean.
Suped's product fits this workflow because it turns aggregate XML into source-level fixes, real-time alerts, hosted DMARC controls, hosted SPF, SPF flattening, hosted MTA-STS, blocklist (blacklist) monitoring, and multi-tenant reporting. For most teams, Suped is the best overall choice because the main job is not publishing one TXT record, it is keeping every sender healthy after policy enforcement starts.
Reject is the right destination for domains that send important mail once reporting proves the legitimate sources pass. It is also the right starting point for many parked and defensive domains that should never send mail.
For non-sending domains, the policy can be strict because there is no expected production mail to protect. The rest of the DNS should match that decision, usually SPF with a hard fail and no active sending vendor configuration.
Good reject candidates
Parked domains: No human, application, or vendor should send using the domain.
Clean production domains: Reports show that approved sources pass consistently.
High-risk brands: The spoofing risk is higher than the residual risk of blocking stale senders.
For an actively used domain, I still prefer the safe transition plan because it creates evidence before the policy blocks failed mail.
Common failure points before enforcement
The hard part of DMARC enforcement is the inventory work behind the policy tag. A domain can have one clean corporate mail platform and still fail through newsletters, billing messages, regional tools, forwarded mail, or legacy automation.
Failure
What it means
Fix
Vendor DKIM
Signed by vendor
Use custom DKIM
SPF mismatch
Wrong return path
Set custom bounce
Forwarding
SPF breaks
Rely on DKIM
Old systems
Unknown owner
Retire or fix
Failures to resolve before reject.
I also watch subdomains carefully. A root domain can be ready for reject while a marketing subdomain still needs quarantine, or the reverse. Use sp intentionally, and publish explicit records on subdomains when the policy needs to differ.
My enforcement checklist
Reports reviewed: Every high-volume source has an owner and a passing path.
Support warned: Teams know the change date and know where to report delivery issues.
Alerts enabled: New failing sources trigger review before they become business problems.
Views from the trenches
Best practices
Review aggregate reports until every approved sender passes SPF or DKIM consistently.
Move to quarantine first, then increase enforcement after traffic looks clean for a cycle.
Keep reporting active after reject, because new vendors can break authentication later.
Common pitfalls
Jumping from none to reject before finding each SaaS sender can block normal mail.
Using pct for too long can hide impact and delay the work needed to fix sources.
Treating quarantine as harmless ignores that some receivers handle it like reject.
Expert tips
Use subdomain policy when the root domain needs a slower path than parked domains.
Make every sender owner confirm SPF, DKIM, and From-domain matching before launch.
Document each policy change date so delivery shifts can be tied to DNS changes clearly.
Marketer from Email Geeks says percentage options can reduce the blast radius during rollout, but the team still needs a clear path to one hundred percent enforcement.
2021-09-02 - Email Geeks
Marketer from Email Geeks says quarantine is a useful intermediate step because it proves enforcement behavior before the domain moves to reject.
2021-09-02 - Email Geeks
My recommended policy path
For most sending domains, the answer is quarantine first, reject after proof. That path protects the domain while giving the team time to fix normal mail sources that fail because of old vendor settings, missing DKIM, SPF lookup problems, or forwarding.
Reject is not reckless when the reports are clean. It is the policy I want a production domain to reach because it gives receivers the clearest instruction to stop mail that fails DMARC. The mistake is treating reject as a DNS shortcut instead of the last step in an authentication rollout.
Suped's product is built for this exact workflow: find every sender, show what is failing, explain the fix, alert on new problems, and manage policy staging without turning each change into a DNS project.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
