Should you publish DMARC?

laura
Industry
February 17, 2016

I’ve been hearing a lot lately about DMARC. Being at M³AAWG has increased that. Last night we were at dinner and heard from the next table “And they’re not even publishing DMARC!!!!”
I know DMARC is the future. I know folks are going to have to start publishing DMARC records. I also know that the protocol is the future. I am also not sure that most companies are ready for DMARC.
So lets take a step back and talk about DMARC, what it is and why I’m still a little hesitant to jump on the PUBLISH DMARC NOW!! bandwagon.

DMARC spec

There are multiple parts to the spec.
DMARC reporting. This lets you publish a DNS record where you can receive reports about authentication failures.
DMARC policy. This lets you publish a DNS record that asks receivers how to deliver mail (or not deliver mail) when authentication fails.
A DMARC DNS record has the following structure:
_dmarc.example.com TXT “v=DMARC1;p=reject;pct=100; rua=mailto:dmarcaddress@dmarc.example.com”

v=DMARC1 is the version indicator.
p=reject is the policy request (alternatives are “quarantine” and “none)
rua=mailto:postmaster@dmarc.example.com – asks for failure reports to be sent to the address dmarcaddress@dmarc.example.com

DMARC Reporting

DMARC reporting is useful for a lot of companies. But there is planning and processes that must be done before reports can be usefully consumed. A few years ago one of my clients was talking about their experience with DMARC. “We published a DMARC record and I put my address in and my address is unusable!!” Yeah. Exactly. Unless you have a way to understand and process the reports they’re not useful and you can end up mailbombing the poor person receiving the reports.
Multiple companies have report aggregators you can use (I hope the companies will post links to their free tools in the comments). But I’m not aware of tools that are available to install on your own machines to handle the incoming reports.

DMARC Policy

DMARC policy statements let you tell receivers how you would like mail handled if it fails authentication or if the mail is unaligned. I wrote about alignment in my post from a few years ago “A brief DMARC primer” which has pictures to describe what alignment is.
Unaligned mail happens frequently. A number of providers don’t have the ability to create custom envelope from addresses. And they don’t have the ability to sign with unique DKIM keys. Alignment is a challenge for a lot of providers.
SPF and DKIM failures also happen. Many, many providers are publishing invalid SPF records. Even the big guys can’t always get it right (eBay). Sometimes mail leaves the sending server fully authenticated only to arrive at the recipient server and fail authentication. There was an incident a few months ago where a major ISP changed their internal routing. This caused widespread SPF failures when an internal IP was identified as the source IP, instead of the correct IP.

DMARC is hard

DMARC is a technical challenge, but it’s also a policy challenge. There is a lot of Internet infrastructure that is not quite ready for a place where every email message is aligned and authenticated. We’re getting there. We’re absolutely getting there. But there is a lot of technical debt that many, many companies need to retire before we can have every message aligned an authenticated.
Even more challenging, it is the individual, one-to-one very high value email that is most at risk with a p=reject mail. The bulk mailers are addressing things quite well, and trying to work out ways their customers can publish DMARC. But a lot of not-bulk providers aren’t even really looking at the issues. And there is a dearth of non-technical tools for DNS management.

What you should do about DMARC?

Right now, consuming reports is good. There is a lot of value in knowing where your mail is coming from, where it’s authenticated and where it’s not authenticated.
There are a number of providers who will collect reports for you and provide you with some information on mail that is legitimate but not authenticated.. I think many places will be surprised to find out where their mail is sent from legitimately.
If you’re thinking about a p=reject or even a p=quarantine policy request I strongly recommend consuming reports for a minimum of 3 months. 6 or 12 months would be even better.
Now, there are a lot of companies that have had to turn on p=reject to address an immediate security problem. This happens and p=reject will stop the direct phishing of your domain. This can cause delivery problems for legitimate mail, though.
Any decision to turn on DMARC policy statements requires a clear understanding of how email is used at that business. There are consequences to publishing p=reject and even p=quarantine. The consequences could be problematic. Each company must evaluate, for themselves, whether or not a policy statement will benefit or harm their business.

Spam, Phish or Malware?

Some mornings I check mail from my phone. This showed up this morning.

My first thought was “oh, no, Pizza Hut is spamming, wonder who sold them my address.”
Then I remembered that iOS is horrible and won’t show you anything other than the Friendly From and maybe it was some weird phishing scheme.
When I got to my real mail client I checked headers, and sure enough, it wasn’t really from Pizza Hut. I’m guessing actually malware, but I don’t have a forensics machine to click the link and I’m not doing it on anything I can’t wipe (and have isolated from the rest of my network).
The frustrating thing for me is that this is an authenticated email. It not from Pizza Hut, the address belongs to some company in France. Apparently, that company has had their systems cracked and malware sent through them. Fully authenticated malware, pretending to be Pizza Hut, and passing authentication on various devices.
Pizza Hut isn’t currently publishing a DMARC record, but in this case, a DMARC record for Pizza Hut wouldn’t matter. None of the email addresses in the headers point to Pizza Hut.
I spent last week listening to a lot of people discussing DMARC and authentication and protecting people from scams and headers. But those all the protocols in the world won’t protect against this kind of thing. Phishing and malware can’t be fixed by technology alone. Even if every domain on the planet published a p=reject policy, mail like this would still get through.

