DMARC is now an IETF Proposed Standard: what's new in RFCs 9989–9991

The DMARC protocol (Domain-based Message Authentication, Reporting, and Conformance) was updated in May 2026 and is now an IETF Proposed Standard. It is published as RFC 9989, RFC 9990, RFC 9991, replacing the Informational RFC 7489 from 2015.

While the new DMARC isn’t a revolution, it contains some important changes. This article aims to be a comprehensive list of the most relevant changes in the new RFCs.

Introduction

DMARC is an email security protocol that helps protect your domain from being impersonated by scammers and phishers, an attack known as spoofing.

DMARC builds upon two other foundational protocols of email, SPF and DKIM. It’s a common misconception that SPF and DKIM alone are enough to protect from spoofing, but in practice that’s not the case.

The protocol mainly does three things:

• It provides an algorithm to verify alignment of authentication mechanisms, such as SPF and DKIM. Checking alignment means making sure that the sender of an email matches what’s declared by SPF and DKIM.
• It defines a DNS record format that lets domain owners specify how their emails should be handled when alignment fails, and tune other parameters.
• It defines a reporting mechanism that lets domain owners gain visibility into their email flows, investigate authentication and alignment failures, and adjust their SPF, DKIM and DMARC settings accordingly.

In the past few years, the DMARC Working Group led by the IETF (the Internet Engineering Task Force) worked on a new updated specification with the aim of addressing some of the limitations of the original protocol. In the process, lessons learned during the first decade of DMARC deployment were also incorporated.

The new specification was internally referred to as DMARCbis and is now officially published as a Proposed Standard, as of 20 May 2026. For comparison, the original DMARC specification, first published in 2015 as RFC 7489, had Informational status and was an independent submission not led by an Internet standards organization like the IETF.

The new DMARC took many years to finalize (roughly from 2018 to 2025), and a general consensus was finally achieved on all matters. The result is three new documents:

• RFC 9989: main document.
• RFC 9990: aggregate reporting.
• RFC 9991: failure reporting.

What’s changing

Broadly speaking, these are the changes in the new RFCs compared to RFC 7489:

• A general restructuring of the specification, that is now easier to read, with better examples, more guidelines and clearer definitions.
• A new section specifies the “conformance requirements for full DMARC participation”, helping domain owners and email receivers determine if they’re following the best practices around DMARC.
• In the DMARC policy record, some tags were removed (pct, rf, ri) and some were added (np, psd, t). Note that this is not considered a breaking change so there is no such thing as DMARC2: DMARC records will continue to start with the v=DMARC1 string.
• In the context of determining the Organizational Domain, both for DMARC record discovery and identifier alignment, the Public Suffix List mechanism has been replaced with the more flexible (and complex) DNS Tree Walk algorithm.
• The above changes allow for better support of Public Suffix Domains (PSD), which previously couldn’t fully participate in DMARC.
• The ”indirect email flows” issue, i.e. forwarding and mailing lists breaking DMARC alignment, remains unsolved, with RFC 9989 now discouraging a reject policy when there’s a chance of mailing lists being used as recipients in an organization.
• Aggregate reporting has been made stricter and the XML report format has been updated to incorporate the new record tags and acknowledge real-world practices.
• Similar small changes were made to failure reporting, including a new section acknowledging the privacy implication.

Let’s go through the changes in detail.

General restructuring and improved definitions

The updated DMARC specification is based on the original RFC 7489 but has been restructured and is now easier to read, with improved examples and more practical guidance.

As mentioned, it’s now split into three different documents, published as three different RFCs. These are the main document, the aggregate reporting specification, and the failure reporting specification.

Several definitions have been updated or added. For example:

• The DMARC policy is now formally called Domain Owner Assessment Policy.
• When the DMARC policy is none, the state is called Monitoring Mode, while in other cases it’s called Enforcement.
• The “report receiver” is now called Report Consumer.

Requirements for full DMARC participation

A new section makes it clear what it means to fully participate in DMARC.

In particular, domain owners:

• Must send SPF-aligned and DKIM-aligned email messages.
• Must collect and analyze DMARC aggregate reports.
• Must publish a DMARC record for all the domains they send emails from, and also for the parent organizational domain if it’s different.
• Must not rely solely on SPF for a DMARC pass if the DMARC policy for a domain is p=reject.

On the other hand, email receivers:

• Must verify if a DMARC record is present to know if DMARC applies to the message, and then conduct the necessary alignment checks to produce a pass or fail result.
• Must support delivery of reports with the mailto: URI (i.e. sending reports as email messages).
• Should send aggregate reports at least daily.
• Must not reject messages solely on the basis of a p=reject policy (more on this below).

