BLOG
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.
I give away some analysis scripts here. They need a mysql database and the ability to pipe mail into perl or python scripts to update the database.
http://www.taugh.com/rddmarc/
Hi Laura, Return Path is a co-founder and sponsor of DMARC.org and publishes a free DMARC creation wizard and DMARC/SPF lookup tool at https://stopemailfraud.returnpath.com/dmarc-start/
Yeah, the DMARC record is the easy bit. It’s all the rest of it (like consuming reports and finding out where your mail is actually coming from) that’s the hard part.
Well said, Laura. We created a free tool for processing reports to help people learn more about their domain’s email activity:
https://dmarc.postmarkapp.com
It basically sends a weekly digest with a full API for deeper reports.
With many thousands of domain owners using it, we’ve found that most confusion is around forwarding failures and the fact that just having an SPF record is not good enough, you need the From and Mail From domains to match.
We ended up writing a guide (https://postmarkapp.com/guides/dmarc) to help us reduce support around many of these questions, but it is still really hard to understand the concepts.
Our main goal with the tool was not as much about helping people get to “reject” or “quarantine” but to have better visibility into their domain’s email traffic and help increase adoption of the standard. We even gave away $100K in email credits to support it (http://wildbit.com/blog/2016/02/12/why-we-gave-away-100k-in-postmark-credits).
The above might seem like a lot of self promotion. The truth is, we truly want to help more people adopt it and we want more ISPs to see more domains using it. The hope is that by offering this tool for free it will make it easier and help grow the standard.
What I like the most in your post is that its not yet another DMARC love song. DMARC is not simple and implementation is full of pitfalls. Tools can help with processing reports and checking DNS records. But it requires knowledge and expertise to analyze and interpret the reports. You also have to make difficult choices, about DKIM key management and DMARC policies.
So before you start implementing DMARC, make sure you have the time, the expertise, and the budget to do it well.
We’re a Google Apps for Work customer and are just now rolling out DMARC with a 5% quarantine at the moment. We’re sending our aggregate reports to both ourselves, and automatically to dmarcian.com. I’m no DMARC expert, but dmarcian seems to be an awesome resource with great analytical tools for viewing what’s going on in your domain(s) in relation to the reported data.
Also, we’re small enough, well under their 100,000 legit emails per month limit to stay on their free service. Of course free has it’s limitations after the trial period, so we’ll have to see if it’s worth paying for the additional tools and support.
Excellent article, also some very interesting comments, thank you Laura!
Hi,
great article, thank you 😉
I wanted to share with you a link to a really nice tool to parse and view DMARC reports on your own server (based on rddmarc):
https://github.com/techsneeze/dmarcts-report-viewer
[…] Honestly, I don’t understand DMARC well enough to write about it just yet. Lara Atkins wrote an excellent piece, Should You Publish DMARC? […]
I feel dmarc is not helping, spf is the way to proceed as I already had implemented. Any redirection on a server with dmarc fails, and, really, I have enough waste dmarc reports, meaning… nothing
Returnpath has been purchased by Proofpoint.
Alternative is dmarcian.
Good luck
Some big recipients (ie. Bell South) seem to be rejecting properly signed mail with p=reject set. It’s hard to find anyone to talk to about why. Our ESP won’t let us use our own envelope sending domain so we’re not SPF-aligned, but we are DKIM-aligned. I’m guessing they have some fail in how they’re enforcing DMARC in that case. Gotta love developers and newish standards.
Oh and Microsoft’s still breaking the DKIM signatures on almost every mail they forward, so anyone forwarding from Hotmail to Gmail won’t receive p=reject mail.