DMARC: Way cooler than it sounds

When Jon Postel wrote the SMTP standard (RFC 5321, formerly known as RFC 2321 or RFC 821) in 1982, the Internet was a 13-year old academic and military research network, and the TCP/IP portion consisted of just a handful of nodes (see the History of the Internet on Wikipedia). “Tootsie” was the highest grossing film that year. The Analog Mobile Phone System (AMPS) was approved by the FTC. Nobody had an iPhone yet, let alone an always-on connection to every other machine in the world.

In this early phase, there wasn’t much sense for Jon to add in security features such as authentication, because everyone on the network could be trusted, and they all knew each other. Fast forward three decades, and obviously the same thing can’t be said for today’s Internet. Yet despite the Internet’s pervasiveness, and the scale of the modern spam problem and other email-borne security concerns, the SMTP protocol has remained largely unchanged.

In the mid-2000s, with the exponential rise in email spam, the Internet industry got organized against email abuse, creating a number of standards that could be overlaid atop email to make it more secure and reliable. Arguably the most successful of these standards – in relation to the control of spam, anyhow – were Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM). SPF and DKIM tie SMTP connections and email message content to a specific domain name, allowing receivers to validate that the connections and content are coming from a place that is consistent with the wishes of the domain name owner. Both standards are widely adopted, and play a helpful role in combatting abuse, by providing a new trustworthy identifier (the domain name) in addition to the IP address, that can be tracked to establish a sender’s behaviour and reputation.

However, while SPF and DKIM are useful standards, there has always been something missing: Email senders have – until now – had no way of communicating to email receivers their intentions around how their SPF and DKIM authenticated (and unauthenticated) email should be handled. For example, should bankofamerica.com email that originates from outside of Bank of America’s network be thrown in the junk, or just treated as a little more suspicious than usual? (Probably it should be junked – but you’d be surprised how difficult it is for a large organization to make this assertion without causing real harm to legitimate email)

Thus, while senders could use SPF and DKIM to “claim ownership” of the content they sent out, senders had no standardized way to communicate their intentions to email receivers as to how they wished their SPF and DKIM policy to be enforced. Furthermore, receivers had no standardized way of letting sender’s know about the email they were receiving from a sender’s domain – whether that email was authentically from the sending domain, or from a fraudster. Well, now we have a solution: DMARC.

Domain-based Message Authentication, Reporting & Conformance (DMARC) provides a relatively simple new mechanism that lets domain owners tell email receivers how they want their domain treated when it comes to email traffic. DMARC also lets domain owners ask for feedback from receivers about the email traffic relating to their domain name. For example, domain owners can get a regular report from Google indicating who sent fraudulent email to Gmail users in violation of the domain owner’s DMARC policy.

Here’s what makes DMARC so cool: You can get reports back telling you exactly how your domain is being used/abused. This information can then be used to assist in identifying – very precisely – who is abusing your domain (for example, to send spam), and to what extent, so that the abuser can be taken down. Additionally, you can register to receive “forensic” reports – samples of messages sent in violation of your DMARC authentication policy. DMARC thus closes the loop between senders, receivers, and fraudsters, in a way that has never before been possible.

To get started with DMARC, simply create a TXT record in your DNS such as the following:

v=DMARC1; p=reject; rua=mailto:dmarc-rua@mydomain.com; ruf=mailto:dmarc-ruf@mydomain.com;

Once you publish this TXT record, Gmail and other major receivers will start sending you regular feedback about how they are seeing your domain. Reports about all email from your domain will be sent to the dmarc-rua@mydomain.com address; samples of fraudulent emails using your domain will be sent to dmarc-ruf@mydomain.com.

In the coming months, doubtless various firms will offer free DMARC monitoring services that can take in and process this feedback data. Until then, enjoy receiving your shiny new DMARC reports. And stay tuned to this exciting new anti-abuse mechanism.