The new DMARC standard, in plain terms for senders

Most of what decides whether your email arrives lives in a few DNS records you set up once and then forget. It is nobody's favorite afternoon. It is also the part of email that changed most quietly this year, and the change is friendlier to small senders than the deliverability news of the last few years.

In May 2026 the IETF published RFC 9989, which describes DMARC and carries the label Internet Standards Track. That sounds procedural until you know what it replaced. The DMARC everyone has published since 2015 was RFC 7489, an Informational document that reached the RFC series through the Independent Submissions Editor rather than an IETF working group. Eleven years of deliverability advice rested on a spec that was, formally, a write up of what some large companies had agreed among themselves to do. The new document obsoletes it and splits reporting into RFC 9990 for aggregate reports and RFC 9991 for failure reports.

What changed in the specification

The largest change is how a receiver finds your policy. RFC 7489 told receivers to work out your organizational domain using a public suffix list, without naming a list or saying how often to refresh it. RFC 9989 replaces that with a DNS tree walk: the receiver looks for a policy record, then walks up the name one label at a time until it finds one, capped at eight queries so a domain with a hundred labels cannot be used to hammer the receiver. The document is candid that the two methods can reach different answers, and it says how to sidestep that. Publish an explicit DMARC record for every domain you send from, and use strict alignment.

The tag list moved too. Three arrived: np for the policy on subdomains that do not exist, psd to flag a public suffix domain, and t to mark a record as testing. Three left: rf, ri, and pct.

The removal of pct is the most interesting, because the reasoning is an unusually honest account of a feature that did not work. The tag let a domain owner apply a stricter policy to a percentage of failing messages and raise that percentage over time. RFC 9989 records that operational experience showed it was usually not applied accurately unless the value was 0 or 100, and that the values in between varied widely between implementations. The useful half survives as the t tag, whose values y and n stand in for the old 0 and 100.

Why this lands now

Mailbox providers move when they decide to, and Microsoft decided in 2025. Since May 5 of that year, Outlook.com has required domains sending more than 5,000 messages a day to outlook.com, hotmail.com and live.com accounts to pass SPF and DKIM and to publish DMARC at a minimum of p=none, aligned with one of the two and preferably both. Mail from high volume senders that misses those requirements goes to the junk folder, and the same page adds that if the problem is left unresolved, messages may be rejected outright with the error 550 5.7.515.

A good deal of writing about this rule says rejection is already universal. Microsoft's own pages are more careful: the junk folder is the documented action today, with rejection announced as coming and no date attached. Two answers in the FAQ on the announcement post matter more than the rest. Adding a sender to the Outlook safe senders list does not bypass the requirement. And if you send through a third party platform, the records still have to live in your own DNS, because authentication is tied to your domain rather than to whoever presses send.

A recipient who wants your mail cannot rescue a domain that fails authentication. Microsoft's answer on the safe senders question is simply no.

The order of operations

RFC 9989 spells out what a domain owner does, in an order that rewards patience: SPF and DKIM on domains that align with your From address, a mailbox set up for aggregate reports, a published policy record, and then a long look at what comes back.

• Start at p=none. The specification calls this monitoring mode: the policy is published and reports are arriving, and you express no preference yet about what should happen to failures.
• Use the reports to find the mail you forgot about. Billing systems, help desks and calendar invitations all send as you, and most domains turn up one nobody remembered.
• Fix the unauthenticated streams before you raise the policy rather than after.
• Give it real time. RFC 9989 says it may take many months of reading aggregate reports before a domain owner is sure all of its mail authenticates.
• Move to quarantine or reject once the reports are boring. Enforcement, in the new document's terms, means any policy other than p=none.

Alignment is where most failures live

DMARC asks for one thing beyond SPF and DKIM passing. The domain that passed has to line up with the domain your reader sees in the From header. Relaxed alignment accepts a shared organizational domain, so a signature from mail.example.com lines up with a From address at example.com, while strict alignment wants the names identical. The failures that puzzle people are usually a platform signing with its own domain, or a bounce address on a subdomain nobody thought to check.

Two traps come with it. An SPF record that pulls in more than ten DNS lookups fails, and include statements stack up fast once several tools send for you. Forwarding also breaks alignment by design, which is what ARC exists to repair.

What you get back for the work

Microsoft runs two free services most senders never sign up for. Smart Network Data Services shows how Outlook.com rates your sending IP space and how many people complained. The Junk Email Reporting Program sends you the full message, headers included, whenever an Outlook.com user marks one of your emails as junk, and Microsoft says enrolled senders usually see that feedback within as little as 72 hours.

None of this is work a tracking tool can do for you, and it would be dishonest to suggest otherwise. Fast Mail Tracker cannot publish a DKIM key or repair an SPF record. What it can do is show whether the mail you send reaches people who respond, separate automated opens from real engagement, and pace a campaign so a burst does not read as bulk. Authentication buys you the chance to be read, and the rest is what you wrote.

The encouraging part of this year's change is that the target is standing still. You can read one standards track document, publish records that match it, and point to a line in it when a platform says something is wrong. Spend an afternoon on DNS, read the reports for a month, and go back to writing better email.