What changed in the 2026 DMARC standard

In May 2026 DMARC was republished as three Standards Track documents: RFC 9989 (core), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). Together they obsolete RFC 7489 and RFC 9091, and move DMARC from Informational to Standards Track for the first time.

This scanner implements those documents. Here is what actually differs in practice.

1. The Public Suffix List is no longer how organizational domains are found

Under RFC 7489, working out the organizational domain for mail.eu.example.co.uk meant consulting the Public Suffix List, a large manually maintained file that every implementation had to ship and keep current.

RFC 9989 §4.6 replaces this with a DNS tree walk: query progressively shorter names, bounded at eight queries, stopping when a record carries a psd tag. For names of eight labels or more, the walk jumps straight to the rightmost seven rather than stepping down one at a time, which bounds the cost.

Practical effect: results no longer depend on how fresh anyone's copy of the PSL is. We ship no PSL.

2. pct, ri and rf are historic

The IANA DMARC registry marks pct, ri and rf as historic. pct was removed in RFC 9989.

This matters most for pct, which was widely used for staged rollout, such as pct=10 to apply a policy to a tenth of messages. Conforming receivers now ignore it, so a record relying on it for partial enforcement is not getting partial enforcement. The replacement signal is t=y, indicating a policy under test.

These tags remain extremely common in deployed records and are harmless. We report them as informational and they carry no score penalty, because flagging them as errors would be noise.

3. np, and clearer subdomain handling

np sets a policy specifically for subdomains that do not exist. Since no legitimate mail can originate from a subdomain that was never created, np=reject is usually safe even while the main policy is still being tightened.

4. Multiple records mean no policy

This was true before and remains true, but it is worth stating plainly because it is commonly reported incorrectly. When more than one DMARC record is returned for a name, all of them are discarded. The domain has no policy in force. Tools that report "multiple records found, using the first" do not match the specification, and the difference is material: the operator believes a policy is protecting them when none is.

Why we are explicit about this

Standards move, and tooling written against a superseded document keeps producing confident output. We cite the specific document and section on every finding so you can verify any result against the source rather than taking our word for it. If we are wrong about a rule, that citation is how you prove it.

We do not make claims about which other tools are or are not current. That would require testing each one individually and keeping evidence, which we have not done.