Direct answer: the 2026 RFC 9989 (DMARC core), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) replace the 2015 RFC 7489 (and RFC 9091), and DMARC moves from Informational to Standards Track / Proposed Standard. The key change is not "one more DNS record": policy discovery moves from the Public Suffix List to a DNS Tree Walk, new np/psd/t tags are added, pct/rf/ri are removed, and aggregate/failure reporting moves into separate RFCs. The practical sender workflow is still: SPF + DKIM alignment → p=none with aggregate reports → fix every legitimate mail stream → p=quarantine → p=reject. Google/Yahoo also require DMARC, From alignment, one-click unsubscribe and a spam rate below 0.3% for bulk senders. If a domain has human users who post to mailing lists, do not jump straight to p=reject: RFC 9989 recommends p=none for at least a month, then p=quarantine for an equal period, and p=reject must not rely on SPF alone—valid DKIM is required.
This guide is for cross-border e-commerce/standalone stores, SaaS, transactional-email and email-marketing teams. It explains DMARCbis (RFC 9989/9990/9991), record syntax, the p=none → quarantine → reject migration, Google/Yahoo bulk-sender requirements, common failure modes and a 90-day checklist. Rules come from IETF RFC 9989/9990/9991 (published 2026), Google Workspace Email sender guidelines and Yahoo Sender Best Practices, all accessed 8 November 2026. Official rule facts, editorial advice and items to confirm are kept separate. This is not legal or procurement advice.
(1) DMARCbis is Standards Track: RFC 9989/9990/9991 replace 7489; policy discovery uses a DNS Tree Walk, and old receivers may compute a different Organizational Domain. Use strict alignment and publish a record for every Author Domain to remove ambiguity. (2) pct is removed; do not use percentage sampling. Migrate p=none → p=quarantine → p=reject, or use t=y test mode (one level lower). (3) The bulk-sender floor is SPF+DKIM+DMARC, From alignment, one-click unsubscribe and spam rate below 0.3%; p=reject requires DKIM, not SPF alone.
What changed: from 7489 to 9989/9990/9991
RFC 9989 is the DMARC core, RFC 9990 covers aggregate reports (rua) and RFC 9991 covers failure reports (ruf); together they replace RFC 7489, and RFC 9989 also replaces RFC 9091. The biggest engineering change is policy discovery: old implementations rely on the Public Suffix List to find the Organizational Domain, while the new specification uses a DNS Tree Walk and incorporates Public Suffix Domain (PSD) policy discovery. A receiver using the old implementation may disagree with the sender's expectation. RFC 9989's mitigation is to publish explicit DMARC records for every Author Domain in the organization and use strict alignment. It also adds np (non-existent subdomain policy), psd (PSD flag) and t (test mode), removes pct/rf/ri, and splits reporting into 9990/9991.
| Dimension | RFC 7489 (old) | RFC 9989/9990/9991 (new) |
|---|---|---|
| Status | Informational | Standards Track / Proposed Standard |
| Organizational Domain | Public Suffix List | DNS Tree Walk; includes PSD policy discovery |
| Tags added | - | np, psd, t |
| Tags removed | pct, rf, ri | No longer used; reporting split into 9990/9991 |
| Reporting | Described in the core document | RFC 9990 aggregate, RFC 9991 failure |
| Interoperability risk | PSL version differences | Tree Walk vs PSL may find different Organizational Domains |
| Mitigation | - | Strict alignment plus explicit records for every Author Domain |
Sources: IETF RFC 9989 (2026, Appendix C "Changes from RFC 7489"), RFC 9990 and RFC 9991. Editorial summary; implementation differences follow the receiver/tool documentation.
Record syntax: core tags and examples
A DMARC record is still a DNS TXT record: v=DMARC1; p=...; rua=...; ruf=...; fo=...; adkim=...; aspf=...; sp=...; np=...; t=.... p is the organizational-domain policy, sp the subdomain policy and np the non-existent-subdomain policy; adkim/aspf control DKIM/SPF alignment (r = relaxed default, s = strict); rua/ruf are aggregate/failure report destinations; fo controls failure-report options; t=y is test mode (applies the policy one level lower, e.g. p=reject + t=y treats failures as quarantine); psd=y is only for Public Suffix Domains and should not be set on ordinary domains. pct is removed; do not use "pct=25" for gradual rollout.
| Tag | Purpose | Editorial advice |
|---|---|---|
| v=DMARC1 | Version | Fixed; must come first |
| p=none/quarantine/reject | Organizational-domain policy | Start with none; escalate based on reports |
| sp= | Subdomain policy | Evaluate separately when many subdomains; otherwise inherits p |
| np= | Non-existent subdomain policy | Blocks subdomain spoofing; set as needed |
| rua= | Aggregate report destination | At least one; use a dedicated mailbox/analyzer |
| ruf= | Failure report destination | Optional; watch privacy and volume |
| fo= | Failure report options | 0/1/d/s common; based on troubleshooting needs |
| adkim/aspf | DKIM/SPF alignment | r default; use s to remove Tree Walk ambiguity |
| t=y | Test mode | One level lower; not a substitute for staged migration |
| psd=y | PSD flag | Public Suffix Domains only |
| pct/rf/ri | Removed | Do not rely on them; use new tags/staging |
Sources: IETF RFC 9989 (Sections 4/6 and Appendix C), RFC 9990/9991. Editorial summary; validate syntax before publishing—one malformed record can invalidate the domain policy.
Migration path: p=none -> quarantine -> reject
RFC 9989 recommends starting with p=none (Monitoring Mode) and using rua aggregate reports to audit every sending stream. Once legitimate mail passes SPF/DKIM alignment, move to quarantine/reject. For domains with human users who post to Internet mailing lists, the RFC explicitly recommends p=none for at least a month, then p=quarantine for an equal period, comparing dispositions before deciding on p=reject; p=reject must not rely on SPF alone and requires valid DKIM. Transactional/system-only domains can usually move faster, but still start from reports.
| Stage | Example record | Entry/exit criteria |
|---|---|---|
| Monitoring | v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r | Reports received; legitimate streams inventoried |
| Testing | v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com | Validate reject behavior, but apply one level lower first |
| Quarantine | v=DMARC1; p=quarantine; sp=quarantine; rua=...; ruf=...; fo=1; adkim=s; aspf=s | Legitimate mail passes; no high-volume failures |
| Reject | v=DMARC1; p=reject; sp=reject; np=reject; rua=...; ruf=...; fo=1; adkim=s; aspf=s | No legitimate mail blocked in quarantine; DKIM in place; rollback plan |
| Subdomains | Publish a record per Author Domain; control with sp/np | Avoid inheritance ambiguity; cover all subdomains |
Editorial migration examples, not an official template; syntax/policy follows RFC 9989. The "p=none one month, quarantine equal period" recommendation is for domains with mailing-list users; transactional-only domains may move faster based on report quality.
Receiver requirements: Google and Yahoo bulk-sender floor
For personal Gmail accounts, Google requires all senders to have SPF or DKIM, valid PTR, TLS, a spam rate below 0.3% and RFC 5322 compliance; senders above 5,000 messages/day must also have SPF+DKIM+DMARC (p=none allowed), From-domain alignment with SPF or DKIM, and one-click unsubscribe for marketing/subscribed messages (List-Unsubscribe-Post + List-Unsubscribe). Yahoo requires bulk senders to have SPF+DKIM, DMARC at least p=none with DMARC passing, From alignment (relaxed acceptable), one-click unsubscribe (RFC 8058 recommended, mailto acceptable), a visible unsubscribe link in the body, unsubscribe handling within 2 days and a spam rate below 0.3%. These are inbox-entry requirements, not optional extras.
| Requirement | Google (personal Gmail) | Yahoo (bulk sender) |
|---|---|---|
| SPF/DKIM | All senders SPF or DKIM; 5,000+/day SPF+DKIM | All SPF or DKIM; bulk SPF+DKIM |
| DMARC | Required at 5,000+/day; p=none allowed | Bulk at least p=none, with DMARC passing |
| From alignment | From domain aligned with SPF or DKIM | Relaxed alignment acceptable |
| One-click unsubscribe | Required for marketing/subscribed; List-Unsubscribe-Post | Required; RFC 8058 recommended, mailto acceptable |
| Unsubscribe handling | Process one-click requests | Within 2 days; visible link in body |
| Spam rate | Below 0.3% | Below 0.3% |
| Other | PTR, TLS, RFC 5322; no Gmail From impersonation | PTR, RFC 5321/5322 |
Sources: Google Workspace "Email sender guidelines" (accessed 8 November 2026); Yahoo "Sender Best Practices" (accessed 8 November 2026). Editorial summary; "bulk" definitions/enforcement follow each provider's latest page and may change.
Common failure modes: why DMARC still lands in spam
A DMARC pass only proves the From domain is authorized; it does not guarantee content, reputation or unsubscribe experience. Common failures: SPF exceeds 10 DNS lookups, DKIM signs with the ESP's own domain and does not align with From, subdomains have no record and inherit the organizational policy, mailing lists/forwarding break SPF, old receivers use the PSL while new ones use the Tree Walk and find a different Organizational Domain, and teams still use the removed pct tag. Another frequent issue is missing one-click unsubscribe, or unsubscribe requests not processed within 2 days.
| Failure mode | Symptom | Control |
|---|---|---|
| SPF lookup limit | permerror; some streams fail | Reduce includes, merge SPF, rely on DKIM |
| DKIM not aligned | DMARC fail even when DKIM passes | Sign with your own domain; check d= vs From |
| No subdomain record | Inherits organizational policy; over/under-blocking | Per-subdomain records; use sp/np |
| Mailing lists/forwarding | SPF breaks; DKIM may survive | Test before p=reject; ensure DKIM |
| Tree Walk ambiguity | Old/new receivers disagree | Strict alignment + record per Author Domain |
| Still using pct | Policy does not apply as expected | Remove pct; use staged policy/t=y |
| No one-click unsubscribe | Bulk mail throttled/spam-foldered | List-Unsubscribe-Post; process within 2 days |
| Poor reputation/complaints | Spam rate above 0.3% | Clean lists, confirmed opt-in, monitor Postmaster/CFL |
Editorial failure list, not an official checklist; SPF/DKIM/DMARC errors follow RFC 9989/7208/6376 and receiver reports.
90-day implementation checklist
Use the first 90 days to connect the domain/subdomain inventory, SPF/DKIM alignment, p=none reporting, legitimate-stream fixes, one-click unsubscribe and policy escalation. The order is inventory, authentication, monitoring, fixing, quarantine, reject, continuous monitoring. Do not jump to p=reject, and do not stay at p=none forever without reports.
| Phase | Action | Output |
|---|---|---|
| Weeks 1-2 | Inventory all sending domains/subdomains/ESPs/transactional/marketing streams | Domain and stream list, owners |
| Weeks 2-3 | Add SPF/DKIM; confirm DKIM d= aligns with From; PTR/TLS | Authentication baseline, alignment report |
| Weeks 3-4 | Publish p=none + rua; connect a DMARC analyzer/mailbox | Aggregate reports, baseline |
| Weeks 4-8 | Fix legitimate streams from reports; handle lists/forwarding/subdomains | Failure list, remediation log |
| Weeks 8-10 | Escalate to p=quarantine; watch false positives; prepare rollback | Quarantine report, rollback plan |
| Weeks 10-12 | Escalate to p=reject (with DKIM); roll out domain by domain | Reject policy, monitoring |
| Ongoing | One-click unsubscribe, spam rate, reports/alerts, quarterly review | Monthly review, SLA |
Editorial implementation advice, not an official template; policy, reporting tools, unsubscribe implementation and receiver requirements follow RFC 9989/9990/9991 and the Google/Yahoo pages.
FAQ
What is DMARCbis, and is it in force?
DMARCbis is the IETF rewrite of DMARC: RFC 9989 (core), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting), published in 2026, replacing RFC 7489/9091. It is Standards Track/Proposed Standard; receivers/tools will implement it over time, and senders should review records and policy against the new specification.
What is the biggest change in RFC 9989?
Policy discovery moves from the Public Suffix List to a DNS Tree Walk (including PSD policy), np/psd/t tags are added, pct/rf/ri are removed, and reporting moves to 9990/9991. Old receivers may compute a different Organizational Domain; use strict alignment and publish explicit records for every Author Domain.
Can we still use pct?
RFC 9989 removes pct; do not use "pct=25" for gradual rollout. To test, use t=y (one level lower), or migrate p=none -> quarantine -> reject in stages.
Is p=reject always better, and sooner?
No. Start with p=none and reports, fix legitimate streams; for domains with mailing-list users, the RFC recommends p=none for at least a month and p=quarantine for an equal period before considering p=reject. p=reject cannot rely on SPF alone and requires valid DKIM.
Does DMARC guarantee inbox placement?
No. DMARC only validates authorization of the From domain; it does not guarantee content, reputation or unsubscribe experience. Google/Yahoo also look at spam rate below 0.3%, one-click unsubscribe, PTR/TLS, etc. DMARC is necessary, not sufficient.
What are the Google/Yahoo bulk thresholds?
Google requires senders above 5,000 messages/day to personal Gmail to use SPF+DKIM+DMARC, From alignment and one-click unsubscribe; Yahoo requires bulk senders to use SPF+DKIM, DMARC at least p=none, From alignment, one-click/two-day unsubscribe. Check each provider's page for definitions/enforcement.
Should subdomains have their own DMARC records?
Yes, preferably. A subdomain without a record inherits the organizational policy; use sp for subdomains and np for non-existent subdomains. RFC 9989 also recommends explicit records for every Author Domain to avoid Tree Walk/PSL differences.
How do we implement one-click unsubscribe?
Add List-Unsubscribe-Post: List-Unsubscribe=One-Click and List-Unsubscribe: <https://...> to marketing/subscribed mail, and implement page-less POST unsubscribe; Yahoo also requires a visible body link and processing within 2 days. Decide for transactional mail based on business/receiver rules.
Research method and limitations
This article separates "official rule facts" from "editorial advice." The RFC 9989/9990/9991 status, DNS Tree Walk, PSD, np/psd/t, removal of pct/rf/ri, reporting split and the p=reject/DKIM/mailing-list caveats come from IETF RFC 9989 (2026, Appendix C) and 9990/9991. Google's 5,000/day threshold, SPF+DKIM+DMARC, From alignment, one-click, spam rate below 0.3% and PTR/TLS/RFC 5322 come from Google Workspace Email sender guidelines. Yahoo's bulk SPF+DKIM, DMARC at least p=none, relaxed alignment, RFC 8058/two-day unsubscribe and spam rate below 0.3% come from Yahoo Sender Best Practices. Migration stages, the 90-day checklist and failure modes are editorial.
Eight limitations: (1) this is not legal/compliance advice; (2) DMARCbis implementation progress at each receiver is not checked individually; (3) ESP/tool record-syntax differences are not covered; (4) SPF 10-lookup limits, DKIM key rotation, ARC/forwarding and related details are not expanded; (5) DMARC report-tool privacy/cost is not assessed; (6) BIMI/VMC is not covered; (7) no real sending test/reputation data is included; (8) Google/Yahoo rules may change, so recheck the official pages before implementation.
Sources and basis
- IETF RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (2026): rfc-editor.org/rfc/rfc9989. Core specification, DNS Tree Walk, np/psd/t, pct/rf/ri removal, Appendix C changes. Accessed 8 November 2026.
- IETF RFC 9990, DMARC Aggregate Reporting (2026): rfc-editor.org/rfc/rfc9990. Aggregate report format/sending. Accessed 8 November 2026.
- IETF RFC 9991, DMARC Failure Reporting (2026): rfc-editor.org/rfc/rfc9991. Failure reports. Accessed 8 November 2026.
- Google Workspace, Email sender guidelines: support.google.com/a/answer/81126. All-sender/5,000+ bulk requirements, one-click, spam rate. Accessed 8 November 2026.
- Yahoo, Sender Best Practices: senders.yahooinc.com/best-practices. Bulk SPF/DKIM/DMARC, one-click/unsubscribe timing, spam rate. Accessed 8 November 2026.
Data cut-off 8 November 2026; DMARC/sender requirements follow the IETF RFCs and the latest Google/Yahoo pages; this is not legal, compliance or procurement advice.