DMARC in 2026: what RFC 9989, 9990 and 9991 changed

Which RFCs to cite now, and the old record vs the new one

The 2015 document, RFC 7489, was Informational and carried DMARC, aggregate reporting and failure reporting in one place. The 2026 replacement splits that into three Standards Track documents: RFC 9989 for the DMARC protocol and record, RFC 9990 for aggregate (rua) reporting, and RFC 9991 for failure (ruf) reporting. When you write a runbook or a ticket, cite the specific RFC and year, because a checker or a colleague working from a pre-2026 article will reach different conclusions about the same record.

Most of the practical changes are things you can see in a published record: a tag that no longer does anything, a size suffix that validators now flag, or a policy that resolves differently because discovery rules changed. The table below is the quick reference; the sections after it link each change to the field note that works through it.

Policy discovery: the DNS tree walk replaced the Public Suffix List

Under the old model a receiver used the Public Suffix List to decide where your Organizational Domain boundary was, then looked for a DMARC record there. The 2026 spec removes that dependency. A receiver now performs a DNS tree walk: it queries _dmarc at the exact From domain, and if there is no record it climbs one label at a time, up to a bounded number of steps, until it finds one or runs out of labels.

The practical effect is that a stale public-suffix entry and a current tree-walk implementation can disagree about which policy applies to a multi-label domain, and that disagreement looks mysterious because both tools show valid DNS. Publish an explicit record at the domain you actually want to govern, and log each _dmarc query and the stopping point when you debug.

• DMARC's 2026 DNS Tree Walk: why RFC 9989 no longer relies on a public-suffix list

pct is gone: stage enforcement on evidence, not a percentage

The pct tag let a domain apply its policy to only a fraction of failing mail. Receivers implemented it inconsistently, so the current spec removed it. Records copied from old tutorials often still carry something like p=quarantine; pct=10, and some validators render that as syntactically fine even though the percentage no longer means anything.

Staged rollout now works differently: publish p=none first and use the aggregate reports as a sender inventory until every legitimate stream aligns, then move to quarantine and reject. A testing flag exists for cautiously trialling an enforcing policy, but it is a switch, not a dial. The goal is an evidence-based enforcement plan, not an imagined ramp.

• DMARC pct was removed in RFC 9989: how to stage policy changes in 2026
• How to start DMARC with p=none under the current 2026 specification

sp and np: existing subdomains vs non-existent ones

The current spec makes the subdomain story explicit with two tags. sp sets policy for subdomains that exist in DNS and inherit from the parent. np sets policy for names that do not exist at all, which is the case an attacker exploits by inventing random.example.com to send lookalike mail. When both tags are absent, fallback rules eventually apply the parent p policy.

Model your DNS tree before choosing values. A dedicated sending subdomain can publish its own record; everything else should be covered by the Organizational Domain record so the tree walk finds one policy for every child. Subdomain policy is not a substitute for getting alignment right on the mail you actually send.

• DMARC sp vs np in RFC 9989: existing subdomains and nonexistent subdomains are different

Reporting moved out: ri is historic, size suffixes are gone

Aggregate reporting is now its own document, RFC 9990, and two record habits did not survive the move. The ri tag, which asked for a specific report interval, is historic: receivers decide cadence, typically one file per day, and a monitor that expects hourly XML because a record says ri=3600 will wrongly conclude reporting is broken. The report-URI size suffix, written as something like !10m, has also been removed; a current validator flags it, and report packaging is handled by the spec rather than by the domain owner.

Update ingestion accordingly: drop ri from templates, widen the alert window that flags a receiver as silent, key every record to the begin and end timestamps inside the report rather than to when the file landed, and grep DNS and infrastructure-as-code for any leftover size notation on a rua address.

• DMARC ri is historic in RFC 9989: stop promising a custom aggregate-report interval
• DMARC report URI size limits changed in 2026: the old !10m-style maximum is gone

External reporting still needs an authorization record

If your rua or ruf address is on a different domain from the one being protected — a monitoring service, or a separate reporting subdomain — the destination has to publish a record authorizing it to receive those reports. This has not changed in spirit, but it is still the most common reason reports arrive from some receivers and not others, which makes external reporting look randomly unreliable.

When reports are missing, check the external-destination authorization record in DNS before looking at the mailbox or the parser, expect genuine receiver-to-receiver variation, and protect that authorization record during any later DNS cleanup.

• DMARC rua points to another domain: the external reporting authorization record you may be missing

The DKIM and unsubscribe RFCs that pair with this

Two adjacent standards come up in the same audits. RFC 8301 sets DKIM's cryptographic floor: use rsa-sha256, keep RSA keys at or above 1024 bits, and prefer 2048 where the provider and DNS path allow — and remember that key length lives in the key pair at the signer, not in the DNS TXT string alone. RFC 8058 defines one-click unsubscribe, and its easily missed requirement is that a valid DKIM signature must cover the List-Unsubscribe and List-Unsubscribe-Post headers, not merely that those headers are present in the delivered message.

Both are worth checking whenever you touch DMARC, because a migration that changes signing or gateway behaviour can quietly break either one while the DMARC record itself still looks correct.

• DKIM 1024 vs 2048 bits: what RFC 8301 actually requires before you rotate a selector
• One-click unsubscribe headers must be covered by DKIM: the RFC 8058 detail easy to omit