10 August 2026 · 7 min read
The short answer: your existing DMARC record is still valid, and for most domains nothing breaks. In May 2026 the IETF published RFC 9989, known through its long drafting as DMARCbis, replacing the original 2015 specification, RFC 7489. The record format, the v=DMARC1 version string, the p= policy levels and the reporting addresses all carry over unchanged. You need to act in two situations: if your record uses the pct= tag, which the new standard removed, or if you want the new tags that make enforcement safer to roll out.
This article covers what changed, what did not, and exactly when a record edit is worth making.
What DMARCbis is
DMARC is now specified across three documents instead of one:
- RFC 9989 defines the record, policy discovery and evaluation
- RFC 9990 defines aggregate (RUA) reporting
- RFC 9991 defines failure (RUF) reporting
The split is organisational; a receiver that implemented RFC 7489 well already does most of what the new documents describe. The substantive changes for domain owners are the removal of pct=, the new t=, np= and psd= tags, and a new way of finding your organisational domain called the DNS Tree Walk.
The change that can alter behaviour today: pct= no longer works
RFC 7489 let you apply your policy to a sampled percentage of failing mail, for example p=quarantine; pct=25. RFC 9989 removes the tag entirely. DMARC parsers ignore tags they do not recognise, so a leftover pct= does not make your record invalid. What it does is stop doing anything.
That creates a mixed world worth understanding precisely:
- A receiver on the new standard ignores
pct=25and appliesp=quarantineto all failing mail. - A receiver still on RFC 7489 continues to sample at 25%.
If you were using pct= as a brake during rollout, the brake has already failed on every receiver that has adopted RFC 9989. Check your DMARC reports for a week or two before assuming the sampled behaviour still protects you. The replacement approach is staged rollout by subdomain (enforce on subdomains that have proven clean in your reports, then the organisational domain) with p=none monitoring wherever you are not yet confident. Our guide to reaching p=reject without breaking email walks that path in detail, and the pct tag explainer covers exactly how legacy receivers still interpret the tag.
Test mode: t=y, with an important catch
The new t= tag (default n) is DMARC's explicit test switch. t=y tells receivers you are publishing a policy but do not want it applied yet; they should evaluate and report as normal but not act on the policy.
The catch: receivers still on RFC 7489 have never heard of t= and will ignore it. Publish p=reject; t=y and a legacy receiver rejects your failing mail today. Until the old standard fades out, t=y is not a safe "off switch". If you need mail to keep flowing while you investigate, p=none remains the state every receiver on either standard understands the same way.
The Tree Walk replaces the Public Suffix List
RFC 7489 receivers used the Public Suffix List, a community-maintained file, to work out your organisational domain (the domain your alignment is judged against). RFC 9989 replaces this with the DNS Tree Walk: the receiver queries _dmarc records up the DNS hierarchy from the message's domain, at most eight queries, and picks the organisational domain from what it finds. A record with psd=n claims the organisational domain directly, a parent with psd=y marks a registry boundary, and otherwise the record with the fewest labels wins.
For a typical company domain like example.com with mail from mail.example.com, the outcome is identical to before and you can ignore this change. It matters if your domains sit under a private registry or a suffix that appears on the Public Suffix List, where the two methods can disagree about where your organisation starts. If that is you, publish a DMARC record at the domain you consider your organisational boundary and add psd=n to it, which removes the ambiguity for Tree Walk receivers.
np=: a policy for subdomains that do not exist
The most useful new tag for most domain owners. Attackers like inventing subdomains (invoices.example.com, secure-login.example.com) precisely because nothing legitimate sends from them. RFC 9989 adds np=, a policy specifically for subdomains that do not exist in DNS. The fallback order is np, then sp, then p.
Because a non-existent subdomain cannot be sending legitimate mail, np=reject is a low-risk hardening step even while your real domains are still at p=none:
v=DMARC1; p=none; np=reject; rua=mailto:reports@example.comTwo cautions. First, "does not exist" is judged by DNS: if you use a wildcard DNS record, every subdomain technically exists and np= will not match. Second, legacy receivers ignore np= and fall back to sp= or p=, so the protection arrives progressively as receivers adopt the new standard. It can only make handling stricter for mail nothing legitimate sends, never looser. If you run subdomains that do send, our guide to the sp subdomain policy covers the existing-subdomain side of the same decision.
What has not changed
- The record lives at
_dmarc.yourdomain.comand startsv=DMARC1 p=,sp=,rua=,ruf=,adkim=,aspf=andfo=all work as before- Relaxed alignment remains the default for both SPF and DKIM
- Aggregate and failure reporting continue exactly as they do today
- External report destinations still require the same authorisation record
Do you need to change your record?
| Your situation | Action |
|---|---|
Record has no pct= and you are at p=none | Nothing to change. Consider adding np=reject once you have checked for wildcard DNS. |
Record contains pct=100 | Remove the tag next time you edit; it is inert. |
Record contains pct= below 100 | Act now. Modern receivers already apply your full policy. Verify in your reports that legitimate mail is passing, then either remove pct= deliberately or step the policy down while you finish fixing senders. |
Considering t=y to pause enforcement | Do not rely on it yet; legacy receivers ignore it and will enforce. Use p=none if you need a universal pause. |
| Domains under a private registry or Public Suffix List entry | Publish a record with psd=n at your organisational boundary. |
As with any DMARC change, move one step at a time and read your aggregate reports before and after: the risk in tightening policy is always to legitimate mail from senders you had not identified.
How DMARC Engine handles RFC 9989
DMARC Engine's record analysis and policy discovery already follow the new standard: organisational domains are resolved with the DNS Tree Walk, and np=, psd= and t= are parsed and reflected in your compliance view, where t=y is treated as a monitoring state rather than enforcement. If your record still carries a pct= tag, the record check will show you what your effective policy now is under current receivers. You can check any domain's record with the free DMARC checker, and if you would rather have the whole journey to enforcement managed for you, that is what the done-for-you DMARC service is for.
Technical statements in this article were checked against the published text of RFC 9989.
Frequently asked questions
Is a record written for RFC 7489 now invalid?
No. The syntax is unchanged and unknown or removed tags are ignored rather than treated as errors. The only tag whose absence of effect can surprise you is pct=.
Do all mail receivers use the Tree Walk now?
No. Adoption is progressive, and large receivers move at different speeds. This is why every new-tag decision above is framed as "what does each generation of receiver do with this record", not just what the new standard says.
Should I add psd= to my record?
Almost certainly not, unless you operate a registry-level domain or your domains sit at an unusual boundary. For an ordinary company domain the default (psd=u, unknown) resolves correctly.