np: policy for non-existent subdomains

The new DMARC record tag np allows domain owners to define a policy to apply when an email fails DMARC alignment checks and the subdomain does not exist.

Here’s an example of how this tag could be used:

v=DMARC1; p=none; np=reject;

If the np tag is missing, the sp or p policies are used for subdomains, in this order.

The definition of a non-existent domain is as follows:

For DMARC purposes, a non-existent domain is consistent with the term’s meaning as described in [RFC8020]. That is, if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist.

It should be noted that not all authoritative name servers correctly return the NXDOMAIN status code when a subdomain doesn’t exist (i.e. it has no DNS records at all), so it remains to be seen what impact this will have in practice.

pct removed in favor of t (testing mode)

A feature of the original DMARC protocol is message sampling, which tells destination email servers to apply the DMARC policy only on a subset of the email messages based on the percentage specified with the pct tag.

In the updated specification, the pct tag was removed for a few reasons. One of them is that implementers reportedly disagreed on how the percentage should be calculated and applied.

A consequence was that in real-world usage the pct tag has been effectively used as a yes/no variable, and so in almost all cases with a value of pct=0 or pct=100, with no gradualness.

From RFC 9989:

Operational experience showed that the pct tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

For this reason, the pct tag was replaced with t, which can take two values:

• y to say that the DMARC policy should not be applied (testing mode), equivalent to pct=0.
• n otherwise, equivalent to pct=100 (default).

This change was extensively discussed within the working group with some notable representatives expressing a negative opinion on this change.

For example, here’s what Wei Chuang from the Gmail team had to say:

We question the benefit versus the implementation effort and confusion of deprecating the DMARC policy “pct” percentage mode and replacing it with “t” test.

We do agree that there is benefit in having receivers support a debug mode to enable DMARC deployment and that the test mode supports the most useful use case for testing with indirect mailflow behavior.

However “pct” represents a sunk cost and implementing test mode seems redundant to the already existing “pct” percentage mode. Moreover both modes will likely need to be supported for a while. We do see senders use “pct” ratcheting and it will be confusing to them when at some point they will have to switch.

As Chuang says, given that pct is already cemented in thousands of resources and implementations of DMARC, it’s unlikely it will go away soon, and there’s a risk of creating confusion around whether pct or t should be used to maximize compatibility.

Time will tell if this concern was justified.

rf (report format) and ri (report interval) tags are going away

These two tags are being removed. Here’s what they mean according to RFC 7489:

• rf determines the format to be used to generate failure reports. The only supported format is afrf.
• ri is the interval in seconds that reporting mail servers should consider when generating reports.

In practice, not much will change: there’s only one supported reporting format anyway and aggregate reports will keep being generated daily by default, which is what the vast majority of domains use.

psd (Public Suffix Domain) for better control of the discovery algorithm

One limitation of the original DMARC protocol was that it didn’t allow Public Suffix Domains (PSD) owners to fully benefit from DMARC (unless you consider experimental extensions).

For example, the gov.uk domain is not only the UK Government domain but also effectively a Top Level Domain (TLD), as subdomains can be registered upon request, and is therefore usually included in public suffix lists. This prevents the DMARC policy from being applied to subdomains, since a PSL domain cannot be an Organizational Domain.

In the new RFC 9989, the algorithm to determine the Organizational Domain has been changed (see below) and now partly relies on the new psd tag.

The psd tag can have one of the following values:

• y, indicating that the domain is a Public Suffix Domain and subdomains should therefore be considered Organizational Domains.
• n, indicating that the domain is not a Public Suffix Domain but is the Organizational Domain for itself and its subdomains.
• u, the default. In this case the Organizational Domain is determined by the results of the DNS Tree Walk.

DNS Tree Walk replaces the Public Suffix List

An important part of DMARC is determining the Organizational Domain. The Organizational Domain is used for two purposes:

• Discovering the DMARC policy record when the From domain doesn’t have a DMARC record.
• Determining whether SPF or DKIM domains are aligned in relaxed mode.

RFC 7489 relied on public suffix lists to determine the organizational domain, with the idea of finding an approximation of the highest registrable domain in the hierarchy. This mechanism was deemed unreliable (public suffix lists are community projects and updated on a volunteer basis) and has the limitations mentioned in the previous section.

The new RFC 9989 introduces a new mechanism based on DNS Tree Walk, an algorithm that loops through parent domains until it finds DMARC records. To limit the number of DNS queries, there’s a limit of 8 queries and some domains may be skipped in the process.

Here’s an example, taken from the RFC, with the list of queries that the tree walk may execute when given the domain name a.b.c.d.e.f.g.h.i.j.mail.example.com:

