DMARC record checker

What changed in RFC 9989

DMARC stopped being an informational document and became Standards Track. Three things changed that affect records already published:

• pct was removed. Receivers implemented partial sampling inconsistently, so it is gone. A record carrying pct=50 is not broken, but receivers following the current specification ignore it, which means your policy applies to all of your mail rather than half of it. That is usually the opposite of what the person who set it intended.
• t= replaced it. t=y means testing: receivers report as normal but do not apply the policy. It is binary, which is the point — a staged rollout you can reason about.
• rf and ri were removed. rf was rarely implemented; ri was widely ignored, because receivers send aggregate reports on their own schedule.

The DNS Tree Walk

The larger change is how the Organizational Domain is found. RFC 7489 used the Public Suffix List. RFC 9989 replaces it with a DNS Tree Walk: query _dmarc at the name, then climb toward the root, at most eight queries, stopping at the first record that declares whether it is a public suffix domain via the psd tag.

This matters in practice. A subdomain with no record of its own inherits from the Organizational Domain through sp, and a subdomain that does not exist in DNS at all is governed by np, a tag RFC 9989 added. This checker performs the walk and shows every step.

What p=none actually means

It means monitoring. Receivers are asked to report but not to act. It is a valid, correctly published policy, and it satisfies what Gmail, Yahoo and Outlook.com ask of senders above their volume thresholds. It is not "broken", and a tool that marks it as a failure is measuring the wrong thing.

What it does not do is stop anyone sending mail that claims to be from your domain. Moving beyond it safely requires aggregate reports first, so you can see which legitimate systems would start failing.