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.
1. 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.
2. When no PCT tag is applied, a 100% enforcement policy is in play by default.
3. 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.
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.
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.
Using a PCT policy long term is dangerous from a couple angles:
1. 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.
2.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.
3.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.
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.