Current standard
What this RFC defines
RFC 9989 is the current specification of DMARC, the policy layer that ties SPF and DKIM to the domain a recipient sees in the From header. It was published on May 19, 2026, together with two companion documents: RFC 9990 for aggregate reports and RFC 9991 for failure reports. The three documents are known as DMARCbis and replace RFC 7489 (2015) and the experimental RFC 9091.
Why it matters for senders
For the first time, DMARC is an IETF Proposed Standard rather than an Informational document. In practice very little breaks: records still start with v=DMARC1, and the tags most senders use (p, sp, rua, ruf, adkim, aspf, fo) keep their meaning. What changes is how receivers find the policy for a domain, three tags that disappear, three that appear, and firmer guidance on when p=reject is appropriate.
RFC 9989 (May 2026, Proposed Standard) defines DMARC. Published at _dmarc.[domain] as a DNS TXT record starting with v=DMARC1. Policies: none, quarantine, reject. New tags: np (non-existent subdomains), psd (public suffix domain flag), t (test mode). Removed tags: pct, rf, ri. Organizational domain found by a DNS tree walk, capped at eight queries, instead of the Public Suffix List. Reporting lives in RFC 9990 (aggregate) and RFC 9991 (failure).
RFC 9989 at a glance
| Aspect | Detail |
|---|---|
| Status | Proposed Standard (IETF Standards Track) |
| Published | May 19, 2026 |
| Obsoletes | RFC 7489 (DMARC, 2015) and RFC 9091 (experimental PSD DMARC) |
| Companion documents | RFC 9990 (aggregate reporting), RFC 9991 (failure reporting) |
| Record location | DNS TXT at _dmarc.[domain] |
| Version tag | v=DMARC1 (unchanged, there is no DMARC2) |
| Policy discovery | DNS tree walk, at most eight queries |
| Backward compatible | Yes: a valid RFC 7489 record remains valid |
The DMARC record tags in RFC 9989
| Tag | Meaning | Default | Change vs RFC 7489 |
|---|---|---|---|
v | Version, must be the first tag, value DMARC1 | Required | Unchanged |
p | Domain Owner Assessment Policy: none, quarantine or reject | Treated as none if absent | Unchanged meaning |
sp | Policy for existing subdomains | Falls back to p | Unchanged |
np | Policy for non-existent subdomains | Falls back to sp, then p | New |
adkim | DKIM alignment: r (relaxed) or s (strict) | r | Unchanged |
aspf | SPF alignment: r (relaxed) or s (strict) | r | Unchanged |
rua | Where to send aggregate reports | None | Unchanged; report size limit in the URI removed |
ruf | Where to send failure reports | None | Unchanged |
fo | When to generate failure reports (0, 1, d, s) | 0 | Unchanged; ignored without ruf |
t | Test mode: y asks receivers to apply the policy one level lower | n | New, replaces part of pct |
psd | Public suffix domain flag: y, n or u | u | New (moved in from RFC 9091) |
pct, rf, ri | Percentage, failure report format, reporting interval | n/a | Removed |
Example records
_dmarc.example.com. IN TXT “v=DMARC1; p=reject; sp=reject; np=reject;
rua=mailto:dmarc-agg@example.com; adkim=r; aspf=r”
Testing a stricter policy before enforcing it:
_dmarc.example.com. IN TXT “v=DMARC1; p=reject; t=y;
rua=mailto:dmarc-agg@example.com”
(receivers apply quarantine instead of reject while t=y is present)
How the DNS tree walk finds the policy
RFC 7489 relied on the Public Suffix List to work out the organizational domain, but never said which list to use or how often to refresh it, so two receivers could reach different answers. RFC 9989 replaces it with DNS queries. The receiver looks for a DMARC record at the Author Domain, then removes labels from the left and queries each parent, until it finds a record or runs out of labels. A record carrying psd=y or psd=n stops the walk.
To stop a sender from forcing dozens of lookups with a very long domain name, the walk never makes more than eight queries: if the name has eight labels or more, the receiver jumps straight to the last seven. The RFC’s own example for a.b.c.d.e.f.g.h.i.j.mail.example.com:
_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
_dmarc.g.h.i.j.mail.example.com
_dmarc.h.i.j.mail.example.com
_dmarc.i.j.mail.example.com
_dmarc.j.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com
news.example.com the tree walk and the Public Suffix List both land on example.com. Differences appear for organizations with deep subdomain trees or several DMARC records at different levels, which is exactly the case the tree walk was designed to handle.What RFC 9989 says about p=reject
The new text is more explicit than RFC 7489 about the cost of p=reject:
- A domain that publishes
p=rejectMUST NOT rely on SPF alone and MUST sign its mail with valid DKIM, because forwarding and relaying break SPF while DKIM usually survives. - Domains whose users post to mailing lists SHOULD NOT publish
p=reject, since list modifications break DKIM and cause problems for the list and its subscribers. - Before moving to
p=reject, the RFC recommends publishingp=nonefor at least a month, thenp=quarantinefor an equally long period, and comparing the results in aggregate reports.
Migrating a record from RFC 7489
| If your record has | What to do |
|---|---|
pct=100 or no pct | Nothing; you can drop pct=100 as it no longer has a meaning |
pct below 100 to ramp up enforcement | Use t=y with the target policy instead. Receivers that still follow RFC 7489 keep reading pct, so keeping both during the transition does no harm |
rf=afrf or ri=86400 | Can be removed; RFC 9989 receivers ignore them |
| Subdomains that do not exist being spoofed | Add np=reject (or quarantine) at the organizational domain |
| A record at a public suffix or registry level | Only operators of public suffixes use psd=y; ordinary domains do not need psd |
Common mistakes with DMARCbis
v=DMARC1; a record with any other version is discarded by receivers.p=reject. Forwarded mail fails SPF, and without an aligned DKIM signature it fails DMARC and gets rejected.np or t where useful) is the safe choice during the transition.Related standards and further reading
Frequently asked questions
What is DMARCbis?
DMARCbis is the informal name of the DMARC revision the IETF published in May 2026 as three documents: RFC 9989 (the protocol), RFC 9990 (aggregate reports) and RFC 9991 (failure reports). Together they obsolete RFC 7489 and RFC 9091.
Do I need to change my DMARC record?
Not urgently. A working v=DMARC1 record stays valid. Review it if you use pct below 100 to ramp up enforcement (switch to t=y), if you want to protect non-existent subdomains (np), or if your domain is at p=reject without DKIM signing on every stream.
Is there a DMARC 2.0?
No. The version tag remains v=DMARC1 and RFC 9989 is backward compatible. “DMARC 2.0” is a marketing label for DMARCbis, not a new protocol version.
What does the t tag do?
t=y tells receivers that the domain owner is testing the published policy and asks them to apply it one level lower: p=reject; t=y is treated like quarantine, and p=quarantine; t=y like none. Reports are not affected. Receivers are not obliged to honor it.
Why was the Public Suffix List dropped?
RFC 7489 suggested the Public Suffix List but never required a specific list or refresh schedule, so receivers could disagree about a domain’s organizational domain. The DNS tree walk lets domain owners publish policy where they want in their own namespace and gives every receiver the same answer from DNS.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.