DMARC changes in 2026: what businesses need to know

DMARC was updated in May 2026, replacing the specification that had been in place since 2015.

The Internet Engineering Task Force (IETF) introduced three new Standards Track documents: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting.

Existing DMARC records did not suddenly stop working when those documents were published. There is no blanket migration deadline either.

What has changed is the standard those records now sit under, including: the way DMARC finds the right policy for a domain; some of the tags that can appear in a record; and the guidance around reporting.

For organisations that have had the same setup for several years, especially those that have added new sending platforms or subdomains along the way, that makes a review worthwhile.

A quick reminder: what does DMARC do?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance.

It works with SPF and DKIM and gives domain owners a way to publish a policy in DNS. When a receiving mail system gets a message, DMARC looks at the authentication results and whether the authenticated domains align with the domain the recipient can see in the From address.

A DMARC record can also request reports showing how a domain is being used in email.

Most marketing teams will never need to edit one themselves. They should, however, know who looks after it.

So, what actually changed?

The table gives the short version.

Policy discovery now happens through DNS

One of the more substantial changes is the DNS Tree Walk.

Under the previous approach, DMARC used Public Suffix List information when working out the organisational domain. RFC 9989 now defines a process that looks through the DNS hierarchy itself to find the relevant DMARC record.

A straightforward business domain may behave much as it did before. The detail becomes more useful when an organisation has several levels of subdomains or different parts of the business sending from different places.

RFC 9989 also gives specific guidance for unusually deep domain structures, including situations where organisations may want to publish a DMARC record directly at the author domain rather than relying on policy discovery further up the hierarchy.

Some familiar tags have gone

The previous specification included pct, rf and ri. These are now listed as historic rather than active DMARC tags.

pct is probably the most notable. It was intended to let a domain owner ask for a DMARC policy to apply to only a percentage of messages that failed validation.

In practice, implementation varied. RFC 9989 says operational experience showed that values other than 0 or 100 were often applied inaccurately. The new t tag retains some of the testing behaviour that had become associated with pct=0.

RFC 9989 also includes np and psd.

np allows a separate policy to be set for non-existent subdomains. If it is not used, DMARC still falls back to the relevant sp or p policy, so this is an extra control rather than something every domain suddenly needs to add.

Reporting has been separated out

Aggregate and failure reporting now sit in separate specifications

Aggregate reporting is now covered by RFC 9990. These reports can give domain owners visibility into the mail streams using their domains, including authentication results and the policies being applied.

Failure reporting sits in RFC 9991 and can contain much more detail about individual messages. The specification recognises the privacy implications of that information and gives reporting organisations discretion over what they provide.

That level of detail will usually sit with whoever manages your authentication or reporting service rather than the marketing team.

What has stayed the same?

Anyone who already has DMARC in place will recognise most of the fundamentals.

Records still use v=DMARC1. SPF and DKIM still provide the underlying authentication signals. DMARC still checks alignment with the From domain, and none, quarantine and reject remain the familiar policy choices.

May 2026 is better treated as a reason to review an older configuration than as a deadline that suddenly made every existing setup wrong.

What should technical teams look at?

If your DMARC record still contains pct, rf or ri, those tags are no longer part of the active specification. More complicated domain structures may also justify a closer look at how policy discovery now works and whether np, psd or t has any relevance.

Reporting should be reviewed as well: RFC 9990 and RFC 9991 now define aggregate and failure reporting separately, so organisations using a third-party DMARC monitoring service should make sure that service is working with the current specifications.

Compare the authentication setup with the way the organisation actually sends email now. A configuration that was right when it was created may not reflect a later CRM change, another marketing platform, transactional email sent through a different service or new subdomains.

And what should marketing know?

Marketing teams do not need to manage the DNS record themselves, but they should know who is responsible for it.

If marketing introduces another system that sends email using the company domain, the person managing authentication needs to know about it. The same applies when a team changes sending domains or starts using new subdomains.

Three questions are enough for most marketing teams:

• Who owns DMARC and email authentication internally?
• Which systems are currently authorised to send email using our domains?
• When we introduce a new sending platform or domain, who needs to be involved?

What DMARC does not tell you

A DMARC pass means the message has met DMARC's authentication and alignment requirements.

It does not mean the receiving mail system has decided to put that message in the inbox. RFC 9989 explicitly leaves the eventual handling decision with the receiver, and DMARC results can form only part of that decision.

This distinction is useful when campaign performance is being investigated. A healthy authentication setup is important, but it does not explain every delivery problem on its own.

A message can authenticate correctly and still be addressed to an email that was mistyped at sign-up or is no longer valid. DMARC has no role in checking that recipient address. Email verification does.

Do you need to change anything now?

If your DMARC setup is actively managed, your sending environment has not changed and the people responsible for it are already working to the current specification, a review may simply confirm that everything is in order.

If the record was configured some time ago and largely forgotten, May’s update gives you a useful reason to revisit it.

Check the technical setup with whoever owns email authentication in your organisation.

Recipient data is worth reviewing separately before upcoming campaigns. CORE can check an existing email list, while MORE can validate addresses as they enter forms, registrations and other systems.