DMARCbis: The tag changes and why t doesn't replace pct

Part 2 of the DMARCbis series. Start with the overview.

After the first article the right question promptly came up in the comments: Can you actually use the new DMARC tags already, or does the other side have to switch over first?

Short answer: Yes, you can set them immediately, there's no harm in it. For most records, the transition is pure maintenance. Things look different for organizations that are working step-by-step towards full enforcement using pct. For them, more than just a tag name is changing. One thing at a time.

What changes in the record

DMARCbis (published as RFC 9989) removes three tags and brings three into the core protocol.

Out: pct, rf, ri. All three are now marked as historic in the tag registry. For rf (format of failure reports), this was long overdue: there was only one registered value anyway (afrf), and since unset tags assume their default value, the tag was always redundant. ri (report interval) was simply not evaluated by receivers in practice. You can safely remove both from your record.

In: np, psd, t. The np tag is not entirely new. The tag originally comes from the PSD-DMARC extension (RFC 9091) and has now been adopted into the core standard. We will look at what it does and why it can be useful in a moment. The psd tag marks Public Suffix Domains and plays a role in the new resolution logic. For normal domain owners, it is usually not relevant. More on this in the next post about the DNS Tree Walk.

The third tag is the actual reason for this post: t.

np and sp: subdomains, cleanly separated

A quick digression on np, because it is the most practically useful addition.

Previously, there was exactly one lever for subdomains: sp. It applied to all subdomains without their own DMARC record, regardless of whether the subdomain exists or not. An email from a completely made-up subdomain (invoice.yourdomain.com, which does not exist in your DNS at all) was treated like an email from a real one. Anyone who wanted to hard-block spoofing via made-up subdomains had to set sp=reject, which also hit all real subdomains without their own record.

np now separates this: sp still applies to existing subdomains, np takes effect for non-existing ones. Non-existing here means: the DNS responds to the query with NXDOMAIN, the name has no records at all. This means np=reject works with a relaxed sp, and made-up subdomains are locked down without real subdomains suffering. If np is missing, sp applies as before, and if that is also missing, p.

A note for practice: np has a pitfall with DNSSEC-signed domains. For technical reasons, some large DNS providers do not answer queries for non-existent names with NXDOMAIN there, and then np may not take effect as expected. The details depend on DNS resolution and therefore fit better into the next post on the DNS Tree Walk.

The switch from pct to t

pct was once intended to enable a phased rollout. The idea: apply the policy to only a portion of emails first, such as p=reject; pct=20, and gradually turn it up. The problem was already in the definition. pct was formulated as the "percentage of messages to which the policy is applied", and that allowed for two interpretations. Example: p=quarantine; pct=10, 100 messages arrive, 50 of which fail. Do you now quarantine 5 (10 percent of the failures) or 10 (10 percent of all messages)? Different receivers chose different answers. In the end, only the extreme values 0 and 100 worked reliably. For this very reason, pct was classified as historic in DMARCbis and removed from the core protocol.

The supposed successor to pct is t. But accuracy is worthwhile here: t is not a replacement for pct, but pursues a different approach. pct staggered the scope: full policy, but only on a portion of the emails. t staggers the severity: all emails, but one level below the published policy. These are two different axes. From pct, t only adopts the part that worked reliably in practice: the distinction between full enforcement and pure test mode, previously pct=100 versus pct=0, now as a clean yes/no flag (t=n/t=y).

Specifically, the RFC defines t=y as an instruction to apply the policy one level below the published one:

• p=quarantine; t=y means: failing emails are treated as with none. So effectively no enforcement.

• p=reject; t=y means: failing emails are quarantined, not rejected.

The most common misconception: reading t=y as "test mode, so nothing happens". With p=reject, t=y does not turn off, it lowers one level. Failing mail still ends up in quarantine. On a policy that is already none, however, t has no effect at all. This applies, by the way, to all three policy levels: t behaves in the same way on sp and np, provided their value is not none. Default is t=n, i.e., full application of the policy.

If you are phasing in enforcement with pct today

Now to the group for whom something really changes. Anyone who has never used pct to phase in enforcement can read this section as background knowledge.

