DMARC in 2026: What RFC 9989 Changes for Senders

Your ESP sends a notice that says “DMARCbis is now RFC 9989.” A DNS vendor’s banner says the same thing, with a button labeled “Update your record.” You open your DNS panel, look at the v=DMARC1; p=none line that has passed Gmail’s checks for two years, and wonder whether it just became wrong.

It did not. DMARCbis shipped: in May 2026 the IETF published RFC 9989, an Internet Standards Track document that obsoletes RFC 7489 and RFC 9091. People have been calling the draft “DMARC 2.0.” The published name is still DMARC. The version your DNS record uses is still v=DMARC1.

If you only needed the operator’s explanation of the record you publish today, what DMARC is is that page. This one is the delta, and what it does not entitle you to change. Of the six changes in the table below, none requires you to edit a record that already passes DMARC at Gmail, Yahoo, and Outlook today. That is a statement about provider enforcement pages as checked on 26 September 2026, not a promise that receivers will never adopt the new tags, so recheck when a provider updates its requirements.

Last verified: 26 September 2026, against RFC 9989 (May 2026), RFC 9990, and RFC 9991.

What changed in DMARC in 2026

RFC 7489 was Informational, published outside an IETF working group. RFC 9989 is Standards Track. Appendix C of RFC 9989 is the change list. The items that affect your DNS are these.

The Tree Walk warning is the one to read twice. RFC 9989 says a domain owner can expect one organizational domain from the Tree Walk while a receiver still implemented to RFC 7489, using a Public Suffix List, arrives at another. The document’s own avoidance is strict alignment and an explicit DMARC record on every author domain you actually send from. That is also the right setup if you send from store.com and mail.store.com. Sending architecture is where those names get chosen. Domain alignment is what “explicit record and aligned signature” means in practice.

What did not change for Gmail, Yahoo, or Outlook

Publishing a new RFC does not rewrite a provider’s enforcement page.

• Gmail’s sender guidelines still require bulk senders to publish DMARC. p=none is enough for that requirement. Alignment still has to succeed.
• Yahoo’s sender requirements still say bulk senders need a DMARC policy of at least p=none and a DMARC pass. Relaxed alignment is still described as acceptable there.
• Microsoft’s 550 5.7.515 article still accepts p=none, p=quarantine, or p=reject, and still requires both SPF and DKIM to pass for high-volume From domains.

None of those pages, as checked on 26 September 2026, tell you to delete pct or to add t=. If you publish t=y and a receiver still only implements RFC 7489, do not assume the testing behavior you wanted. If you leave pct=25 in a record, you are publishing a tag the new spec removed, and RFC 9989’s authors already said intermediate percentages were the unreliable ones.

DKIM2 is a separate draft track. What DKIM2 is is that story. It does not replace the DMARC record, and RFC 9989 does not implement DKIM2.

What you should do with your DMARC record in 2026

Leave a working p=none or p=quarantine record in place if live mail aligns. The risk in a rushed edit is a syntax error that removes the record providers already require.

Do not jump to p=reject because the RFC is now Standards Track. Section 7.4 says domains with general users who post to mailing lists SHOULD NOT use p=reject. Your store’s domain often also sends through forwards, a helpdesk, and a review app. Section 7.4 also says any domain that does publish p=reject MUST NOT depend on SPF alone and MUST DKIM-sign. The same section says receivers MUST NOT reject solely on p=reject, and MUST treat the failure as p=quarantine when they have nothing else to go on. So p=reject is not a switch that makes every mailbox refuse forgeries, and it is a switch that can break indirect mail.

Put an explicit record on each From domain you use, so you are not depending on a parent-domain walk that two receivers might compute differently during the overlap of RFC 7489 and RFC 9989 implementations.

Keep reading aggregate reports. The bytes moved to RFC 9990. The decision did not. You still need to see the source that fails before you tighten p=. The order of that tightening is moving from monitoring to enforcement. DMARC monitoring checks your published DMARC policy record every 24 hours and alerts you when it changes. No DMARC record is the case where you do not have a record to revise.

DMARC 2026 claims to avoid

• Do not announce to a client that “DMARC 2.0 is required for inbox placement.” It is not a provider requirement under that name, and DMARC has never been a placement guarantee.
• Do not remove rua because reporting moved to another RFC. You still want the reports. Confirm the destination accepts them.
• Do not treat t=y as a quiet way to enforce p=reject on a percentage of mail. The new tag is a testing flag with two values, not a replacement for a careful policy ramp.

Sources

• RFC 9989, IETF, May 2026. DMARC, obsoletes RFC 7489 and RFC 9091. Appendix A.6 (pct and t), Appendix C (change list), Section 7.4 (p=reject).
• RFC 9990, IETF, May 2026. Aggregate reporting.
• RFC 9991, IETF, May 2026. Failure reporting.
• Email sender guidelines, Google.
• Sender best practices, Yahoo.
• Fix NDR 550 5.7.515, Microsoft.