_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
_dmarc.g.h.i.j.mail.example.com
_dmarc.h.i.j.mail.example.com
_dmarc.i.j.mail.example.com
_dmarc.j.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

(Notice how domains between a and f are skipped.)

To discover the DMARC policy record for a domain, the RFC 9989 algorithm first queries the input domain, and if it doesn’t find a valid DMARC record it starts querying parent domains to determine the Organizational Domain.

The Organizational Domain is determined as follows (slightly simplified):

• If a DMARC record with psd=n is found, this is the Organizational Domain, as specified by the domain owner, and the process stops.
• If a DMARC record with psd=y is found, the domain is a Public Suffix Domain and therefore the Organizational Domain is the domain one level below.
• Otherwise, the shortest domain where a DMARC record was found is selected.

The new mechanism is clearly more complex (it may take a few reads of the specification to fully grasp it), but it’s also much more flexible, as it allows organizations with complex DNS setups to decentralize their DMARC policy management more easily, thanks to the psd tag.

In most cases, though, adding the new psd tag to the DMARC record shouldn’t be necessary. Read this part of the specification for some examples on how the new mechanism works.

When relaxed alignment is requested and domains aren’t all the same domain, the same algorithm is applied to determine the Organizational Domain for each domain involved in the alignment checks.

You might have noticed that this new algorithm may lead to different results depending on whether a DMARC implementation uses the DNS Tree Walk algorithm or the old Public Suffix List-based mechanism. It’s a valid concern; here’s what RFC 9989 has to say about it:

This issue is entirely avoided by the use of Strict Alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization’s email.

This may not be applicable to all situations, but it’s a good recommendation.

The unsolved issue of forwarding and mailing lists: should you avoid p=reject?

One of the objectives of the DMARC working group was to find solutions to the indirect email flows problem, which in practice means email forwarding.

The problem is that when an email message is forwarded by an email server, SPF and DKIM checks often fail:

• SPF fails when a message is forwarded if the SPF policy doesn’t allow the forwarder. Even if the sender is rewritten with the Sender Rewrite Scheme (SRS) to fix this problem, DMARC is then going to fail since the domains won’t match anymore (learn more here).
• DKIM can also fail in the context of mailing lists, which take a message and distribute it to multiple recipients, usually by adding a footer or changing the subject.

If the forwarder doesn’t modify the message contents, the DKIM signature will likely survive and so DMARC will pass. For this reason, RFC 9989 says that:

It is therefore critical that domains that publish “p=reject” MUST NOT rely solely on SPF to secure a DMARC pass, and MUST apply valid DKIM signatures to their messages.

Unfortunately, when mailing lists are involved usually both SPF and DKIM alignment fail. As a consequence, an email sent from a domain with a DMARC policy of reject may be rejected, causing issues to other members of the mailing list too:

A Policy of p=“reject” […] can cause the Mail Receiver’s users to have their subscriptions to that mailing list canceled by the list software’s automated handling of such rejections - it looks to the list manager as though the recipient’s email address is no longer working, so the address is automatically unsubscribed.

This interoperability issue (explained in detail in RFC 7960) was supposed to be solved with technical measures, but in the first decade of DMARC deployment no satisfying solution was found.

ARC (Authenticated Received Chain) was introduced in 2019 as an experimental mechanism aimed at “freezing” the authentication results before forwarding, but it has the limitation that receiving mail servers must determine whether to trust the forwarder. Discussions are underway to determine whether the ARC experiment should be terminated.

A technical solution to the forwarding problem is likely to come from DKIM2, the successor of DKIM (DomainKeys Identified Mail), which will include a mechanism based on “recipes” to revert changes that usually break DKIM signatures. The work on DKIM2 started in October 2024 and is progressing quickly, but it will likely take a few more years to complete.

Although a path to a technical solution exists, none of these solutions are currently ready. Given this state of things, the DMARC working group discussed at length whether the use of a DMARC policy of reject should be discouraged.

Some participants strongly supported the proposal to strictly forbid (“MUST NOT”) the use of p=reject when a domain is used for “general-purpose email” (i.e. including mailing lists) and not only for transactional emails.

For some, not breaking mailing lists is an essential goal, even more important than preventing email spoofing and phishing attacks effectively:

Keep in mind that improper deployment of DMARC results in damage to innocent third parties: It’s not the sender or the MLM that’s impacted, it’s everyone else on the list. It’s breathtaking to me that we can feel comfortable shrugging this off under the banner of “security” or “brand protection”. (Murray S. Kucherawy)

On the other hand:

