Email itself is quite old, and so are the protocols standardized for it. Between all these old protocols, DMARC, short for Domain-based Message Authentication, Reporting and Conformance, is practically still an infant. We explain the purpose behind this protocol and how it works in this article.
The history of DMARC
The email has already been extended several times and supplemented by new protocols and standards. Many extensions have important security goals that should be respected in today’s communications. The fact that many extensions limit usability and are more of a limitation than an improvement for most e-mail users was already shown in the well-known paper”Why Johnny Can’t Encrypt” by Whitten and Tygar about the usability of PGP. Unlike PGP, which requires a lot of interaction from the user, DMARC is a protocol that is virtually invisible to the user and runs in the background.
DMARC has been under development since 2010. It should, on the one hand, allow senders to enact policies for authenticating emails and handling them when they are not authenticated, and on the other hand, allow recipients to send error reports to the sender domain. Major companies developed or are still working on the DMARC specification, such as AOL, GMail, Yahoo! Mail, Facebook, LinkedIn, PayPal, and Bank of America. The developed specification was published in 2012 and submitted to the Internet Engineering Task Force(IETF) for standardization. DMARC has not yet been standardized by the IETF, but was published for informational purposes in RFC 7489 in 2015.
How DMARC works
DMARC builds on two well-known protocols, SPF and DKIM. It specifies how a recipient should proceed if they receive an email that does not pass the SPF or DKIM check. For this purpose, the sender deposits a DMARC policy as a TXT record in the DNS.
Let’s take a look at one such policy:
First the protocol version is stored, up to now only the value “DMARC1” can be specified here. This is followed by instructions on what to do with emails from the main domain if SPF and DKIM are unsuccessful. For this purpose, three different options can be selected, “None”, i.e. no change and a normal passing of the email, “quarantine”, i.e. marking the email as spam, or “reject”, rejecting such an email. If the SPF check or the DKIM check is successful, no action is taken. In addition, DMARC allows reports to be generated if an email fails the SPF or DKIM check. To do this, one specifies an address under “rua” to which an aggregated report is sent typically as an XML file, once a day. Under “ruf” a forensic report can be sent, which is created per rejected email and sent directly. Additionally, “adkim” and “aspf” can be used to specify how the domains should be checked with DKIM or SPF. With “relaxed”, i.e. an “r” as value, the checked domains may also contain subdomains, otherwise not.
The advance of DMARC
Standards have a long way to go on the Internet before they become established. DMARC is also not yet used by all email providers, but it is spreading faster and faster. Looking at the valid DMARC records in the DNS, it can be seen that more and more domains are using DMARC to send emails. By the end of 2021, approximately 5 million policy entries existed. A pleasing development.
Conclusion
If emails are sent via your own domain, setting up SPF, DKIM and DMARC is important and another step towards a secure Internet. The setup is quite simple and provides clear instructions on how to deal with non-authenticated emails. At the same time, the domain owner receives information about which emails are sent in his name and can investigate them further.
