Move DMARC from p=none to stronger enforcement only after inventorying every legitimate sender through aggregate reports and fixing alignment. In 2026, RFC 9989 makes p=reject unsuitable for many domains that host human mailboxes used with mailing lists; prefer p=quarantine for those domains while pure transactional domains can safely reach p=reject. Use the new t=y testing tag and np=reject for non-existent subdomains, and always keep a rollback path.
Why staged DMARC enforcement still matters
The problem is simple: jumping straight to p=reject can bounce legitimate mail from forgotten senders, mailing lists, or third-party tools that do not yet align. A report-driven rollout discovers those sources first, fixes SPF/DKIM alignment, then tightens policy gradually so legitimate traffic is not disrupted. Outcomes include reduced spoofing, better inbox placement, and fewer surprise bounces.
RFC 9989 changes that affect the rollout
RFC 9989 (May 2026) replaced the older informational RFC 7489 and became a Proposed Standard. Key practical changes:
- The pct tag is retired; use t=y instead. A record with p=reject; t=y asks receivers to treat it like quarantine during testing.
- New np= tag sets policy for non-existent subdomains (NXDOMAIN). np=reject closes a common spoofing gap.
- Guidance against p=reject on general-purpose domains where users participate in mailing lists; receivers may treat failing p=reject as quarantine in some cases.
- Existing records continue to work; update when you next change policy.
Verify current receiver behavior, as transition periods can vary.
Stage-by-stage rollout playbook
Stage 1 – Monitor (p=none + rua): Publish p=none with an aggregate report address. Stay here 2–4 weeks (or longer if volume is high) while you inventory every source. Learn to read the reports in our guide to reading DMARC reports.
Stage 2 – Fix alignment: Correct SPF and DKIM so legitimate mail passes alignment. Alignment is the whole game; see why alignment matters more than a simple pass. Review SPF, DKIM, and DMARC fundamentals if needed.
Stage 3 – Quarantine (with testing): Move to p=quarantine. Use t=y while testing so the effective policy is softer. Monitor reports for any remaining legitimate failures. Duration: 1–2 weeks of clean data.
Stage 4 – Reject only where appropriate: Pure transactional or machine-only domains can move to p=reject (optionally with np=reject). Domains with human mailboxes and list traffic should usually stay at p=quarantine. Always keep the ability to roll back to a previous record within minutes via DNS.
ArawaMail domain onboarding publishes SPF, DKIM, and custom MAIL FROM when you activate receiving then sending; you still own and publish the DMARC record yourself. See the DNS records reference and domain setup guides.
How we analyzed this
We reviewed RFC 9989 and companion reporting documents, cross-checked secondary analyses of the new tags (t, np, psd) and the retirement of pct, and mapped the guidance against real operational constraints of mixed human + transactional domains. We prioritized report-driven decisions and explicit caveats for mailing-list domains over generic “always go to reject” advice. No invented metrics; all policy recommendations are conditional on inventory and alignment results.
FAQ
How long should I stay on p=none?
Until aggregate reports show a complete inventory of legitimate senders and you have fixed alignment issues—commonly 2–4 weeks, longer for complex environments.
When is p=reject the right choice after RFC 9989?
Best for pure transactional or no-human-mailbox domains. Avoid or delay for domains whose users post to mailing lists; prefer p=quarantine plus np=reject.
What does t=y do?
It requests testing behavior: the published policy is applied one level softer (reject behaves as quarantine, quarantine as none).
How do I roll back a bad policy change?
Change the DNS TXT record back to the previous value. Most receivers pick up the change within minutes to a few hours; keep the old record text ready.
Does ArawaMail handle DMARC for me?
No. Domain activation publishes SPF, DKIM, and custom MAIL FROM. You still publish and monitor the DMARC policy yourself and review reports.
Further reading: DNS & deliverability guides, SPF/DKIM/DMARC on subdomains.