DMARCbis is around the corner: what's changing

The DMARC protocol (Domain-based Message Authentication, Reporting, and Conformance), first published in 2015 as RFC 7489, is about to change.

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 draft specification is internally referred to as DMARCbis, and is expected to be published as a Proposed Standard in 2025. For comparison, the original DMARC specification had instead the Informational status and was an independent submission not led by an Internet standards organization like the IETF.

At the time of writing, most issues in DMARCbis were resolved and a general consensus was (kind of) achieved on the most delicate aspects. The draft is now in the IETF Last Call phase, one of the last stages of the process before publishing.

DMARCbis won’t be a revolution of DMARC, but there are some important changes so it’s a good idea to start getting familiar with them.

What’s changing

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

• A general restructuring of the specification, that is now easier to read, with better examples, more guidelines and clearer definitions.
• 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 DMARCbis 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 practises.

Let’s go through the changes in detail.

General restructuring and improved definitions

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

The specification is also now split in three different documents, which will be 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.

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 DMARC 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 draft, the pct tag is removed for a few reasons. One of them is that for some it was never entirely clear how the percentage was supposed to be calculated (e.g. what’s the “denominator” and how do you estimate it?).

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 the draft document:

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, in the draft the pct tag is 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 greatly discussed within the working group with some notable representatives expressing a negative opinion on this change.

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.

If these changes will be approved, not much will change in practice: there’s only one supported reporting format anyway and aggregate reports will keep being generate daily as a default, which is what the vast majority of domains use.

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

One limitation of DMARC is that it doesn’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 DMARCbis, 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 relies 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.

DMARCbis 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 draft, 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 DMARCbis 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 draft 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 the DMARCbis draft 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 DMARCbis 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 the DMARCbis draft 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 alignments 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 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 recently introduced 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.

In October 2024, work on DKIM2 has started and the new signing mechanism will hopefully include a mechanism to revert changes that break DKIM signatures.

However, none of these technical solutions are currently ready. Given the current state of things, the DMARCbis 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 DMARCbis 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 organisations 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, 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:

  • In policy_published, the fields testing (y or n) and discovery_method (psl, treewalk) were added.
  • The policy override reason can now take the value of policy_test_mode, while forwarded and sampled_out were removed.
  • There’s now a recommended limit of 100 DKIM signatures per “row”.
  • Reporters now “MUST” instead of “SHOULD” use the media types application/gzip or text/xml for the attachment (some reports 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 authentication results, the envelope_from is now optional. There can now be no more than one SPF result. The SPF scope is now optional and it only allows the value of mfrom (helo has been removed).
  • The version field is now optional, although versioning is still being discussed.
  • The report format now allows for extensions.

• Due to the new policy discovery algorithm, the “Feedback Leakage” problem is now mentioned as a security consideration.

Failure reports aren’t changing

The failure reporting mechanism of DMARC should remain unchanged, but the draft now acknowledges that for privacy reasons failure reports are rarely used in practice.

Conclusion

Thanks for reading so far, these were the main changes in DMARCbis, which will be finalized in the coming months.

One final note: DMARCbis 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.

DMARCwise is one of the most user-friendly services that exist out there, and in many cases it’s free. Check it out!