PowerDMARC

DMARC “t=” Tag replaces “pct” in DMARCbis

DMARC-“t=”-Tag-replaces-“pct”-in-DMARCbis-if-yes-please-send-them

In the ever-evolving email security world, DMARC (Domain-based Message Authentication, Reporting, and Conformance) has been a vital tool for domain owners to protect their email domains from abuse and phishing. 

Over time, this protocol has seen several updates, and one such foreseeable change might be the replacement of the “pct” tag with the “t” tag as reported by IETF in their DMARCbis technical draft.

In this article, we’ll explore the reasons behind this modification and its implications for email security.

Note: No action should be taken in reliance upon this article. The IETF document is still in draft and things may alter in the future.

The “pct” Tag

An earlier version of the DMARC protocol, documented in RFC7489, introduced the “pct” tag. This tag allowed domain owners to specify the percentage of messages subject to a stricter DMARC policy, such as moving from ‘none’ to ‘quarantine’ or ‘quarantine’ to ‘reject.‘ The intention was to provide a gradual transition, allowing domain owners to ease into more stringent email policies.

Challenges with the “pct” Tag

However, operational experience revealed that the “pct” tag presented various challenges. It was often inaccurately applied, except when the value was either “0” or “100” (the default).

The default value, “100,” required no special processing on the part of the Mail Receiver, making it a straightforward choice for many. On the other hand, a “pct” value of “0” became associated with deviations from standard handling, primarily by intermediaries and mailbox providers who rewrote the RFC5322 From header to avoid DMARC failures downstream.

Custom Actions and Valuable Insights

Oddly enough, this unintended use of “pct=0” was valuable to the email community. When intermediaries rewrote headers with “pct=0,” domain owners could gain insights into how much of their email traffic passed through intermediaries that didn’t alter the RFC5322. While this comparison required effort, it was an important source of information for domain owners.

Knowing the extent of mail subject to potential DMARC failure due to the absence of RFC5322 from header rewriting by intermediaries, domain owners could make informed decisions. They could assess their tolerance for DMARC failures and decide whether to transition from “p=none” to “p=quarantine” or “p=reject.”

Introducing the “t” Tag

Recognizing the value of “pct=0” to domain owners, retaining this functionality within the DMARC protocol made sense. However, it no longer made sense to maintain a tag named “pct” with only two valid values. To address this, the latest version of the DMARC protocol may introduce the “t” tag, which stands for “testing.” The “t” tag has two valid values: “y” and “n.”

For more information, you can refer to the official DMARC IETF draft.

The “t” Tag vs. the “pct” Tag

The “t” tag will be designed to be analogous in its application by mailbox providers and intermediaries to the “pct” tag values “0” and “100”, respectively. Here’s how they compare:

  1. “t=y” is equivalent to “pct=0”: Messages marked with “t=y” imply that the domain owner is currently in the testing phase of their policy rollout and the policy is not to be applied by the receiver performing the check. 
  2. “t=n” is equivalent to “pct=100”: Messages marked with “t=n” will adhere to the default DMARC policy, akin to the previous “pct=100” setting.

Read more about the t= tag in DMARC IETF’s official draft.

Implications of the “t” Tag

Overall, introducing the “t” tag may simplify DMARC policy handling. While this may initially seem like a minor change, it also streamlines setting and implementing DMARC policies. The new tag might help ensure that policies are more accurately applied, addressing previous issues.

Conclusion

The information provided is based on a draft document that hasn’t been confirmed or implemented yet. The current version of the DMARC protocol still actively uses and supports the DMARC “pct” tag. The views expressed in this article are ours alone, and no action should be taken based on this without official confirmation from the IETF.

Exit mobile version