What are the best practices for implementing a DMARC policy, and should you use reject or quarantine?
Published 23 May 2025
Updated 24 Jul 2026
10 min read
Summarize with
Updated on 24 Jul 2026: We updated this guide for RFC 9989, including the removal of pct and the stricter guidance for p=reject.
The safest default is to move in stages: start with p=none while you collect reports, fix every legitimate sender, then move to p=quarantine. Use p=reject only after authorized sources and indirect mail flows have been tested. Reject can be an appropriate end state for controlled mail streams and non-sending domains, but RFC 9989 advises extra caution for domains whose users post to Internet mailing lists.
Quarantine is not a harmless preview. It asks receivers to take action on messages that fail DMARC, usually spam-folder placement, filtering, or another local action. Reject expresses the strongest handling preference, but receivers still apply local policy. Under RFC 9989, receivers must not reject solely because a domain publishes reject and must use other available analysis.
The practical workflow is to use DMARC monitoring to find all sources, fix SPF and DKIM alignment, validate the record, test enforcement on real traffic, then strengthen policy only when reports show normal mail passing.
- Default path: Use none, then quarantine, then consider reject after direct and indirect mail tests are clean.
- Fast path: Use reject early only for parked domains or tightly controlled new domains.
- Risk point: Do not move to reject without checking legitimate senders, forwarding, and mailing-list traffic.
The short answer: quarantine first, reject only after proof
For a business domain with controlled mail streams, start enforcement at p=quarantine. That gives the team a real enforcement signal without requesting the strongest treatment for every failed message on day one. Move to p=reject only when authorized sources pass and the domain's forwarding and mailing-list use has been reviewed.
Quarantine still affects mail. A receiver can put failed mail in spam, add filtering weight, or handle it close to reject. 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 reviewing DMARC reports and indirect mail. That can disrupt invoices, support replies, password resets, mailing-list posts, or campaigns sent through services that are not configured correctly.
What the three DMARC policies do
|
|
|
|---|---|---|
none | No handling preference | Discovery and reporting |
quarantine | Request filtering | First enforcement |
reject | Request strongest handling | Controlled or non-sending domains |
DMARC policy behavior in plain terms.
DMARC passes when either SPF or DKIM passes and its authenticated domain has alignment with the visible From domain. Relaxed alignment, the default, accepts domains with the same organizational domain. Strict alignment requires an exact domain match. SPF alone is not enough if the return-path domain belongs to a sending vendor and lacks alignment with your From domain. DKIM alone is not enough if the signature uses the vendor's domain instead of yours.
Starting record for monitoringTXT
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
When rua points to a different organizational domain, that report destination must authorize the source domain in DNS or receivers can decline to send reports. Before changing policy, validate the syntax with a DMARC checker. Invalid policy syntax can stop the intended enforcement from being applied.
Best practice rollout plan
DMARC policy rollout from p=none monitoring through quarantine to p=reject.
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 capture routine, low-volume, and seasonal senders.
- Identify sources: Map each source to a system owner, business purpose, DKIM selector, and SPF path.
- Fix authentication: Configure sender-specific DKIM and an aligned return path where the vendor supports it.
- Move to quarantine: Apply enforcement after the main sources pass and support teams know what changed.
- Evaluate reject: Use reject only when direct mail passes, indirect flows are tested, and remaining failures are unauthorized or obsolete.
Operational readiness gates
Use report evidence and business testing rather than a fixed pass-rate target.
Monitor
Unknown sources remain
Inventory and ownership are incomplete
Quarantine candidate
Known mail is aligned
Important authorized sources pass
Reject candidate
Residual failures reviewed
Direct and indirect flows are tested
Do not use pct for a new staged rollout. RFC 9989 marks the tag as historic because receivers applied percentage values inconsistently. Use distinct none, quarantine, and reject observation periods instead. The newer t=y value is a testing signal, not a percentage throttle.
?
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 keeps aggregate report data over time so teams can compare sources before and after a policy change. The point-in-time check catches obvious DNS errors before they become a delivery issue.
Enforcement recordsTXT
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
How to choose quarantine or reject
Use quarantine when
- 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.
- Indirect mail: Mailing lists, forwarders, or gateways have not been tested fully.
Use reject when
- Known mail: Every legitimate sender has a stable, aligned DMARC pass path.
- Indirect flows: Forwarding and mailing-list behavior has been tested and accepted.
- Non-sending domains: The domain has no authorized human, application, or vendor mail.
If DNS access is slow or shared across teams, Hosted DMARC gives the security or email team a controlled way to stage policy changes without waiting on repeated TXT edits. When creating a new record, a DMARC record generator helps keep the tags clean.
Suped's product fits this workflow by translating aggregate XML into source-level results, alerts, and policy staging. That gives teams an audit trail for each sender and reduces the risk of changing enforcement with incomplete data.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
When reject is the right answer
Reject is appropriate for controlled domains that send important mail once reporting proves the legitimate sources pass and indirect flows are understood. It is also a suitable starting policy 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. Under RFC 9989, np=reject requests reject handling for mail using non-existent subdomains.
Good reject candidates
- Parked domains: No human, application, or vendor should send using the domain.
- Dedicated senders: A small set of approved services passes with stable alignment.
- Controlled production domains: Reports are clean and indirect mail behavior has been tested.
Reject record for a strict domainTXT
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com
For an actively used domain, follow a safe transition plan because it creates evidence before the policy requests stronger handling for failed mail.
Account for mailing lists and forwarding before reject
RFC 9989 adds strong operational caution for general-user domains. Mailing lists and forwarders can break SPF because the forwarding server is not authorized by the original sender's SPF record. Message changes can also invalidate DKIM. A legitimate message then fails DMARC even though the original sender authenticated it.
For domains whose users post to Internet mailing lists, the specification recommends at least one month at p=none followed by at least one month at p=quarantine before deciding whether reject is acceptable. Compare aggregate-report dispositions and test actual indirect routes during both periods.
- Mailing lists: Test representative posts and confirm how each list handles the visible From domain.
- Forwarding: Use aligned DKIM that survives normal transit because SPF commonly breaks after forwarding.
- Report overrides: Review mailing-list and forwarding reasons in aggregate policy-override data.
- Business decision: Keep quarantine when legitimate indirect mail cannot pass reliably and user impact is unacceptable.
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, mailing lists, or legacy automation.
|
|
|
|---|---|---|
Vendor DKIM | Signed by vendor | Use aligned custom DKIM |
SPF mismatch | Unaligned return path | Set a custom return path |
Forwarding | SPF commonly breaks | Use aligned, durable DKIM |
Old systems | Unknown owner | Retire or fix |
Failures to resolve before stronger enforcement.
Watch subdomains carefully. A root domain can be ready for reject while a marketing subdomain still needs quarantine, or the reverse. Use sp intentionally for existing subdomains and np for non-existent subdomains. Publish an explicit record on a legitimate subdomain when its policy needs to differ.
Enforcement checklist
- Reports reviewed: Every important source has an owner and an aligned pass path.
- Indirect mail tested: Forwarding, mailing lists, and gateways have been checked.
- Support warned: Teams know the change date and 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 with alignment.
Hold none and quarantine long enough to capture low-volume and seasonal mail sources.
Keep reporting active after enforcement because new vendors can break authentication.
Common pitfalls
Jumping to reject before testing mailing lists and forwarding can disrupt valid mail.
Using the historic pct tag creates inconsistent rollout behavior across receivers.
Treating quarantine as harmless ignores that receivers can filter failures differently.
Expert tips
Use np=reject to cover non-existent subdomains where current receiver support exists.
Make each sender owner confirm SPF, DKIM, and From-domain alignment before launch.
Document each policy change so delivery shifts can be tied to DNS changes clearly.
Marketer from Email Geeks says staged policy changes can reduce the blast radius, but the team still needs a clear path to complete 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
Recommended policy path
For most controlled sending domains, use quarantine first and evaluate reject after proof. That path gives the team time to fix normal sources that fail because of old vendor settings, missing DKIM, SPF alignment problems, forwarding, or mailing-list changes.
Reject is a reasonable policy when reports are clean and indirect flows have been tested. It gives receivers the strongest DMARC handling preference, but it is not a DNS shortcut or a guarantee that every failed message will be refused. General-user domains with unavoidable mailing-list risk should keep quarantine when that produces the safer business outcome.
Suped's product supports this workflow by identifying each sender, showing alignment failures, alerting on new problems, and recording policy changes without turning every update into a manual DNS project.
