Should I change my DMARC policy from p=none to p=reject?
Updated on 25 Oct 2026: We clarified DMARC rollout readiness and test-mode limits, and added steps to restore legitimate mail after rejection.
Do not change your DMARC policy straight from p=none to p=reject just because a warning says your DMARC policy is not enabled. Change to reject only after you have collected reports, identified every legitimate sender, fixed authentication failures, tested indirect mail, and staged enforcement.
The long-term answer is yes for most controlled sending domains. p=reject tells receivers that mail failing DMARC with your visible From domain is not valid use of the domain. Receivers combine that request with local analysis when deciding whether to reject a message. p=none is a monitoring policy. With aggregate reporting configured through rua, it gives you visibility but does not request enforcement against exact-domain spoofing.
- No reports: stay on p=none while you collect aggregate DMARC reports.
- Known senders: move toward enforcement after your real mail passes SPF or DKIM with DMARC alignment. For reject, configure valid DKIM signing rather than relying only on SPF.
- Unknown mail: investigate before reject, because that traffic can include payroll, support, billing, system alerts, staff mail, and marketing.
- No-send domains: reject is usually safe after you confirm the domain and its subdomains truly send no mail.
When should you move to p=reject?
Treat p=none as the measurement phase. With aggregate reporting configured, it shows sending sources and authentication results. Investigate failures to distinguish spoofing from legitimate mail. Treat p=reject as the enforcement phase, where the domain owner asks receivers to reject mail that fails DMARC after their local analysis.
If you have not reviewed reports yet, set up DMARC monitoring first. If you already have reports and the legitimate sources are clean, move in stages. If the reports show active spoofing and your real sources pass, do not sit at p=none longer than needed. Gmail's bulk sender requirements allow p=none as the minimum DMARC policy. A compliance warning alone does not establish readiness for reject.
Do not skip the visibility step
Changing to reject without reports means you are asking receivers to enforce a policy without knowing what your domain actually sends. That can stop real campaigns, invoices, support replies, password resets, or internal mail when authentication is wrong.
|
|
|
|---|---|---|
No reports | p=none | Collect data before enforcement. |
Legitimate failures | p=none | Fix legitimate failures first. |
Known sources pass | p=quarantine | Pilot quarantine on a separately configured sending subdomain, then review delivery. |
Sources and routes assessed | p=reject | Enforce and keep monitoring. |
Use the current state of your reports to choose the next policy step.
What p=reject changes for email delivery
DMARC passes when SPF or DKIM passes and its authenticated domain has DMARC alignment with the visible From domain. Under RFC 9989, receivers use DNS Tree Walk policy discovery to find the applicable policy domain and organizational domain. If neither authentication path produces an aligned pass, DMARC fails. The applicable policy expresses how the domain owner wants that failure handled, while the receiver makes the final disposition decision. SPF checks the return-path domain; DKIM uses the signing domain in d=. Relaxed alignment, the default, permits a shared organizational domain. Strict alignment requires an exact domain match.
With p=none
- Purpose: observe mail sources and failures.
- Receiver action: no requested enforcement based on DMARC.
- Risk: spoofed mail using your exact domain can still be accepted.
- Use: initial discovery and remediation.
With p=reject
- Purpose: protect the domain from unauthenticated use.
- Receiver action: consider rejecting failing mail during SMTP, using the policy together with local analysis.
- Risk: real mail can be rejected if a sender or indirect route is misconfigured.
- Use: mature domains with clean authentication.
DMARC rollout steps: collect reports, verify sources, stage quarantine, review failures, and move to reject.
This is why the answer depends on your whole domain, not only the marketing platform you are thinking about. DMARC applies to every message using that domain in the From header. A domain can have clean marketing mail and still have broken support, finance, CRM, scanner, ticketing, payroll, or employee mail. Reject does not guarantee inbox placement or prevent display-name impersonation and lookalike domains.
What to check before changing policy
Before moving a domain to reject, require evidence rather than confidence. The evidence comes from aggregate reports, live test messages, DNS records, and a sender inventory with clear ownership.
- Reports: collect enough reporting cycles for normal sending patterns to appear. Trigger test messages from monthly or seasonal systems that have not sent during the monitoring window.
- Sources: name each legitimate sender, including internal mail and operational systems. Check with department owners for unrecorded services, often called shadow IT.
- Authentication: confirm each source produces an aligned SPF or DKIM pass for the visible From domain.
- Indirect mail: test forwarding, mailing lists, aliases, and other relays, with aligned DKIM that survives expected changes.
- Policy scope: review p, sp, np, and specific subdomain records for every sending and no-send subdomain.
- Ownership: assign every sending service to a person or team that can fix DNS and platform settings. Require domain authentication and a live delivery test before any new sending service goes live.
A quick DNS check is still useful. Run the domain through Suped's DMARC checker to confirm a single valid record and the intended rua destination. If reports go to another domain, verify that the destination authorizes external reporting. Then use a broader domain health checker to inspect related email DNS settings. Verify DKIM signing on actual messages as well.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A valid TXT record does not prove real mail passes DMARC. Assess legitimate mail by source rather than requiring a perfect overall pass rate: attempted spoofing should continue to fail. Investigate unexplained failures even when overall results look good. Aggregate reports cover participating receivers, so use live tests to check routes that reports do not show.
How to stage the change
A staged rollout limits disruption. Start with reporting, move to quarantine after known sources pass, and then move to reject. Pilot enforcement on a lower-risk sending subdomain with its own DMARC record when you need a smaller initial scope. RFC 9989 makes the old pct tag historic and defines t=y test mode. Hosted DMARC can manage policy changes without a manual DNS edit at every stage.
Plan for receivers that ignore test mode
On receivers implementing RFC 9989, p=quarantine; t=y requests none-level handling, and p=reject; t=y requests quarantine-level handling. RFC 7489 requires unknown tags to be ignored. Therefore, a receiver that does not recognize t=y can apply the full published policy. Prepare for that enforcement before publishing a test record; test mode is not a percentage rollout.
Publish one TXT record at _dmarc.example.com, replacing example.com with your domain. Each line below is a successive replacement, not a separate record to publish alongside the others. Use your actual report destination.
Successive DMARC policies, publish one at a timedns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
Readiness gates
Use evidence from real mail as the gate before changing the domain policy.
Stay at none
Not ready
Reports are missing, legitimate sources are unidentified, or legitimate failures remain unresolved.
Start quarantine
Ready to pilot
Known sources pass and important indirect routes have been tested.
Move to reject
Ready
Legitimate mail passes, indirect-route risks are assessed, and residual failures are understood.
No-send domain
Reject
The domain and its subdomains send no mail and have intentionally restrictive records.
For a step-by-step migration plan, use a safe DMARC transition process rather than a single DNS edit. Every policy change should be backed by report data, live delivery tests, and a rollback path.
Check indirect mail before reject
Forwarding and mailing lists deserve a separate readiness check. SPF often fails after forwarding because the relay's IP address is not authorized by the original return-path domain. DKIM can preserve a DMARC pass, but only when the signature is aligned and survives message changes such as footer or subject-line edits. RFC 9989 says a domain using p=reject must not rely only on SPF for DMARC.
- Forwarding tests: send through the forwarding paths your users and customers actually use.
- Mailing lists: check how lists rewrite the From header or edit fields covered by the DKIM signature.
- DKIM durability: use aligned signatures and verify that common intermediaries do not invalidate them.
- User impact: identify employees who post to external lists or use role aliases before enforcement.
RFC 9989 advises domains that host users who might post to Internet mailing lists not to publish p=reject because of interoperability problems. If such a domain proceeds, the RFC recommends at least one month at p=none, followed by an equally long period at p=quarantine, while comparing dispositions. Simpler transactional domains can use a shorter evidence window when all sources and routes are controlled.
When a faster move to reject is reasonable
A domain that truly sends no mail can usually move directly to reject after you verify that no legitimate service uses it or its subdomains. Keep aggregate reporting enabled so attempted abuse remains visible.
Safer to move faster
- No-send: the domain and its subdomains have no legitimate outbound mail.
- New brand: only one controlled sender is using it.
- Dedicated mail: marketing or transactional traffic is separated on a subdomain.
- Clean reports: all legitimate traffic is known and passing.
Slower is safer
- Legacy domain: years of systems have used the domain.
- Staff mail: employees send through desktop, mobile, or delegated systems.
- Shared domain: many business units send with the same From domain.
- Low visibility: reports are missing or not tied to source owners.
Marketing-only assumptions are where teams get hurt. A domain used for newsletters can also be used by a salesperson, billing system, support desk, event platform, or old automation that nobody remembered. DMARC enforcement does not care which team owns the message. It evaluates the domain in the visible From address.
What to do if legitimate mail is rejected
Before enforcement, save the working DMARC record and its DNS TTL, assign a person who can restore it, and tell sending-service owners how to report delivery failures. If you lower the TTL for the change, do so in advance and wait out the previous TTL. DNS caching follows the rules described in RFC 1034.
- Check the sending service's SMTP logs or bounce response for the recipient domain and a DMARC-specific rejection. Identify the source and visible From domain before changing policy.
- Fix the affected source's DKIM signing or return-path configuration, then send a live test. A temporary switch to a properly authenticated sending domain is another recovery option.
- If critical legitimate mail remains blocked, temporarily restore the last working policy at the applicable domain record. Keep rua reporting and review separate subdomain policies; changing the parent record does not override them.
- Allow cached DNS records to expire, verify delivery through the affected route, and resend messages that received a permanent rejection. Resume enforcement after the cause is fixed and fresh tests pass.
Aggregate reports generally arrive daily rather than immediately, as described in RFC 9990. Compare results by source and receiver after each policy change, while using SMTP logs and live tests for immediate troubleshooting.
Use Suped to monitor the transition
Suped's DMARC reporting product supports this workflow by turning aggregate reports into source-level findings and authentication issues to investigate before enforcement. Teams can use those findings and remediation steps to identify legitimate sources that need work, then verify fixes with live delivery tests.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped's product keeps authentication findings and alerts together after enforcement. DNS changes, vendor infrastructure changes, new senders, and altered routes still need review.
A practical Suped workflow
- Add domains: start collecting aggregate reports for every sending domain and subdomain.
- Review sources: separate verified senders, unknown traffic, and broken authentication.
- Fix issues: use issue detection and tailored steps before policy changes.
- Stage policy: move through quarantine and reject with monitoring still active.
- Keep alerts: watch for new failures and sending-source changes after enforcement. Alerts depend on incoming report data, so check sender logs for immediate delivery problems.
Use a dedicated report address to keep aggregate XML out of staff inboxes. Prioritize authentication fixes by legitimate sending volume and business impact.