All the major free mail providers are moving to have DMARC policies on their domains. Yahoo has it, 1und1 has it, Gmail has committed to do it. That’s 2.5bn+ inboxes protected by DMARC. Why would we have text says MUST or SHOULD NOT against a practice that’s protecting inboxes worldwide and is picking up steam across them all due to the very real security benefit of the document this guidance is in…? (Seth Blank)

In the end, a consensus was reached and RFC 9989 now explains in detail what are the interoperability risks of having a reject policy when mailing lists are involved, suggesting the use of DMARC reports to monitor if mailing lists are being used by an organization:

It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of “p=reject”.

Any such domains wishing to publish “p=reject” SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing “p=none” for at least a month, followed by publishing “p=quarantine” for an equally long period of time, and comparing the message disposition results.

Domains that choose to publish “p=reject” SHOULD either implement policies that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered.

Still, this didn’t leave everyone satisfied: Wei Chuang from the Gmail team pointed out that the recommendation of preventing people from using mailing lists is «impossible to implement».

Since most organizations are going to use p=reject anyway, a provision for receiving mail servers was added, so that an email isn’t rejected and only quarantined if it cannot be determined whether that message was forwarded or is coming from a mailing list:

It is therefore critical that Mail Receivers MUST NOT reject incoming messages solely on the basis of a “p=reject” policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis. “Other knowledge and analysis” here might refer to observed sending patterns for properly-authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were “p=quarantine” rather than “p=reject”.

Changes in aggregate reporting

Several small things were changed in DMARC aggregate reporting, which is now specified in its own document with much more detail and improved formatting, but the overall mechanism is unchanged and the reporting format is also essentially backwards compatible.

• The rua tag can contain multiple URIs, but the part of RFC 7489 that says that receivers MUST support the ability to send to at least two of them was removed.
• Since the ri tag was removed, aggregate reports are now sent «daily or more frequently» and the interval cannot be overridden.
• The option in the rua tag to specify a size limit for reports was removed.
• The XML schema for aggregate reports was updated:
  • Reporters now “MUST” instead of “SHOULD” use the media types application/gzip or text/xml for the attachment (some reporters still use pre-RFC implementations).
  • Reporters now “MUST” construct the attachment file name and the email subject with the specified formats.
  • The validation mechanism for destinations external to the From domain is now mandatory (some providers have never implemented the validation).
  • In report_metadata, a new optional generator field allows reporters to specify the software that generated the aggregate report. The error field is now limited to one occurrence.
  • In policy_published, the fields testing (y or n), discovery_method (psl, treewalk), and np were added (optional). The sp field is now also optional.
  • The policy override reason can now take the value of policy_test_mode, while forwarded and sampled_out were removed.
  • In policy_evaluated, pass is now a valid value for the disposition.
  • In authentication results, the envelope_from is now optional.
  • The SPF result is now also optional and there can be at most one. The SPF scope is now also optional and it only allows the value of mfrom (helo has been removed). The SPF result can now have the value of policy, as per RFC 8601. A new human_result was introduced, reflecting the existing similar field for DKIM signatures.
  • The human_results now have an optional lang attribute which defaults to EN (English).
  • There’s now a recommended limit of 100 DKIM signatures per “row”. The selector field for a DKIM signature is now mandatory.
  • The version field is now optional.
  • The report format now allows for extensions.
  • The XML root element now declares the attributes targetNamespace and xmlns.
• Due to the new policy discovery algorithm, the “Feedback Leakage” problem is now mentioned as a security consideration.
• Reports not adhering to the schema should now be discarded by report receivers, which may however still try to extract some of the data.

Failure reports aren’t changing

The failure reporting mechanism of DMARC remains largely unchanged, except for the following minor changes:

• The option in the ruf tag to specify a size limit for reports was removed.
• Since the rf tag in the DMARC record was removed, the failure report format is now always afrf.

More importantly, the specification now acknowledges that for privacy reasons failure reports are rarely used in practice, and details what the privacy concerns are.

Conclusion

We’ve gone through the changes introduced in the new DMARC specification, which is now a Proposed Standard and will be adopted gradually by mail servers and domain owners in the coming months and years.

At DMARCwise, we help you gain visibility over your email security compliance, and we’ve already started the work to fully support the new DMARC specification. You can track our work on this page.

As a final note, the new RFC 9989 now explicitly recognizes the role of third-party DMARC monitoring services:

While it is possible for a human to read aggregate reports, they are formatted in such a way that it is recommended that they be machine-parsed, so setting up a mailbox involves more than just the physical creation of that mailbox.

Many third-party services exist that will process DMARC aggregate reports or the Domain Owner can create its own set of tools.

If you’re looking for a hosted solution to help you monitor your email compliance, give us a try.