DMARC Percentage (PCT) Tag - When, and when not to use it.
What is the DMARC Percentage (PCT) Tag and what does it do?
When IT folks start researching DMARC for the first time, they’ll often encounter a nifty sounding option: Percentage-Based DMARC Enforcement, enabled via the use of a special tag.
This tag, known as the ‘PCT’ tag, is an optional setting for use with DMARC records in the P=Quarantine or P=Reject states (it does nothing while in the P=None state, since nothing is being filtered anyway). The PCT tag defines the percentage of messages from a domain’s outbound mail that will be checked to for enforcement, kind of like spot checking ‘some’ messages to get an idea of if ‘all’ messages are good.
Setting PCT to 0 (zero) means no messages will be checked, while setting PCT to 100 means that all messages will be checked. PCT=50 would mean 50% of all messages get checked, PCT=25 is 25%, and so on.
When no PCT tag is applied, a 100% enforcement policy is in play by default.
Percentage-based enforcement works differently with different mail providers, but the simple rule of thumb is to consider it functioning in a probabilistic sense: a PCT=25 tag means there is a 25% chance of any given email getting enforcement checks and application. So that 25% chance applies to each message that arrives, since it would be very unlikely for all but the largest of mail recipients to quantify the amount of any given domain’s mail being sent to them each day and enforcing selectively on that number.
At this point, one would wonder why anyone would want to only enforce DMARC against some messages, right?
The PCT tag was designed with an eye towards ramping up DMARC enforcement gradually over time, rather than an “all or nothing” deployment that could immediately start blocking legitimate traffic by accident. As IT folks, there is a traditional emphasis to proceed with implementing any new technology cautiously (and with good reason!), so this particular tag is inherently and understandably attractive.
The PCT tag allows for those same IT Administrators to deploy DMARC for a subset of the mail, then monitor the forensic and aggregate reports for any errors or issues. If none were appearing, the PCT tag could be increased further until all email was being DMARC-enforced and all issues sorted out.
With that said, read on to better understand how PCT behaves in practice and why we do not recommend using it.
Understanding how the PCT Tag Impacts Enforcement
As discussed above, using the PCT tag on your DMARC policy limits enforcement of SPF and DKIM protocols to only a subset of your emails. This means only some emails are receiving enforcement and others are not.
This comes back to bite us in two ways: both short term and long term.
From the short term perspective:
Obviously, enforcing less than 100% of your email delivery policies is not ideal. As an example, no one likes other people running red lights, but enforcement of traffic laws is less than 100%, and we’ve all seen those intersection-stopping events at least once as a result and were stuck in the gridlock because of it.
While traffic law enforcement is outside of our control, DMARC enforcement is fully within it. Using graduated PCT tag policies to implement DMARC directly into a P=Quarantine or P=Reject stage can make it feel like we’re getting where we want way faster, but comes with the risk of causing some really unnecessary accidents when our organization’s email gets stuffed into a spam folder or is outright rejected.
It’s kind of like slamming down a brick wall on traffic even when there is a green light. That traffic was intended to go through normally, but because some little misconfiguration was in play on those vehicles, like their headlights being off, they were not allowed through. The worst part is: you won’t know that traffic didn’t go through until you both receive those RUF/RUA reports and make the time to go through them to understand what went wrong and how to fix it. Imagine sitting in that traffic jam overnight (or longer)!
The big takeaway from how the PCT tag gets used often is from the “harm reduction” angle, where an organization needs to implement a DMARC policy, but wants to jump straight to a P=Quarantine or P=Reject policy and is just dealing with the RUF/RUA reports and “patching” problems as they come in.
This is a bad strategy.
Not only are emails your organization is sending out wind up not necessarily being read or arriving to your clients and vendors on time, but using a reactive methodology of fixing the issues means you’re only plugging leaks as they occur.
Instead, the proper way of implementing DMARC is to start with a P=None policy and monitor the RUF/RUA reports over a period of time, rather than escalating a policy up and then intentionally hamstringing its efficacy.
Yes, we know reading those reports is tedious (that’s what we’re here for), but it is infinitely a smarter strategy as being proactive about fixes and never missing a beat rather than missing some potentially important business communications and trying to fix it afterwards (and of course, advising the other internal employee to resend that email again or re-contacting the client via another method; that’s a whole ‘nother headache). The idea of using the PCT tag as a shortcut will invariably only create more work than there otherwise would’ve been.
By using a P=None policy and fixing all potential problems in advance, you’re ensuring that email deliverability is never impacted as the policy gets escalated to a protective one.
From the long term perspective:
Using a PCT policy long term is dangerous from a couple angles:
A slowly escalating DMARC policy that only enforces a subset of emails leaves your domain (and users) vulnerable to impersonation attacks throughout the duration, until it finally reaches a PCT=100 level. Attacks will slip through, both to you and to anyone receiving impersonated emails purporting to be from your domain.
In similar relation, there has been an upsurge in the number of domains we see that have a P=Quarantine policy coupled with a PCT=0 tag. This particular policy is effectively no different than a P=None policy, since zero messages are having that Quarantine enforced upon them. There is no protection associated with this kind of DMARC policy and it has no value. But why would someone even think to try using such a useless policy? Fraud, of course.
We’ve seen this methodology get used to try and work through Cyberinsurer requirements, since many of them require a DMARC policy of at least P=Quarantine or above nowadays (it’s been rising steadily up from most requiring at least P=None). Some insurers will check to see if a PCT tag is present and is being used to try and bypass their requirements of full enforcement; this is something they’ve cottoned on to as an underhanded tactic by potential and/or current clients and they will deny claims when seeing a DMARC record set up this way.
Remember, a domain is only enforcing a DMARC policy if all messages that do not pass SPF, DKIM and DMARC authentication from itself (or its subdomains) will be quarantined or rejected. Anything less than a 100% quarantine or rejection rate is unsafe and shouldn’t be maintained long term.
When is it Safe to use the PCT Tag?
In a nutshell, it’s almost never a good idea to use the PCT tag in a DMARC policy.
In only one very minor exception, for very large organizations with lots and lots of mailing lists (ones they send out to, like large ListServs), it can help find some peculiar mailing list behavior (known as ‘munging’, which is a rewrite of the Mail-From header to enhance deliverability from DMARC-protected domains) while escalating the policy. The problem with munging is that it breaks DMARC authentication by changing the Mail-From header to now point to an entirely different domain.
Munging will only occur for DMARC-protected domains that have escalated their DMARC policies to either P=Quarantine or P=Reject; it does not trigger on a P=None policy.
In such a scenario, once the P=None policy has been in play for awhile and all of the RUF/RUA reports have completed analysis and any sender authorizations finished, escalating the policy up to “P=Quarantine PCT=0” would allow for a gentle start to a Quarantine-grade policy with no defensive effects, but would trigger any mailing lists that munge to begin doing so for mail sent from your domain.
When those mailing lists munge the domain, they’ll begin appearing as if they come from that mailing list’s domain instead of yours. That means that any DMARC reporting for that original email (if enabled) then goes to that mailing list domain’s email administrator and it simply drops off the radar of the original sending domain. When that happens, you lose all visibility into it and will have a much harder time understanding whether it got delivered, rejected, marked as spam or anything else.
Munging was designed as a workaround to keep mailing lists functioning in the age of ever-increasing email security, but it’s really the job of Authenticated Receive Chain (ARC), which is a new email transport standard that allows for intermediate mail servers (like that of mailing lists) to cryptographically sign the original mail’s authentication results and pass that assurance along, like a chain of custody. ARC is still relatively new in terms of adoption and not all mail systems support it, but it’s a critical element to get addressed in terms of mailing list hosts so that DMARC-enabled domains can get their messages out safely and securely.
It’s not necessary, nor advisable, to wait to move to P=Quarantine with a PCT tag to find out if a mailing list that’s in use has munging behavior. With proper RUF/RUA report interpretation while still at a P=None policy, getting mailing lists ARC-signed before escalating the policy up to P=Quarantine is the smart way to go that avoids any trouble altogether.