DMARC Grew New Teeth Without Breaking the Old Ones

TL;DR: DMARC’s 2026 standards update keeps existing records working while replacing Public Suffix List discovery with a DNS tree walk, removing pct, adding a testing flag and nonexistent-subdomain policy, and splitting reports into separate RFCs.

Email authentication has a new set of manuals. Your old record does not burst into flame at midnight.

DNS changes attract a specific kind of operator, the one who sees a new RFC and reaches for production with a coffee in the other hand.

I know that operator. I have been that operator, at a transmitter site at the end of a dirt road with nobody to check my work.

Here is why I am careful with this one. DNS fails the way a transfer switch fails. Not with an alarm. With nothing. Mail stops arriving somewhere you cannot see, and nobody tells you, because a person who did not get your message has no way of knowing they did not get it.

Brian Kerr’s Resend overview covers the practical changes. The primary specification is now RFC 9989, published on the Standards Track in May 2026. Aggregate reporting moved to RFC 9990 and failure reporting to RFC 9991.

The standard changes discovery, tags, and reporting

The new DMARC standard changes policy discovery, cleans up weak or confusing tags, and separates reporting from the core protocol.

Existing DMARC records remain valid. RFC 9989 obsoletes RFC 7489 and RFC 9091, but it preserves the central model: a domain owner publishes a policy, receivers evaluate SPF or DKIM alignment with the visible From: domain, and reports show who is sending mail under that name.

The old specification described an industry practice in an Informational RFC. The new core document is Standards Track, meaning the IETF has put the deployed protocol through its formal standards process.

Most of the actual work happens under the floorboards. Receivers change how they find the applicable organizational domain. Operators gain a clearer way to treat nonexistent subdomains.

Reporting formats and schedules lose knobs receivers rarely honored.

Nobody needs to redesign the mail room for the sake of having fresh paint.

---

How does the DNS tree walk change policy discovery?

Receivers can now discover DMARC policy by walking up the DNS hierarchy from the author domain and querying _dmarc records at each level.

Older DMARC processing relied on the Public Suffix List to decide where an organizational domain began. Every implementation needed a current copy of that community-maintained file and had to agree on how to use it.

DNS now carries more of its own boundary information. The tree walk checks parent names through a bounded procedure, while the psd tag lets a name state whether it is a public suffix domain. psd=y is intended for public suffix operators. psd=n can identify an organizational domain where the walk might otherwise continue.

Most domain owners should leave psd alone. Registry and complex-domain cases need it. A small sender who adds every new tag because the tag exists is wiring switches to an empty wall.

Query counts are capped to prevent runaway lookups. That matters at receiver scale, where a tiny waste multiplied across hostile mail becomes a denial-of-service tool wearing standards language.

pct, rf and ri are gone; t, np and psd are standardized

The update removes pct, rf, and ri, while standardizing or adding t, np, and psd behavior.

pct tried to apply enforcement to a percentage of failing mail. Receivers often ignored it. The new t=y flag indicates testing behavior, while t=n is the default full-policy behavior.

Resend recommends that senders using fractional pct values monitor under p=none, fix alignment, and then move to quarantine or reject instead of expecting partial enforcement.

The np tag closes a useful side door. It sets policy for nonexistent subdomains. A record such as np=reject asks receivers to reject mail claiming to come from an unprovisioned name like billing.example.com, subject to DMARC evaluation and receiver policy.

Failure reporting lost the rf tag because afrf was the only format ever registered for it, which made the tag decorative. RFC 9991 says the quieter part out loud: most large-scale providers limit or skip failure reports entirely, unwilling to ship a stranger’s mail headers inside a diagnostic email.

The ri interval tag is gone for a related reason. Receivers send aggregate reports on their own schedule regardless of what a domain requested.

rua stays the workhorse. A ruf destination still parses fine under the new spec, but don’t build a Monday around what shows up there.

Reports are still the instrument panel. Tightening policy without reading them is how a forgotten invoice service gets classified as an attacker on the last day of the month.

---

What should a domain owner do now?

A domain owner should inventory the current record, verify every legitimate sender, read aggregate reports, and change policy only after confirming SPF or DKIM alignment.

This network’s own migration ran into a version of that blind spot: every panel read green, DNS resolving, and a category of DNS record no dashboard would flag as missing went in late anyway, a full day after everyone assumed the registrar already had it handled. A missing DMARC record behaves the same way. It does not turn a dashboard red. It just leaves the door unlocked, and nobody is watching.

Start by querying the live _dmarc TXT record and saving the result. Identify every service sending with the domain in From:. Check DKIM signing domains, SPF return paths, and alignment.

Include boring systems: support desks, forms, stores, old automations, and the scanner in accounting that still thinks it is 2014.

Monitor before reject. A strong policy applied to an incomplete inventory blocks legitimate mail with excellent consistency.

Remove pct when the receiver environment and provider guidance support the new standard. Consider np=reject for domains that should never send from nonexistent subdomains. Check whether the DNS provider or mail platform has documented RFC 9989 behavior before changing a record through its panel.

Then test. Send through every approved route. Inspect Authentication-Results headers.

Watch aggregate reports for several normal business cycles, including monthly jobs that do not appear during a one-day test.

The new standard gives the machine better instructions. It does not know about the forgotten payroll vendor. That ghost belongs to whoever keeps the inventory.

Frequently asked questions

Do existing DMARC records stop working under RFC 9989?

No. The new standard preserves compatibility with existing records. Domain owners can adopt new features after checking provider and receiver support.

What replaced the DMARC pct tag?

RFC 9989 removes percentage enforcement and adds the boolean t testing flag. Use monitoring and staged policy changes instead of relying on fractional enforcement.

What does the DMARC np tag do?

The np tag publishes a policy for nonexistent subdomains, allowing a domain owner to request quarantine or rejection of mail claiming to come from names that have no DNS records.