What to expect in 2016

I don’t always do predictions posts, even though they’re popular. Most years I skip them because I don’t see major changes in the email space. And, I’m not the type to just write a prediction post just to post a prediction.
This year, though, I do see changes for everyone in the email space. Most of them center on finally having to deal with the technical debt that’s been accumulating over the past few years. I see ISPs and ESPs spending a lot of development effort to cope with the ongoing evolution authentication requirements.
When people started seriously looking at how to authenticate email, the first goal was getting organizations to implement the protocols. This was a practical concession; in order for a new protocol to be used it needs to be widely implemented. Phase one of authenticating email was simply about publishing protocols and getting organizations to use them.
During phase one, the organization that authenticated a mail hasn’t been important. In fact, the SPF spec almost guarantees that the ESP domain is the authenticated domain. In DKIM, the spec says any domain could sign as long as they could publish a public key in that domain’s domainkeys record.
ESPs took full advantage of this and lowered their own development overhead by taking most of the authentication responsibility on themselves. Their domains were in the 5321.from and they published the SPF records. Domains they control were in the d= and they generated and published the DKIM keys. Mail was authenticated without ESP customers having to do much.
We’ve hit the end of phase one. Most of the major players in the email space are authenticating outbound email. Many of the major players are checking authentication on the inbound. Phase one was a success.
We’re now entering phase two, and that changes thing. In phase two, SPF and DKIM are used as the foundation for user visible authentication. Neither SPF nor DKIM were designed to be user visible protocols. To understand what they’re authenticating you have to understand SMTP and email. Even now there are days when I begin talking about one of them and have to take a step back and think hard about what is being authenticated. And I use these things every day!
DMARC is the first of these end user visible protocols built on SPF and DKIM. It uses the established and widespread authentication to validate the user visible from address. This authentication requires that the d= value or the 5321.from address belong belong to the same domain in the visible from address. While you can pick whether the alignment between the visible from and the authentication is “strict” or “relaxed” you have no choice about the alignment.
Prior to DMARC no one really paid much attention to the domain doing the authentication. Authentication was a yes or a no question. If the answer was yes, then receivers could use the authenticated domain to build a reputation. But they weren’t really checking much in the way of who was doing the authentication.
In the push to deploy authentication, ESPs assumed the responsibility for authentication deployed ESPs took the responsibility and did most of the work. For many or most customers, authentication was as simple as clicking a checkbox during deployment. Some ESPs do currently let customers authenticate the mail themselves, but there’s enough overhead in getting that deployed that they often charged extra to cover the costs.
DMARC is rapidly becoming an expectation or even a full on requirement for inbox delivery. In order to authenticate with DMARC, the authenticating domain must be in the same domain space as the visible from. If senders want to use their own domain in the visible from, DNS records have to be present in that domain space. Whether it’s a SPF TXT record or a domainkeys record the email sender customer needs to publish the correct information in DNS. Even now, if you try to authenticate with DKIM through google apps, they require you to publish DNS records.
ESPs aren’t in a situation where they can effectively manage authentication alignment for all their customers. Hosting companies are in even worse shape when it comes to letting customers authenticate email. Developers are facing the fact they need to go back and rework their authentication code. Businesses are facing the fact they need to change their processes so customers can authenticate with DMARC.
It’s not just the infrastructure providers that are facing challenges with authentication. Senders are going to discover they can no longer hand authentication off to their ESPs and not worry about it. They’re going to have to get DNS records published by their own staff.
Getting DNS updates through some big companies is sometimes more difficult than it should be. I had one client a few years ago where getting rDNS changed to something non-generic took over a month. From an IT standpoint, changing DNS should require approvals and proper channels. Marketers may find this new process challenging.
And, if organizations want to publish reject policies for their domains, then they will have to publish records for every outside provider they use. Some of those providers can’t support DMARC alignment right now.
In 2016 a lot of companies will discover their current infrastructure can’t cope with modern authentication requirements. A lot of effort, both in terms of product development and software development, will need to be spent to meet current needs. This means a lot of user visible features will be displaced while the technical debt is paid.
These changes will improve the security and safety of email for everyone. It won’t be very user visible, which will give the impression this was a slow year for email development. Don’t let that fool you, this will be a pivotal year in email.

Salesforce SPF and now DKIM support

Salesforce has published a SPF record for sending emails from Salesforce for years and with the Spring ’15 release, they will provide the option to sign with DKIM.
The SPF record is straight forward, include:_spf.salesforce.com which includes _spf.google.com, _spfblock.salesforce.com, several IP address blocks, mx, and ends with a SoftFail ~all.
Salesforce Knowledge Article Number: 000006347 goes in-depth with information regarding their SPF Record.