Should you publish DMARC?
I’ve been hearing a lot lately about DMARC. Being at M3AAWG 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.