DMARCbis (RFC 9989): What Changed In Your DMARC Record

Introduction

Your DMARC record was written years ago, copied from a guide that recommended `pct=100; rf=afrf; ri=86400`. Now a checker flags three of those tags as retired, a vendor newsletter says DMARCbis is here, and you cannot tell whether your record is broken, outdated or fine.

Mostly fine. DMARCbis was published in May 2026 as three documents: RFC 9989 for the core protocol, RFC 9990 for aggregate reports and RFC 9991 for failure reports. Together they obsolete RFC 7489. The record format is the same, and every tag a typical record uses still works. Three tags were retired, three were added, and receivers now find your policy by walking the DNS instead of consulting an outside list. A record that worked last year keeps working, but a few edits make it say what you mean under both standards.

Why DMARCbis Replaced RFC 7489

RFC 7489 was published in 2015 as an Informational document, not a standard. It described DMARC as deployed at the time. RFC 9989 is Standards Track (Appendix C.1), fixes the errata collected over a decade (C.9), and moves reporting into its own documents (C.4). For you as a domain owner, the practical changes are in the tags and in how receivers find your record.

Every DMARC Tag That Changed In RFC 9989

Nothing breaks when an old tag stays in your record, because RFC 9989 §4.7 says unknown tags MUST be ignored. The same rule lets receivers that still follow RFC 7489 skip t, np and psd. That is what makes a gradual transition possible, and it is also the trap: a tag one group of receivers ignores can change what the other group does.

From The Percentage Tag To Test Mode

pct was meant to let you enforce on a sample: quarantine 25% of failing mail, then 50%. Appendix A.6 of RFC 9989 records that in practice only 0 and 100 behaved predictably. pct=0 turned out to be useful for a different reason: some intermediaries, such as mailing lists, treated it as a signal to rewrite the From header, which showed domain owners how much of their mail passed through them. So the new standard keeps that behaviour as a yes-or-no flag, t, and calls t=y and t=n analogous to pct=0 and pct=100.

Receivers are mid-transition, so a test-mode record should carry both:

v=DMARC1; p=reject; pct=0; t=y; rua=mailto:[email protected]

A receiver on RFC 9989 reads t=y and treats reject as quarantine. One on RFC 7489 ignores t, reads pct=0, and applies the policy to none of the failing mail, which for reject means falling back to quarantine and for quarantine means its normal filtering (RFC 7489 §6.6.4). Publishing t=y alone is the mistake to avoid: older receivers would enforce the full policy you thought you were only testing. And t does nothing with p=none, because there is no lower level to step down to.

The DNS Tree Walk Replaces The Public Suffix List

Under RFC 7489, a receiver handling mail from news.example.com with no record of its own worked out the organisational domain, example.com, from a Public Suffix List. The RFC never said which list or how often to refresh it, so receivers could disagree (RFC 9989 §4.10). RFC 9989 drops the list. Receivers query _dmarc at the Author Domain, then walk up one label at a time, with at most eight queries however long the name is.

_dmarc.alerts.eu.example.com
_dmarc.eu.example.com
_dmarc.example.com
_dmarc.com

For a typical domain the answer is the same as before: subdomains inherit the record at _dmarc.example.com. The difference shows up in large organisations, where a record published at an intermediate level such as eu.example.com can now be found, letting a regional team run its own policy without touching the parent. The same walk decides the organisational domain used for relaxed alignment, which is why psd exists and why an ordinary domain should never set it: psd=n fixes where that boundary sits.

The New Policy For Subdomains That Do Not Exist

Spammers like made-up subdomains: billing.example.com looks plausible even when the name has no DNS records at all. np lets you set a policy just for those names, separate from sp, which covers subdomains that exist. Because no legitimate mail comes from a name that does not exist, np=reject is safe to publish even while your main policy is still none. Receivers on RFC 7489 ignore it and fall back to sp or p, so it adds protection without risk.

What To Change In Your Record Today

1. Delete rf and ri. Neither does anything under RFC 9989, and if yours hold the old defaults, rf=afrf and ri=86400, older receivers behave the same without them.
2. Remove size limits such as !10m from your rua and ruf addresses.
3. Replace a partial pct. If you publish pct=25 or pct=50, choose: the full policy with no pct, or test mode with pct=0; t=y.
4. Add t=y wherever you have pct=0, so new receivers keep treating the record as a test.
5. Consider np=reject if your main domain is still at none or quarantine.
6. Keep p second, right after v=DMARC1. RFC 7489's grammar puts it there, so receivers still on that standard expect it in that position.

Here is a common legacy record and its updated form:

Before: v=DMARC1; p=quarantine; pct=100; rf=afrf; ri=86400; rua=mailto:[email protected]!10m
After:  v=DMARC1; p=quarantine; np=reject; rua=mailto:[email protected]

One rule did not change but matters more now that reports are documented separately: if your rua address is on another domain, that domain must publish a TXT record at example.com._report._dmarc.theirdomain containing v=DMARC1, or receivers drop your reports (RFC 9990 §4).

DMARCbis Questions

Do I Have To Update My DMARC Record For RFC 9989?

No. A valid RFC 7489 record still works, because the format is unchanged and receivers ignore tags they do not know. Updating is worth it if you use a partial pct, which new receivers ignore, or pct=0 without t=y, which new receivers treat as a full policy. Removing rf, ri and size limits is tidy but changes nothing.

Is There A New DMARC Version Tag?

No. Records still start with v=DMARC1, written exactly that way. RFC 9989 kept the version so that one record serves receivers on both standards. A record that starts with anything else, or puts another tag before v=DMARC1, is ignored, under the old standard and the new one alike.

Did DMARC Alignment Change In RFC 9989?

The rules did not: relaxed alignment still means sharing an organisational domain, strict still means identical, and relaxed is still the default. What changed is how the organisational domain is found, by the DNS tree walk instead of a public suffix list. For ordinary domains the result is the same, so alignment that passed before still passes.

Do Gmail, Yahoo And Outlook Follow RFC 9989 Yet?

Their published sender requirements ask for a DMARC record with a policy of at least none and alignment with SPF or DKIM, which is true under both standards. None of the three has said publicly when its receivers will read t or np, so write records that behave correctly either way, such as pct=0 with t=y.

How Eklow Handles This

The free DMARC record generator is built on RFC 9989, RFC 9990 and RFC 9991 and writes records that behave the same under RFC 7489. It never offers a partial percentage: test mode writes pct=0 and t=y together, and only when the policy is quarantine or reject. Its Check tab reads your live record and flags retired tags (pct values between 1 and 99, rf, ri, size limits), t=y published without pct=0, a pct and t that disagree, np with a note that older receivers ignore it, and a report address on another domain that has not authorised your reports. Each finding says what receivers on each standard will do with the tag.

Domains you connect to Eklow are asked for a minimal record, p=none with aggregate reports collected, which carries none of the retired tags. Verification accepts any valid DMARC record you already publish, and the domain is re-checked every six hours. The domain verification guide lists every record Eklow asks for, and SPF, DKIM and DMARC explained for founders covers how DMARC sits beside the other two.