DMARC is now RFC 9989: what changed in May 2026

In May 2026 DMARC became an IETF standard, RFC 9989, replacing RFC 7489 from 2015. Three tags were removed, three were added, and receivers find a domain's policy a new way. A record written for RFC 7489 keeps working, but some of its tags now do nothing. Reports are now RFC 9990 (aggregate) and RFC 9991 (failure). We read every source on 14 November 2026.

What to change in your record

1. Remove rf and ri. Receivers that follow RFC 9989 ignore them, and they don't make the record invalid.
2. Testing a stronger policy: publish t=y beside pct=0, and remove both when testing ends. Receivers that follow RFC 9989 read t=y and ignore pct; older receivers do the opposite. Both then apply one level less: reject is treated as quarantine, and quarantine as none (older receivers give mail outside pct the next lower policy). Removing pct=0 alone would make older receivers apply the full policy at once. If your domain shows a logo in Gmail, keep pct=100, because Gmail needs it for the logo. Older receivers then apply the full policy, so test the stronger policy on a subdomain first.
3. A pct between 1 and 99 now counts as 100 at receivers that follow RFC 9989. Decide whether to apply the policy to all mail or go back to testing.
4. To cover subdomains that don't exist, such as invoices.example.com when you never created it, add np=reject. Older receivers ignore np and use sp, then p, so set those as you need them too.
5. Sign with DKIM before you reject. At p=reject, SPF alone is no longer enough.

The changes

Why pct went

The RFC says it plainly: "the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100". The advice to roll out with pct=10, then 50, then 100 no longer holds. t=y does what pct=0 did, and leaving t out does what pct=100 did.

Some pages still use pct. Google's DMARC setup page recommends it, and requires pct=100 on a domain that uses BIMI, the standard for showing a brand logo beside your mail. If your domain shows a logo in Gmail, keep pct=100: receivers that follow RFC 9989 ignore it.

np: subdomains that don't exist

Mail from a subdomain you never created, such as billing.example.com, now has its own policy. Without np, receivers use sp, then p.

The DNS tree walk

To find a domain's policy and its main domain, receivers used the Public Suffix List, a published list of the endings under which people register domains. RFC 9989 replaces the list with DNS lookups, walking up from the sending domain, at most eight. Receivers that still follow RFC 7489 use the list, so the two can disagree on unusual domains. The RFC's fix: publish a DMARC record on each domain you send from.

p=reject needs DKIM

"domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages." SPF breaks when mail is forwarded; a DKIM signature usually survives.

p=reject and mailing lists

RFC 9989 is more careful about reject than many guides: "domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject"". For those domains it advises p=none for at least a month, then p=quarantine for as long, before reject. It also tells receivers they "MUST NOT reject incoming messages solely on the basis of a "p=reject" policy".

Other rules still ask for reject: US federal agencies must publish p=reject under CISA BOD 18-01. Both are official; which applies depends on who you are and whether your users post to mailing lists.

What MailGlo does with each change

1. Removed tags: the checker and each domain's page report pct, rf and ri as retired. Changes MailGlo prepares keep them by default, and the change's warning says how to drop them.
2. t=y: MailGlo shows the policy receivers apply in testing mode, and its DMARC changes can set it.
3. np: MailGlo shows the policy for subdomains that don't exist beside the one for subdomains that do.
4. The tree walk: MailGlo uses it to find each domain's policy and to recalculate aggregate report results.
5. p=reject: a domain isn't ready for reject while one of its services passes DMARC with SPF alone. A change to reject warns about mailing lists.
6. Reports: MailGlo reads RFC 9990 aggregate reports and RFC 9991 failure reports, and still reads reports in the 2015 format.

Check your record

Check a domain reads your DMARC record and names any retired tag in it. DMARC explains the policies and reports, and what Gmail, Yahoo, Outlook and Apple require covers the providers' rules.