As long as receivers are in transition, some will still evaluate your record according to the old spec (RFC 7489), others already according to RFC 9989. I will refer to them below as 7489 receivers and 9989 receivers. For most records, the difference does not matter. For a record that phases in enforcement, it does.

Let's take p=reject; pct=20. If you now remove pct without replacement, the two receiver worlds drift apart:

• A 7489 receiver no longer finds pct in the record and falls back to the default value of 100. "Reject on 20 percent" becomes "reject on 100 percent". The hard jump that you wanted to avoid with the phase-in.

• A 9989 receiver ignores pct anyway and would apply the full policy without further specification.

Not a broken record in the syntax sense, but a real effect on your mail flow, and in the unpleasant direction. How long this phase lasts, in which both receiver worlds exist in parallel, cannot be seriously quantified today. Realistically, one must assume several years; receiver transitions of this kind do not happen in quarters.

The transition path, and why it is controversial

There is a pragmatic transition path: set both tags together for a while, p=reject; pct=20; t=y. Then each receiver reads what it understands.

• The 7489 receiver uses pct=20, ignores the t unknown to it, and does reject on 20 percent.

• The 9989 receiver ignores pct, reads t=y, and does quarantine on 100 percent (reject minus one level).

The result: no receiver jumps to hard reject. 7489 receivers stay with reject on a portion, 9989 receivers end up with full quarantine. Both below the hard edge, and quarantine does not reject any mail, it only sorts it out.

Important to note: This is a transition path with an expiration date, not a permanent solution. It only works as long as there are 7489 receivers. The moment the last receiver has switched to RFC 9989, pct is finally ineffective, and only t still has any effect in the record. Anyone who sets the double-tag record should make a note of a date to clean up, otherwise they will carry a dead tag around for years.

To be honest: this path is not uncontroversial among practitioners. The opposing position says that pct should be removed immediately because a record that behaves differently with different receivers creates more confusion than benefit. Both sides have an argument. If you want to make a clean cut, go directly to t=y and manage the rollout operationally, i.e., by cleanly authenticating your senders one after the other, instead of relying on a dead tag.

The actual point

pct was the only mechanism in the DMARC protocol with which an enforcement rollout could be controlled in stages. Exactly this capability is lost with DMARCbis. t does not replace pct: it is a test switch, not a ramp. The protocol can no longer phase in scope. The question of "how do I safely get from monitoring to enforcement" thus finally moves from configuration to operations. This is likely to be the most important practical change of DMARCbis. Not a new tag, but the loss of the only built-in rollout mechanics.

What you can do specifically

• Are you running pct=100 or do you have no pct at all? Then simply remove pct, otherwise nothing changes.

• Do you use pct with an intermediate value for testing? Then consciously switch over: either a clean cut to t=y with an operational phase-in (first align every legitimate sender cleanly in SPF and DKIM, then tighten the policy), or run the transition path with both tags, being aware of the different effects and with a fixed date to clean up.

• Remove rf and ri at the same time.

Specifically, this is what it looks like on a record that phases in enforcement.

Before (old, RFC 7489):

v=DMARC1; p=reject; pct=20; rua=mailto:dmarc@cloudpandas.com; rf=afrf; ri=86400

After, clean cut:

v=DMARC1; p=reject; t=y; rua=mailto:dmarc@cloudpandas.com

Attention, this is a test state, not a final state: on failing mail, this record behaves like p=quarantine, but continues to signal the target reject. The target state is the same record without t=y.

After, transition path with both tags:

v=DMARC1; p=reject; pct=20; t=y; rua=mailto:dmarc@cloudpandas.com

rf and ri are out in both cases because they no longer do anything. The only difference is whether pct remains for a while for the 7489 receivers.

Whether your record is still sitting on pct and how DMARCbis-fit it is, you can check directly in our tool: mailaudit.

In the next part, we will cover the second major change: DMARCbis throws out the Public Suffix List and replaces it with the DNS Tree Walk. Then it will become clear what the psd tag is really there for, and why np does not always take effect with DNSSEC-signed domains.

DMARCbis series

1. Overview

2. Tag Changes] (this post)

3. DNS Tree Walk

4. p=reject / Full Participation (coming)

5. NIS2 (coming)