An interview with Tim Draegen, co-inventor of the DMARC standard

The current SMTP standard (as defined in RFC 5321) makes no provision for sender verification. In principle, anyone can compose and send an e-mail message and say that it comes from anyone else ('mail spoofing'). As a result, huge volumes of mail are pumped onto the net every day, exposing users to spam, viruses, phishing scams and the like.

Authentication

DKIM, SPF and DMARC are three related standards for authenticating the sender (a person) and the sending host (a mail server) of e-mail messages:

• DKIM (DomainKeys Identified Mail): With DKIM, a digital signature is attached to the body and header of each outgoing message. The authenticity of the signature can then be verified using the sending domain's public key, as published via the DNS.

• SPF (Sender Policy Framework): SPF enables a mail domain owner to use the DNS to publish a list of the mail servers that are authorised to send mail for the domain in question. The listed servers are typically the SMTP gateways that end users use for their outgoing messages, but may also include the addresses of external service providers that send marketing mail for the organisation. Before processing incoming mail, a receiving mail server (MX server) can then check whether the mail comes from a server that is authorised to send for the named sending domain.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): With DMARC, the owner of a mail domain can use the DNS to publish a policy stating what should be done with messages that fail a DKIM check and/or an SPF check. It's also possible to specify an e-mail address that receiving mail servers can use to report back information about what has been received and how the messages have been processed. That enables the administrator to build a picture of how the mail domain is regarded by the wider internet community.

The three protocols are normally used together, but they don't have to be. You can use DKIM or SPF on its own, or DKIM and SPF together without DMARC. The portal dmarcian.com currently offers a (paid) subscription service where incoming DMARC reports can be processed to yield well-presented statistics and diagrams.

Classification

"When deciding what to implement, it is good to consider things from the recipient's viewpoint," Draegen says. "What the recipient wants is a positive indication that a message can be classified as authentic. It doesn't matter to the recipient whether that indication is based on DKIM of SPF. If you use both, all the better, but in principle it's sufficient to use one of the two."

Draegen sees the integrity added to messages by DKIM digital signatures as relatively unimportant. "A receiving mail server isn't initially interested in message integrity. What matters is that both DKIM and SPF make it clear who the sender of a message is. If the source infrastructure suddenly starts sending spam, you know who to contact. But, without DKIM or SPF, you can't act against someone who sends out fake messages from a given infrastructure."

More efficient processing

"The main purpose of the three standards is to make the processing of mail more efficient," according to Draegen. Many organisations divide incoming mail into two general categories: mail from unauthenticated domains or previously unencountered authenticated domains and mail from known benign mail domains. Processing of the second category is straightforward: the messages can be delivered without more ado. Messages from insecure and unfamiliar domains require thorough checking. Resources can therefore be concentrated where they are needed. It also pays to delay the decision briefly, since a zero-day will not appear on any list. It is very likely that the classification of such a message will be much easier a short while later."

"SpamAssassin doesn't yet offer out-of-the-box support for that approach. However, the Trusted Domain Project provides all the tooling required to set it up yourself."

RFC 7489

Although RFC 7489, which defines the DMARC standard, is a long and dense text, the standard itself was deliberately kept as simple as possible, Draegen says. "The DMARC specification was heavier than most material from the IETF, but that is because we wanted to explain the underlying decision-making in as much detail as possible."

"Participants initially wanted to have some very complex options available, such as the ability to quarantine messages for three days if a message was validated using SPF but not using DKIM. In the end, however, everyone agreed to keep things as simple as possible, which was a good thing, because otherwise people just wouldn't have used it. It ultimately became a pretty good technical specification, but I wouldn't recommend reading it from start to finish, unless of course you're an engineer who needs to implement it."

DNSSEC

For the same reason, DNSSEC is recommended for all three security standards, but isn't mandatory. That means that DKIM doesn't necessarily require the provision of a trust anchor to be provided. That's in contrast to DANE, for example, for which DNSSEC is essential. "We decided at the start that DMARC and DNSSEC shouldn't be linked",recalls Draegen. "You can't put the one standard ahead of the other. DNSSEC has been around for a long time, but, as with the transition to IPv6, it's taking a long time to build up the critical mass. The only thing you can do is keep pushing everything at the same time."

