DMARC turned into an official IETF standard in May, not just a well-followed industry convention. After a decade running as an informational recommendation, it's now published as three formal specifications, replacing the original 2015 document.
If that's the first you've heard of it, you haven't missed much. This happened months ago, and if you've seen it nicknamed ‘DMARC 2.0,’ I'd treat that label with some scepticism.
What's worth five minutes of your time is understanding what actually moved, what didn't, and why the next chapter, something called DKIM2, matters more than this one.
The headline change is DMARC's status, not its mechanics. It's gone from a good idea most of the industry follows to the same formal tier as TLS, the protocol behind the padlock icon in your browser. That's not just a badge, it means the spec now gets ongoing scrutiny and maintenance as core internet infrastructure, rather than being treated as a well-respected suggestion.
Splitting the spec into three documents is part of that. Reporting has always been the clunkiest part of DMARC but it now has its own document, separate from the core policy rules so it can be improved on its own timeline without every domain owner needing to change how they publish a policy.
Two changes underneath that fix real, specific problems. First, working out which domain actually owns a DMARC policy used to rely partly on a third-party public list of domain suffixes, one that occasionally lagged behind reality. Say a business sends mail from something like newsletter.sales@clientdomain. The old method could misjudge which domain that subdomain actually belonged to and leave it unmonitored, especially for less common structures. The new approach checks DNS directly instead so that judgement call no longer depend on an external list catching up.
Second, and more useful for most clients, businesses can now explicitly lock down subdomains that don't send mail at all. Before this, if a company only ever sent from mail@clientdomain but never touched payroll@clientdomain, an attacker could still spoof second subdomain, because nothing was actively rejecting mail claiming to come from it.
There's now a clean way to say, ‘reject anything from any subdomain we don't use,’ closing a gap a lot of businesses didn't know existed.
Worth repeating to anyone nervous about yet another email standard to deal with - existing DMARC records still work exactly as they did before, nothing needs republishing overnight and nothing breaks because a domain hasn't been touched since 2023.
The core mechanism that tells receiving mail servers what to do with messages that fail authentication, is untouched. If a client is already sitting at a proper enforcement policy, this update changes nothing about their protection today.
Here's the more interesting part. DMARC has always had one well-known weak spot - mailing lists and forwarders.
When a message gets forwarded or passes through a mailing list, it often breaks the checks DMARC relies on. A common result is the recipient's own mail server treating the forwarded message as suspicious and quietly unsubscribing them, as if their address had stopped working when the real problem is how the message travelled, not who sent it.
That's been a known, unresolved problem for the best part of a decade. The new standard describes it more clearly and gives better guidance on managing the risk but it doesn't fix it structurally - that gap is still open.
This is where DKIM2 comes in. Still an early-stage draft and not a finished standard, it's being built to add exactly what's missing: a verifiable trail showing how a message moved between mailboxes and a clearer way to tell ‘this was legitimately forwarded’ from ‘this was replayed by someone pretending it's legitimate.’
That's a genuinely useful answer to the forwarding problem. But it's early days and nobody should be building it into plans this year. It's worth knowing it exists and roughly what it solves, so when it does mature, it isn't a cold start for you or your clients.
None of this changes the job in front of partners today - get domains to a proper enforcement policy and make sure every legitimate sending source is actually authenticated. That's still the whole task, and it's still where most businesses fall short.
It's exactly why we partnered with Sendmarc. Keeping every client's DMARC set-up correctly configured and current as the standard evolves is what they do, so you don't need to be the one tracking RFC numbers.
If you want to know where your clients currently stand, get in touch and I'll help you find out.