The New DMARC Standard Is Here. Most Domains Need to Change Nothing.

In May 2026 the rules behind DMARC were rewritten. We covered what changed when it was published.

Since then you have probably received a few emails about it, and some of them were written to worry you. So here is the version we would give a friend.

Your DMARC record still works. Nothing expired. Nothing broke. There is no deadline. What follows is every change, sorted by whether it actually deserves your attention — including the five that do not.

One thing is worth checking today

If your DMARC record contains pct= followed by anything under 100, read this part. If it does not, skip ahead.

The old pct setting applied your policy to only a slice of your mail. pct=10 meant enforce on one message in ten. It was how careful people eased into DMARC without betting everything at once.

The new standard retires pct completely, and mail providers that have adopted it now ignore the tag outright. So a record reading p=reject; pct=10 is no longer rejecting one message in ten at those providers. It is rejecting all of them.

This is the only item on this page with real-world bite, and it is not a warning about something coming — it is already true. If you were leaning on pct to hold enforcement back, that brake is gone. Go read your record. It takes a minute.

One new setting is worth adding, with two catches

The new np tag sets a policy for subdomains that do not exist. np=reject tells the world: if a message claims to come from a subdomain we never created, throw it away.

That matters because inventing subdomains is a standard phishing move. payroll.yourcompany.com and secure-login.yourcompany.com look official and cost an attacker nothing, precisely because they were never yours to protect.

Two catches, and you will not find them in most write-ups:

It does nothing if you are already strict. If your policy is p=reject, or you publish sp=reject, invented subdomains are already being rejected — they inherit that policy. Adding np=reject changes nothing at all. It only helps if your policy is softer than reject.

It does nothing behind a wildcard DNS record. If your DNS has a * entry, then no subdomain of yours is ever technically "non-existent" — every invented name resolves to something. np never fires. Check for a wildcard before you count on it.

We also need to correct something we wrote in May. We said np was worth considering if you have subdomains. That is backwards. The fewer real subdomains you have, the more of the invented-name problem np covers — because everything an attacker makes up is, by definition, one that does not exist.

And do not start at np=none. We suggested that too, and it was wrong. np=none is not a monitoring mode; it is an instruction to take no action. If your policy is already quarantine or reject, adding it leaves you weaker than before. Either go to np=reject or leave the tag out entirely.

One honest thing to check first: do you send mail from a subdomain that has no DNS records of its own? Some systems send as [email protected] where that name was never actually created in DNS. That is exactly what np=reject blocks. Glance at your reports before you flip it.

One setting could help, but only while you are ramping up

t=y is the replacement for pct. It asks receivers to treat your published policy one step softer than written — a reject behaves like a quarantine.

It is useful if you are moving toward enforcement and want a safety net while you watch your reports. Worth knowing that it is a simple on/off rather than a percentage dial, so you have less fine-grained control than pct gave you. Once you have reached the policy you want, take it out.

Three things to delete eventually, with no rush at all

pct, rf and ri are all retired. If your record still carries them, they are ignored and harmless.

Nobody is going to reject your mail because your record still says rf=afrf. Clean them out the next time you are in your DNS for some other reason. That is genuinely the full extent of the urgency.

The one exception is the pct warning above — if you are mid-rollout, understand what removing it does before you remove it.

Two things to ignore completely

psd is for organizations that operate a domain extension — the registries behind things like .bank. If that is not you, and it is almost certainly not, ignore it.

The "DNS Tree Walk" is a change in how mail providers find your record. It happens entirely on their side of the conversation. You will see it explained at length elsewhere; it asks nothing of you.

The honest summary

The thing that matters far more than any of this

In August we read the published DMARC records of 296 Quebec organizations. 72% do not stop anyone from sending email in their name. Two-thirds of those had done nearly all the work and stopped one setting short.

If that describes your domain, nothing in this article is your problem. A new tag on a record set to p=none is a better lock on a door that is standing open.

Get to p=reject first. Everything above is tidying.

Check your domain

It takes about ten seconds and needs nothing but your domain name. It will tell you which policy you publish, whether your subdomains are covered, and whether anything on this page actually applies to you.

Check your domain now →

If it comes back weaker than you expected, that is not a crisis — it is an afternoon of work. Get in touch if you would like a hand doing it without breaking your legitimate mail, which is the part people are rightly nervous about.