Should you publish DMARC?

secure_email_blogI’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.
 

Related Posts

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

Read More

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More

Spam, Phish or Malware?

Some mornings I check mail from my phone. This showed up this morning.
PizzaHutMail
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.
 
 
 

Read More