Pains of DMARC adoption

Looking back 3 years there were few domains with DMARC records. The number of admins aware of the DMARC standard was even lower and DMARC was the domain of deliverability professionals. Back then the admins were curious about the new record. When we asked them to add the record to their domains they were eager to learn about its effect. The situation has improved but some of the obstacles are even more difficult.

As most sys-admins are aware of and have read about DMARC they have started implementing the standard on their own. In many cases without an understanding of its meaning or impact. As a result, we as deliverability professionals are facing an uphill battle - useless DMARC records. Created by admins who believe they have done everything that there was to be done. Let’s take a look at the most common issues slowing down DMARC adoption.

Useless records

Without any doubt, the invalid records are the most common case of records we are facing when onboarding clients. Their IT departments have set up a record that they believed to be the one that they need to claim “we have DMARC”:

_dmarc IN TXT “v=DMARC1; p=none;”

The amount of these record keeps growing along with the number of sys-admins learning about DMARC. It’s a reminder of the SPF times when many domains had records that had a major negative impact on deliverability and prompted the creation of DMARC itself. So what is it that is so wrong with such a record, you ask? Well first and last of all it has no point - there is no use in having such a record as it is no different than not having any. It’s a record that matches the default of not having a record.

The key feature of DMARC is its reporting which provides insight into the receiving server’s “mind”. There are two types of reports - aggregate reports (RUA) and forensic reports (RUF). The aggregate reports provide anonymous information from the receiving server about the result of the authentication of messages originating from the DMARC enabled domain. These are the key to proper deployment of both SPF and DKIM. The record above has no RUA reporting address and as such will not help the domain owner to achieve the goals of authentication.

Very few receivers provide the forensic reports. Those include detailed reports about individual messages and often contain personal information of both the sender and recipient. As you may have just realized this could easily put any receiver of forensic reports at odds with GDPR and as such their use is discouraged. Simply put - forget about RUF!

Too strict records

Many admins take the opposite route to DMARC deployment and set the record the way they did their SPF.

_dmarc IN TXT “v=DMARC1; p=reject;”

Rejecting all email using p=reject may sound as the secure way to go. Above record will be the reason for upcoming deliverability issues from all sources that are not properly authenticated. While reject policy is the ultimate goal of domain protection, there is a road to be taken first. That road starts with p=none and analysis of the aggregate reports. Above displayed extreme example doesn’t even have any reporting address, making it difficult for the admins to figure out the cause of deliverability issues in the first place. 

Only when the reports uncover all the legitimate sources and all of those sources are properly authenticated using SPF and/or DKIM, you can move to stricter policies. The next step should always be the quarantine and not reject (unless there is just one single well-managed source).

Invalid records

RFCs (Request for comment) - the documents that make up the standards on which the Internet is based, are no easy read. No wonder most sys-admins would rather read Shakespeare then an RFC. Many standards - even the simple ones like DMARC - get misinterpreted. By far the most common mistake plaguing DMARC records comes from the way admins are used to write SPF - repeating rules. While in SPF each attribute in the record must be fully declared including its type eg. “v=spf1 ip4:123.123.123.123 ip4: 234.234.234.234 include:spf.mailkit.eu”, DMARC doesn’t allow this. As a result, we are often seeing the following type of mistakes:

_dmarc IN TXT “v=DMARC1; p=none; rua=mailto:email@email.com; rua=mailto:other@mail.com;”

or

_dmarc IN TXT “v=DMARC1; p=none; rua=email@email.com;”

Both examples are wrong - the first one by repeating the RUA attribute, second by not defining the protocol for the reporting endpoint (mailto). DMARC uses a comma as a separator for multiple reporting addresses so the fix for the first would be as easy as:

_dmarc IN TXT “v=DMARC1; p=none; rua=mailto:email@email.com,mailto:other@mail.com;”

DMARC records also require proper order of attributes - "v=DMARC1; pct=100; p=none; sp=none" is invalid since the pct (percentage of email to apply a policy to) precedes the policy. The corrected record would be "v=DMARC1; p=none; pct=100; sp=none;". But then again - there is no point in declaring implicit values so the pct=100 in this example has no impact.

Over-reporting

As we run DMARC reporting on our corporate mail server at Mailkit, we couldn’t help but notice the amount of reporting addresses that bounce emails. The value of DMARC lies in the reports and can not be understated. Having the reports directed to a non-existent address or ignoring their content defeats the purpose of having DMARC in the first place.

That’s why seeing DMARC records with a large number of reporting addresses is another warning sign. Especially if those addresses are pointing to personal mailboxes which is often the case. Such domains usually include the RUF addresses as well raising even more red flags. In such cases it’s highly unlikely that the receivers are giving any attention to the reports at all.

Keep in mind that the DMARC report is not a human readable text file with straight answers.It’s an XML that needs to be parsed by a reporting tool and analysed in context. And there are tens, sometimes hundreds or even thousands of these files every day. At Mailkit we have built our own reporting suite that is available to our clients and helps us analyze these reports and put them in context to improve authentication for our clients. Similar tools are offered by other providers such as Dmarcian.com, eDatasource, Valimail and 250ok just to name a few.

As we onboard customers we require DMARC records to send reports to our reporting address. We have seen in the past examples of clients that have changed ESP and yet we still receive their DMARC reports, a clear sign that the reports are being ignored not only by admins but smaller providers as well. we onboard customers we require DMARC records to send reports to our reporting address.

Wrong use of SPF with DMARC

This problem is the least documented of many - the interaction between SPF’s "-all" also known as “Hard-fail” policy and DMARC. While there is technically nothing wrong with having SPF “-all” it does have a major impact on DMARC reporting. The problem lies in the order of how individual authentication methods are evaluated by receiving servers. 

SPF is tied to the very start of the communication between the sender and receiver it’s the first one to be evaluated. The “-all” results in the message being rejected “at the door”. A message, which could have passed the DKIM authentication. The next stage where the message headers and DKIM authentication are evaluated never happens. That also means that the DMARC stage which would evaluate the SPF and DKIM authentication results and lead to the policy-based decision will never happen too.

As a result, there is no DMARC report to be done. The email gets rejected and there is no good way to analyze the reason without having access to the bounce message or necessary server logs.
To avoid this problem that is lurking in the dark and often missed is to use the “~all” aka “Soft-fail” in the SPF records. This will leave the delivery policy decision on the method that is meant to make the decision - the DMARC policy.

These are just five most common mistakes of DMARC records but there are many more. We have seen DMARC mixed in with SPF, records without the leading underscore (which are not technically DMARC records) and many more. Errors like these could make a difference between poor, average and great deliverability, but could also lead your sys-admins and deliverability people chasing ghosts.

Proper email authentication and DMARC policy is becoming even more important as new standards like BIMI are building on top of it. If you are interested in more detailed information about DMARC visit DMARC.org, the home of DMARC or feel free to contact us.

_{Image by Freepik.com}