Five Changes in the New DMARC Standard to Check on Every Client Domain

DMARC got its first real update in more than a decade this year. On May 20, 2026, the IETF published three documents that replace the original 2015 specification: RFC 9989 for the core protocol, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. Together they obsolete RFC 7489, and DMARC is now on the IETF standards track as a Proposed Standard.

Nothing broke overnight. Records still start with v=DMARC1, and existing records keep working. But a few changes touch exactly the things agencies set up for client sending domains, and receivers will adopt the new rules gradually. Here are the five worth checking now.

1. pct is gone, and t replaces it

The old pct tag let a domain apply its policy to a percentage of failing mail, so you could ramp from p=none to p=quarantine in steps. RFC 9989 removes it. The reason given in the RFC is blunt: "the 'pct' tag was usually not accurately applied, unless the value specified was either 0 or 100," and results for other values "varied widely from one implementation to another."

The replacement is a testing flag, t. With t=y, the domain asks receivers to apply the policy one level below the one published. A p=reject record with t=y should be treated as quarantine, and p=quarantine with t=y as none. The default, t=n, applies the policy as written.

What to do on client domains:

• Don't publish new records that depend on pct values like 25 or 50. The new standard says they never worked consistently anyway.
• Don't rip out pct=100 in a panic either. It was the default under the old spec. Some mailbox provider documentation still refers to it, including Google's BIMI setup page, which asks for pct=100.
• Expect a mixed period. DMARCwise, a DMARC monitoring vendor, quotes a Gmail engineer's comment to the working group that both modes "will likely need to be supported for a while." Plan staged rollouts around full policy steps, not percentages.

2. A new np tag covers subdomains that don't exist

Spoofers like made-up subdomains. Mail from billing.clientdomain.com looks plausible even if that host has never existed.

RFC 9989 adds np, a policy for "non-existent subdomains of the given Organizational Domain." If np is absent, receivers fall back to sp, then to p. A client still in monitoring mode on its main domain could publish:

v=DMARC1; p=none; np=reject; rua=mailto:reports@clientdomain.com

That keeps real mail flows under observation while asking receivers to reject mail from subdomains that return no DNS records at all.

One caveat. "Non-existent" here means the DNS answer is NXDOMAIN. DMARCwise points out that not every DNS host returns NXDOMAIN correctly, so test the client's DNS provider before you count on it.

3. The Public Suffix List is replaced by a DNS tree walk

DMARC needs to find a domain's "organizational domain" for two jobs: locating a policy when the sending subdomain has none, and deciding whether a relaxed SPF or DKIM domain counts as aligned. The old spec did this with the Public Suffix List. RFC 9989 replaces it with a DNS tree walk, which queries _dmarc records up the domain tree, capped at eight queries, and adds a psd tag for public suffix operators.

For most client domains, the result will be the same. The risk is in the transition, when some receivers use the old method and some use the new one. The RFC's own advice is simple: the mismatch problem "is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email."

For agencies, that means publishing a DMARC record on every sending domain and subdomain you set up for a client, including secondary cold outreach domains. Don't rely on inheritance from the parent.

4. SPF for DMARC now means the envelope sender only

According to the DMARC.org summary of the new documents, DMARC's SPF check now "only uses the MAIL FROM: address, no fallback to the HELO identifier." Under the old spec, some implementations would evaluate the HELO name when the envelope sender was empty.

That's a small change, and it points the same way the rest of RFC 9989 does: don't lean on SPF alone. The RFC says domains that publish p=reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages." Its list of what domain owners must do to "fully participate in DMARC" includes sending mail that passes aligned SPF and aligned DKIM.

Check on each client domain:

• DKIM is signed with the client's domain (the d= value), not just the sending platform's.
• The DKIM domain aligns with the visible From domain.
• A real test message shows DKIM pass, not just SPF pass.

5. p=reject comes with stronger warnings, and reports are part of the deal

The working group argued for years about whether to discourage p=reject because of mailing lists, which often break both SPF and DKIM when they forward a message. The final text lands in the middle.

For domain owners, RFC 9989 says domains whose users might post to mailing lists "SHOULD NOT" publish p=reject, and anyone moving there should publish p=none "for at least a month," then p=quarantine "for an equally long period of time," and compare results using aggregate reports. For receivers, it says they "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy," and without other evidence should treat such mail as quarantine.

The RFC also makes reporting a core duty. To fully participate, a domain owner "MUST set up a mailbox to receive aggregate reports and collect and analyze those reports." A rua address that nobody reads doesn't meet that bar.

For client work, I'd split this by domain type. A client's main business domain, where staff use mailing lists and vendor tools, should move to enforcement on the RFC's slow path, owned by their IT team. A dedicated outbound domain that only sends cold email from a few known mailboxes has fewer moving parts. Even there, confirm through aggregate reports that every source is aligned before you tighten the policy.

A short checklist per client domain

1. Record exists at _dmarc.<domain> for every sending domain and subdomain.
2. No pct values between 1 and 99.
3. Consider np=reject on the organizational domain once DNS behavior is tested.
4. DKIM is aligned on real test mail, not just SPF.
5. A rua mailbox exists, and someone reviews the reports on a schedule.
6. Any move toward p=reject follows the none, then quarantine, then reject path, with a month at each step.

Where GTM fits

GTM connects each client's own sending domains inside an isolated workspace, with send windows, limits, and a compliance gate that blocks any send without a verdict and an unsubscribe URL. Authentication lives in the client's DNS, so the checks above stay with the client and their IT team. Keeping each client's domains and results separate makes it easier to tell whose record needs fixing.

If you run outbound for several clients and want each client's domains kept apart, join the waitlist.

Sources

• RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)": https://www.rfc-editor.org/rfc/rfc9989.txt
• IETF Datatracker, history for RFC 9989: https://datatracker.ietf.org/doc/rfc9989/history/
• DMARC.org, "IETF Publishes Updated DMARC Specification" (May 2026): https://dmarc.org/2026/05/ietf-publishes-updated-dmarc-specification/
• DMARCwise, "DMARC is now an IETF Proposed Standard: what's new in RFCs 9989-9991": https://dmarcwise.io/blog/new-dmarc-2026
• Google Workspace Admin Help, "Set up BIMI": https://support.google.com/a/answer/10911320