What you need to know about the PCT tag in DMARC records

We’ve been seeing an increase in the number of published DMARC records with a “pct” tag that undermines the value of DMARC altogether.

While the pct tag is well-supported, it is not often used because its application can be somewhat counterintuitive in practice, leading to some unexpected results — like this one.

But first, some background.

What Is the PCT Tag in DMARC?

The pct tag is an optional setting that can be defined on a DMARC record. This tag specifies the percentage of messages from a domain’s mail stream that will be checked to see if they pass authentication.

The pct tag was conceived as a way to allow domain owners to do a “slow rollout” of DMARC enforcement, building their confidence in the setup over time. The intent was to allow domains to shift to a more stringent DMARC policy for a subset of the mailstream, monitor the new configuration for errors and complaints, then increase the size of that subset once they feel confident they’ve identified and addressed all issues.

However, this can still leave your domain open to impersonation attacks until you set pct=100 or remove the pct tag entirely.

Further, there is a stark difference between how the pct tag is defined in the DMARC standard, how most people believe it functions, and how it has been deployed at scale globally.

Because of this gap in understanding and implementation, the use of the pct tag can cause more problems than it solves.

Unfortunately, we’ve been seeing an increase in the number of published DMARC records with a “pct” tag that effectively eliminates any benefit that DMARC might otherwise provide.

One particularly problematic case is when a domain publishes record with pct=0 and p=quarantine.

The Trouble With PCT=0

Domain owners can set the pct to any integer from zero to 100.

Setting it to 100 is the same as having no pct tag at all (because the default, with no pct tag, is to check 100 percent of the messages and apply the stated policy to those that fail authentication).

Setting it to zero is essentially the same as having the next-most-permissive policy.

And this is where the problem comes in. Valimail has seen a growing number of DMARC records in the wild with the following settings:

p=quarantine; pct=0

This combination of tags means that the “quarantine” policy will be applied to zero percent of the domain’s message flow. In other words, this setting is the same as p=none — but with reduced monitoring capabilities (see below)!

Don’t be fooled: A DMARC record with “p=quarantine; pct=0” is not at enforcement. It is potentially a useful stop along the road to enforcement, but keep in mind that it is literally the same as p=none in terms of its ability to stop spoofed messages.

In other words, the same lessons apply as they do with a setting of p=none. A DMARC record with this setting may be useful for gathering data on your email ecosystem via aggregate reports. But you cannot count on it to provide protection, and it is not considered to be at enforcement.

Worse, the inclusion of “quarantine” in your record might offer some illusions of security that doesn’t exist. It may also fool a compliance checklist or simple domain checker tools, creating a false sense of security while leaving your front door wide open.

Use Case For Mailing Lists

There is one use case in which “p=quarantine; pct=0” makes sense — but only after you have spent the requisite time monitoring and understanding your mailflow with a setting of p=none.

Some mailing lists rewrite their From: headers when they see a domain at p=quarantine or p=reject, so that mail from domains at enforcement can be delivered when sent through the list. In mailman, for instance, this is called “from munging.”

(Needless to say, munging headers like this is not an optimal solution to the problem of mailing lists breaking DMARC authentication — and that’s why Valimail is such a strong supporter of the ARC standard, which is a robust solution to this problem.)

Because this munging behavior has no effect on domains with p=none DMARC records, and only kicks in once you move to quarantine or reject, you won’t see its impact until you change policies. Hence, there is a case to be made for using “p=quarantine; pct=0” — so you can monitor the impact of moving to enforcement.

However, this is ultimately misguided. Because the mailing list changes the From: address to be its own, DMARC reports for this mailstream now go to the list, not to you, the domain owner. Once this change is in place, you lose all visibility into this part of your mailflow.

While this will ultimately happen once you move to enforcement, a “p=quarantine; pct=0” setting is absolutely the wrong place to start diagnosing the problem. This issue underscores why it’s so critical to start at p=none, and monitor your mailflow carefully through analysis of DMARC reports that explicitly identify all senders and receivers with accuracy.

What is DMARC Enforcement?

A domain is “at enforcement” if all non-authenticating messages that appear to come from a domain — or its subdomains — will be quarantined or rejected.

The following settings are considered to be at enforcement:

• p=reject [with no pct tag]
• p=reject; pct=[anything]
• p=quarantine [with no pct tag]
• p=quarantine; pct=100

However, if you have a policy of quarantine and a pct set to anything less than 100, then you’re not at enforcement, because some proportion of your message flow effectively has a policy of “none.” If that pct value is pct=0, then 100 percent of your message flow has no policy.

In short: Watch those tags closely. If your DMARC vendor or some consultant advises you to use p=quarantine in combination with anything in the pct tag, ask them why.