DMARC Receiver Foibles
dmarcian’s Service Director Tomki Camp has worked with email authentication technologies for over two decades and has supported DMARC implementation efforts since 2012. In this article, he talks about inconsistencies in the way some providers give feedback on DMARC, and in some instances, don’t provide any at all.
DMARC data provided by receivers is tremendously useful in helping domain owners understand and address domain authentication issues. However, there is a lot of work and expert-level knowledge required to make sense of variations in “standardized” data sent by providers.
No two providers of similar services are alike, and each mail or web hosting environment has its own idiosyncrasies with pros and cons known by its subscribers. However, the tools provided by these companies are generally not governed by protocols defining their behaviour and presentation, and so there are enormous differences from one to another.
In contrast, the intended use of DMARC is quite well defined, from the perspective of “how to verify whether a given message passes the authentication protocol,” to “what should I do with a message that fails DMARC authentication,” and “how should communication about DMARC authentication statistics be presented to the address specified by the domain owner.”
Unfortunately, there are still a number of implementation details that some providers neglect or get wrong. This article is not a comprehensive review of all known problems, and most end users (domain owners) rarely recognize most of these issues. However, they become apparent when a company such as dmarcian receives hundreds of thousands of individual XML data files each day, representing billions of email messages for tens of thousands of customers. At this scale, problem trends become obvious and even low-volume customer complaints have exposed concerns. This article is to illustrate some of the problems that dmarcian encounters in the journey to assist people in better protecting their domains.
The sole problem with data that this ESP provides is actually not in the format or quality of the data it sends; the problem is that it does not comply with the DMARC specification restriction on who to not send data to. For example, if I publish a DMARC record for tomki.com specifying that reports should be sent to [email protected], we can agree that this is a bad thing, and inappropriate.
The authors of the specification took this issue into account and made it a requirement that DMARC data providers (any entity who sends RUA and/or RUF data) should ascertain a positive allowance for such reports. A DMARC record specifying that reports should be sent to an address within its own domain is a no-brainer—no further checks necessary. If a DMARC record specifies a recipient within a domain *outside* of that domain, then there is a requirement that the DMARC report generator check for a special record at the destination domain—that record must exist to provide the positive allowance.
The problem with Google not performing this check is that there is the potential for it to be a tool in a Denial of Service attack, since there is the potential to flood an email address with reports.
Cisco IronPort ESA
This is a well-known system that has a couple severe issues with its DMARC reports, both from the hosted solution environment (IPHMX) and on the side of hardware installations at client environments.
One issue is that domains and subdomains are not correctly aggregated for reporting. A domain’s DMARC record is inherited by any subdomain that does not have its own explicit DMARC record at its level. This means that XML data detailing email transactions on all subdomains (which do not have their own DMARC record) should be in the same report as for the top level domain. Unfortunately, the Cisco ESA does not do this, resulting in many (potentially thousands) of extra XML files being generated each day.
Another, more complex problem, is in the Cisco Email Security Appliance’s timing of DMARC data generation and the time of data in the reports. The DMARC specification states that daily data generated and sent to record addresses should adhere to a 24-hour window based on a UTC timeframe of midnight to midnight. In other words, from 00:00 to 23:59:59 of that same day in UTC time. This allows reports of email traffic worldwide to be well coordinated by the domain owner. The issue with Cisco ESA is that there is no capability to align DMARC reports to UTC time; all report data is in timeframes relevant to the time set on that particular ESA instance only.
To explain a bit further in an example: A fraudulent campaign abuses an email domain of an international company by sending 500 messages to environments in the United States, 200 to environments in the EU, and another 300 to India. Let’s assume a scenario where these messages were all received at Cisco ESA hosted environments using local time settings, which is normal.
- The 200 messages received in the EU will report most closely on UTC time.
- The 500 messages received in the US will report on times from -5 to -8 UTC.
- The 300 messages received in India will report on time of +5:30 UTC.
The result is that even though the fraudulent email campaign lasted less than 10 minutes, according to reports received from DMARC reporters that do not comply with the UTC timeframe requirement, it appears the campaign spanned about 24 hours, over two separate days. The administrator for the abused domain would be hard pressed to say whether the fraudulent campaign was on one day or the other, or if it actually spanned the entire time period, based on reports received for the domain.
Receivers Sending Incorrect Data
More often than you might think, we see DMARC reports from environments where the data representation is factually wrong or logically incorrect. For example when an SPF result is “fail” but the DMARC-SPF policy result is “pass.” By definition the only way a DMARC-policy result can ever be “pass” is if the SPF result is “pass.”
There are a variety of problems along these lines, from the logic error shown above, to blank or missing sections of required data. With the goal of being able to guide users in their efforts to strengthen authentication, dmarcian works with these reporters to remedy their implementation. In some cases where we can’t get through or a reporting problem cannot be resolved, data imports from a source are halted entirely.
Receivers That Do Not Generate Data
A last class of receiver foible relates not to problems in data or in data generation, but rather in the lack thereof.
DMARC is a public standard (RFC 7489) which literally millions of domain owners have taken advantage of to improve authentication for their domains’ email traffic. In many cases, these same domain owners have taken steps in DMARC to publish policy restrictions against fraudulent use of their domains. These efforts provide tremendous benefits to any environment receiving email purporting to be from that domain; a viable history of email authentication and, even better, a published enforcement policy allows a receiver to much more reliably separate legitimate email traffic from fraudulent.
The work that domain owners put into setting up and correcting email authentication standards (SPF, DKIM, DMARC) being applied to their email traffic is hugely reliant upon DMARC feedback from receiver environments. Known vagaries aside, the feedback from the likes of Google, Yahoo, all of the Cisco ESA environments, Rackspace, Comcast, Mail.ru and others is invaluable in these efforts. The more that receivers participate, the better that email becomes for everyone. However, there are some that take advantage of these authentication standards and provide authentication services for their own environments without contributing to the ecosystem.
The largest examples of this uncooperative behavior are Proofpoint, MIMECast and Symantec.cloud. Each of those environments provide DMARC authentication services for messages sent inbound to their environments, but then do not send DMARC reports to domain owners. Without DMARC reports pertaining to DMARC authentication purporting to be enforced at those environments, a domain owner cannot even be certain that they are performing verification or enforcement actions correctly.
If you are a customer of any of these services, please contact them to ask that they provide DMARC reports for domains which request them.
dmarcian strives to make email safer by expanding the knowledge and awareness of DMARC. If you need assistance with your DMARC project, you can register for a no-strings-attached trial here.
Want to continue the conversation? Head over to the dmarcian Forum.
