DMARC p=reject in 2026: What the New RFC 9989 Changes (pct Is Gone)

Short answer: in May 2026 the IETF published RFC 9989, the first DMARC specification on the Internet Standards Track. It replaces RFC 7489, which was only an Informational document, and it changes three things you will notice in a DNS record: the pct tag is removed, a new t (test mode) tag takes over part of its job, and a new np tag lets you set a separate policy for subdomains that do not exist. It also says in plain words that domains used for everyday staff email should not publish p=reject. Your existing record keeps working, but the advice about how to move from p=none to p=reject has changed, and this guide walks through it.

If you are new to the three email authentication records, start with our SPF, DKIM and DMARC setup guide. This post assumes you already have a _dmarc TXT record, or are about to publish one.

What RFC 9989 is, and why it matters now

DMARC lets a domain owner publish a TXT record at _dmarc.yourdomain.com that tells receiving mail servers what to do when a message claims to be from the domain but fails authentication. Until this year the only written definition was RFC 7489 from 2015, an Informational RFC published through the independent stream rather than an IETF working group.

RFC 9989 (J. Levine and T. Herr, editors, May 2026) obsoletes RFC 7489 and RFC 9091. Reporting moved into two companion documents: RFC 9990 for aggregate reports and RFC 9991 for failure reports. The old record format still starts with v=DMARC1, so a record you published years ago is still a valid DMARC record. What changed is the list of tags, how a receiver finds the policy that applies to a domain, and the guidance on enforcement.

What changed in the DMARC record

Tag	Status in RFC 9989	What it means for you
`pct`	Removed (listed as historic)	The percentage rollout is gone. `pct=100` was already the default, so deleting it changes nothing under the old rules.
`t`	New: `t=y` or `t=n` (default `n`)	A test flag. With `t=y` you ask receivers to treat a failing message one level more gently than your policy says.
`np`	New (from RFC 9091)	A policy for non-existent subdomains, for example `np=reject` to stop mail from made-up hostnames.
`psd`	New	Used by public suffix operators such as registries. Ordinary domain owners can ignore it.
`rf` and `ri`	Removed	The requested report format and report interval tags are gone. Delete them if you have them.
`p`, `sp`, `rua`, `ruf`, `adkim`, `aspf`, `fo`	Kept	Your core policy, subdomain policy, report addresses and alignment settings work as before.

One more technical change: the old method of working out which domain is the "organizational domain" used the Public Suffix List. RFC 9989 replaces it with a DNS lookup walk up the name tree. RFC 9989 itself warns that a receiver still running the older logic might reach a different answer. Its suggested way to avoid any surprise is to use strict alignment and publish an explicit DMARC record for every domain you send from.

What the standard now says about p=reject

This is the part most setup guides, including older ones on this site, skip. Section 7.4 of RFC 9989 discusses indirect mail flows: alumni forwarders, role-based aliases and mailing lists. These can break authentication, because a forwarder sends from its own server, so the message fails SPF, and a list may modify the message in ways that break the DKIM signature. The standard draws three conclusions:

Do not rely on SPF alone. A domain that publishes p=reject must apply valid DKIM signatures, because DKIM signatures generally survive plain forwarding while SPF does not. See our DKIM record lookup guide to confirm your selectors resolve.
Everyday-mail domains should stay below reject. A domain whose users send routine email, and might post to Internet mailing lists, should not publish p=reject. A domain that wants reject anyway should first run p=none for at least a month, then p=quarantine for about as long, and compare the results in its aggregate reports.
Receivers should not blindly reject. The text says receivers must not reject mail solely because the sender's policy says reject, and without other analysis should treat such failures like p=quarantine. In other words, p=reject is a request, not a guarantee.

The document is also candid that in practice few receivers apply those mitigations, and that mailing list software has settled on workarounds such as rewriting the From address. If you publish p=reject on a domain people use for normal mail, expect some list traffic to misbehave.

What big domains publish today

I queried the DMARC record of a few well-known domains with dig +short TXT _dmarc.example.com @1.1.1.1 on 5 November 2026. The table shows the policy part only.

Domain	Policy	Notes
google.com	`p=reject`	No `pct` tag
microsoft.com	`p=reject`	Still carries `pct=100` and `fo=1`
paypal.com	`p=reject`	Reports go to third-party monitoring services
github.com	`p=quarantine`	`sp=reject` for subdomains
amazon.com	`p=quarantine`	Still carries `pct=100`
ietf.org	`p=none`	Monitoring only, on the domain that hosts the IETF's mailing lists

Two takeaways. First, nobody has rushed to strip pct=100, which is expected because it is harmless. Second, the picture is mixed: companies that send mostly automated or transactional mail enforce, while a standards body publishes monitoring only. Your choice should follow how your own domain is used, not what is fashionable.

You do not need your own record to be at reject to deliver mail. Google's sender guidelines for bulk senders require a DMARC record, and the page says the enforcement policy can be set to none.

A safe rollout, updated for RFC 9989

Publish monitoring mode. Add a record such as v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com and make sure you can read the aggregate reports. Without rua, receivers are told not to send aggregate reports at all.
List every sender. Reports show every system sending as your domain: your mail provider, newsletter tool, invoicing app, help desk and website forms. Make each one pass SPF or DKIM with the same domain in the visible From address. Watch the SPF limit while you add them, as explained in our SPF PermError guide.
Prefer DKIM for every sender. Section 7.4 makes DKIM the safety net for forwarded mail.
Move to quarantine. Change to p=quarantine and hold for at least as long as you spent in monitoring. If you want a gentler step, add t=y for a first period. Whether a given mailbox provider honours t yet is something its own documentation has to confirm, so check before relying on it.
Decide about reject. If the domain is used only for automated mail, or you have confirmed from reports that nothing legitimate fails, move to p=reject. If staff on the domain write to mailing lists, quarantine may be the better final state.
Close the gaps. Add np=reject so spoofed made-up subdomains are refused, and set sp deliberately if your subdomains send differently.

Example of an end state for an automated-mail-only domain:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

Strict alignment (adkim=s; aspf=s) is optional and suits domains where every sender uses the exact domain; relaxed alignment is the default and is fine for most.

Check your own record

Run dig +short TXT _dmarc.yourdomain.com, or use the DNS lookup tool and select TXT with the name _dmarc.yourdomain.com.
You should see exactly one record that starts with v=DMARC1 as its first tag. Two DMARC records at the same name is an error to fix.
Remove rf and ri if present. Leave pct=100 if you like or delete it; avoid values from 1 to 99 for any plan that depends on them.
Read the rest of the mail picture in our email deliverability and DNS records overview.

Sources

Frequently asked questions

Is my existing DMARC record still valid after RFC 9989?

Yes. Records still begin with v=DMARC1 and the p, sp, rua, ruf, adkim, aspf and fo tags are kept. The pct, rf and ri tags are removed from the standard, so tidy them up when you next edit the record.

What replaces the pct tag?

RFC 9989 adds a t tag. t=y asks receivers to apply a policy one level softer than the one you publish (reject becomes quarantine, quarantine becomes none), and t=n, the default, applies the policy as written. It is a test switch, not a percentage, and you should confirm each mailbox provider supports it before relying on it.

Should every domain move to p=reject?

No. RFC 9989 says domains whose users send routine email and may post to mailing lists should not publish p=reject. It suggests at least a month of p=none followed by about a month of p=quarantine, comparing aggregate reports, before deciding.

What does the np tag do?

It sets the policy for subdomains that do not exist, such as a made-up hostname used by a spammer. np=reject asks receivers to refuse mail from them while your real subdomains follow p or sp.