"In the 'DNS Security' section (12.3), we do acknowledge how important the DNS is to the standard — as it is for pretty much the whole of the internet — and we strongly recommend using DMARC in combination with DNSSEC. However, we didn't want people to hold back from implementing DMARC until they had rolled out DNSSEC, because that standard hasn't reached maturity either. What we learnt from DMARC is that, if you want people to actually implement a technology, there have to be plenty of user-friendly tools around. A lot still needs to be done to make DNSSEC much easier to use. Until a registrant simply needs to push a button to enable DNSSEC, you haven't cracked it."

Phishing

"The adoption of DMARC has been driven mainly by the big mail processors, who had a serious problem with phishing mail, according to Draegen. "Being relatively young businesses, social media companies such as Facebook (by far the biggest mail processor in the world) generally have well-consolidated mail infrastructures. A company like that can implement DMARC inside a week."

"It's very different for a bank with a thirty-year history of mergers and acquisitions. If an organisation like that wants to adopt these security standards, they may need to start modifying systems that no one has touched for ten years. That's a hard idea to sell within the organisation. It's only in young companies with serious spam problems that the RoI calculation favours implementation."

"More established companies probably need more time and better tools. Then maybe a fifty-million-euro problem becomes a forty or twenty-million-euro problem. Until the tipping point is reached and the decision is made to do something about the infrastructure."

Cost savings

"Another group that uses e-mail on a large scale are mail marketing companies, Draegen continues. "You might describe them as legitimate spammers. They have a strong interest in ensuring that their messages arrive safely, so they were easily persuaded to implement the new security standards. And, inevitably, such companies have well-defined, modern mail infrastructures."

"The next step is to get the internet providers on board. They could greatly simplify their mail filtering. By using a separate subdomain with DMARC protection, companies such as Amazon and AliExpress could make their messages much more deliverable. For the providers, it would be a cinch to deal with a mail domain such as receipts.amazon.com. All they would have to do is check whether they had encountered the domain before and whether the mail was wanted. That would bring significant cost savings."

"The same goes for the DMARC reports that recipients send back to domain owners. Because customers whose incoming mail is ending up in the spam folder when it shouldn't can now be referred to the sending host. That would mean lower support costs, with the burden finally being shifted to the sender. Security and phishing prevention arguments didn't cut much ice with providers, but the idea of saving money did appeal."

Insight

As more mail processors implement DKIM, SPF and DMARC, it becomes more important for domain name registrants to publish DMARC records. Because failure to follow the trend means risking the non-arrival of your mail. All kinds of people use dmarcian.com, says Draegen. "As well as the techies, we get everyone from estate agents to car wash proprietors on our site. For forty years, people have been able to use e-mail without really worrying about it much. Now service providers have clients asking why their mail isn't getting delivered or how they can stop scammers sending mail that looks as if it comes from them. Abuse is causing a lot of communication problems and hassle. It's only by using DMARC that they can really see what's going on with their domain.

"Small and medium-sized domains are particularly vulnerable to being abused by scammers who are constantly switching from one spoofed domain to the next. The only way of getting a grip on the situation is by identifying yourself with a DMARC record. If you do that, you automatically get dropped from the domain lists used by scammers for spoofing. What's more, you get feedback from recipients, whereas previously all you saw was a spike in your DNS traffic and a pile of bounced messages."

'Bad bank'

Although adoption of DMARC has gone quite quickly compared with DNSSEC and IPv6, a few problems with the security standards remain to be resolved. Automatisch message forwarding and the use of mailing lists are particularly hard to combine with SPF, because the active server doesn't match the original sending domain. "Various partial solutions are in the pipeline," Draegen reports, but we haven't cracked those problems yet. At the moment, the best workaround is to create a separate subdomain — a 'bad bank' if you like — to isolate the problems. Developers are now working to add support for the new security standards to their mailing list software."

"But there are still various things that can go wrong. The combination of various procedures, such as first forwarding and then use with a mailing list, or vice versa, are particularly challenging. It isn't clear what can be done about that kind of thing."

Single-issue solutions

"E-mail has always been an open protocol, says Draegen, "so anyone could use it as a basis for their own applications. DKIM, SPF and DMARC have implications for all those independent applications. In the past, for example, you might see an article on the New York Times website and refer it to a friend by entering whatever address. Your friend would then get a message from the New York Times' domain. That's changed now: when you refer an article, you appear as the sender."

"The IETF is currently looking into the possibility of developing a fairly generic framework to get around the various issues. However, some elements are so cumbersome that it's hard to see them ever being implemented. So, for the foreseeable future, we're going to have to live with a spectrum of single-issue solutions implemented within the various software packages. The role of the IETF is to document those solutions."