DMARC is now an official internet standard, and the pct tag you may still be using is gone

DMARC, the record that tells mailbox providers what to do with mail that fails authentication in your name, just became an official internet standard for the first time. In May 2026 the IETF published RFC 9989, the revised core specification, which replaces the original DMARC document, RFC 7489 from 2015. The reporting formats moved into two companion documents, RFC 9990 for aggregate reports and RFC 9991 for failure reports. The headline is a status change: DMARC went from an Informational document to a Proposed Standard on the standards track. Most of what changed is under the hood for the receivers that evaluate your mail, but two changes touch the record you publish.

The pct tag has been removed

The old specification let you stage enforcement with a percentage tag, written pct=, which applied your policy of quarantine or reject to only a share of your mail while you watched the reports and built confidence. RFC 9989 removes pct entirely. The staged path now is to tighten the policy itself, moving from none to quarantine to reject as your reports come back clean, and to use the subdomain tags below rather than a percentage dial. Receivers may still tolerate a leftover pct during the transition, but it is no longer part of the standard, so do not build a rollout around it. If your published record still carries pct=, treat this as the moment to move that logic into the policy value.

A new np tag closes the non-existent-subdomain gap

DMARC now has an np tag, a policy that applies specifically to non-existent subdomains of your domain, the ones with no address or mail record because you never created them. It sits alongside the two policy tags that were already there: p, which covers your domain, and sp, which covers subdomains that do exist. The gap np closes is a favourite of spoofers: a made-up subdomain such as invoices.yourbrand.com that you never set up can otherwise slip through. Setting np=reject tells receivers to reject mail claiming to come from subdomains that do not exist, without changing how your real subdomains are handled. If you send only from your main domain, np=reject is a low-risk line to add.

How receivers find your domain changed too

To decide whether a From address is aligned and which policy applies, a receiver has to work out your organizational domain, the yourbrand.com sitting behind mail.yourbrand.com. The old specification leaned on the Public Suffix List, a community-maintained file of domain suffixes. RFC 9989 replaces that with a DNS tree walk: the receiver queries up the domain tree to find your record, capped at eight lookups so the mechanism cannot be abused to force endless queries. You do not configure this, it is receiver-side, but it is why publishing your policy at the organizational domain, and adding sp and np where you need them, is worth getting right.

What did not change, so this is not a fire drill

The requirements the mailbox providers actually enforce are untouched. Since 2024 for Gmail and Yahoo and since May 2025 for Microsoft, bulk senders, roughly those sending 5,000 or more a day, need SPF, DKIM and a DMARC record, with p=none accepted as the minimum policy, a spam-complaint rate kept under 0.3 percent, and one-click unsubscribe on marketing mail. None of that moved with the new standard. A DMARC record that passed last week still passes. RFC 9989 formalises the protocol and tidies the record you publish; it does not add a new deadline or a new gate to clear.

Our free cold-email deliverability setup tool checks your SPF, DKIM and DMARC and shows the record to publish, and our guide on why cold email lands in spam walks the same three records plus the complaint-rate and unsubscribe rules the mailbox providers enforce. If your current DMARC record still uses pct=, this is the moment to fold that into the policy value and, if you send only from your main domain, to add np=reject.