The short version
| Tag | RFC 7489 (2015) | RFC 9989 (2026) | What to do |
|---|---|---|---|
v=DMARC1 | Required | Unchanged | Nothing |
pct | Apply the policy to a percentage of failing mail | Removed | Use t=y for testing; keep pct during the transition only if you rely on it |
t | Did not exist | New: t=y means test mode | Add it while you trial a stricter policy |
np | Did not exist | New: policy for subdomains that don't exist | Add np=reject once you enforce DMARC |
psd | Did not exist | New: marks a public suffix domain | Ignore unless you operate a registry or public suffix |
rf, ri | Report format and interval | Removed | Delete them; they are ignored |
Nothing breaks on day one
The record still starts with v=DMARC1, and p, sp, rua, ruf, adkim and aspf work as before. DMARC still passes when SPF or DKIM passes and aligns with the domain in the From address. Mail providers' sender requirements, such as having at least p=none published, are unaffected. You don't need to rush, but you should update deliberately, because the removed tags now behave differently depending on who reads them.
pct is gone: why it needs care
Under the old standard, pct=25 told receivers to apply your policy to roughly a quarter of failing messages, a common way to roll out quarantine or reject gradually. RFC 9989 removes pct. Receivers that implement the new standard ignore it, so for them a p=quarantine; pct=25 record means full quarantine.
Older receivers still honour pct and know nothing about the new tags. For a while you are writing for two audiences at once. That is why the safest transition is:
- If you have
pct=100or nopct: remove it if present. It changes nothing. - If you use
pctbelow 100 to roll out gradually: addt=yand keeppctfor now. Updated receivers followt, older ones followpct, and both treat the policy as a trial. Removepctonce your reports show the policy is safe at full strength.
t=y: the new test mode
With t=y, receivers that support RFC 9989 apply your policy one level softer: reject is treated as quarantine, and quarantine as none. You still receive reports showing what would have happened at full strength. When the reports look clean, remove t=y.
One important limit: receivers that don't support RFC 9989 ignore t and apply your policy in full. t=y is a safety net at updated receivers only, not a guarantee everywhere. Move from none to quarantine to reject in stages, as before.
np: closing the non-existent subdomain gap
Attackers often spoof made-up subdomains, such as billing.example.com when that name doesn't exist in DNS. Under the old standard those messages fell under your subdomain policy, if you set one. The new np tag sets a policy specifically for subdomains that don't exist. Once you enforce DMARC on your main domain, add np=reject: a name that doesn't exist should never send mail.
How receivers find your policy has changed
When a message comes from a subdomain with no DMARC record of its own, receivers look for the policy of the organizational domain above it. The old standard used the Public Suffix List, a separately maintained list, to work out where that was. RFC 9989 replaces it with a DNS tree walk: receivers step up through the parent names in DNS, a limited number of times, until they find a DMARC record. For most organizations the result is the same policy as before. If you run a complex domain structure with DMARC records at several levels, re-check which record applies to each subdomain.
Reporting moved to its own RFCs
Aggregate reports are now specified in RFC 9990 and failure reports in RFC 9991. Because rf and ri are gone, you can no longer ask for a report format or interval; receivers decide, and most keep sending daily aggregate reports. Keep your rua address and make sure someone, or a report tool, actually reads it.
Update checklist
- Look up your current record: run the Email Security Checker, or query
_dmarc.yourdomainin DNS Lookup. - Delete
rfandri, andpct=100if present. - If you use
pctbelow 100, addt=yand keeppctuntil you are ready for full enforcement. - If your policy is
quarantineorreject, addnp=reject. - Confirm
ruapoints to a mailbox or tool you monitor. - If you use subdomains with their own DMARC records, check which record now applies to each.
- Re-check after publishing, and again once the old record's TTL has passed.
Before and after
A domain mid-way through a gradual rollout:
Before: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; ri=86400
After: v=DMARC1; p=quarantine; pct=25; t=y; np=reject; rua=mailto:dmarc@example.comA domain already enforcing at full strength:
Before: v=DMARC1; p=reject; pct=100; rf=afrf; rua=mailto:dmarc@example.com
After: v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@example.comThe Email Security Checker produces this updated record for your domain automatically, and flags each removed or missing tag.
Frequently asked questions
Do I have to change my DMARC record now?
No. Records that start with v=DMARC1 keep working. Update them to remove obsolete tags and add np, but there is no deadline.
Is pct still supported?
Not in RFC 9989; updated receivers ignore it. Older receivers still read it, so if you rely on pct below 100, keep it alongside t=y during the transition.
What does t=y do?
At receivers that support RFC 9989, it applies your policy one level softer: reject acts as quarantine, and quarantine as none. Older receivers ignore it.
Should I add np=reject?
Yes, once your main policy is quarantine or reject. Subdomains that don't exist in DNS should never send mail.
Does RFC 9989 change the Gmail, Yahoo or Outlook sender requirements?
No. Those requirements, including publishing a DMARC record, are set by the mailbox providers and still apply.