Are you ready for DMARC?

laura
Industry
December 15, 2015

The next step in email authentication is DMARC. I wrote a Brief DMARC primer a few years ago to help clear up some of the questions about DMARC and alignment. But I didn’t talk much about where DMARC was going. Part of the reason was I didn’t know where things were going and too much was unclear to even speculate.
We’re almost 2 years down the line from the security issues that prompted Yahoo to turn on p=reject in their DMARC record. This broke a lot of common uses of email. A lot of the damage created by this has been mitigated and efforts to fix it continue. There’s even an IETF draft looking at ways to transfer authentication through mailing lists and third parties.
For 2016, DMARC alignment is going to be a major factor in deliverability for bulk email, even in the absence of a published DMARC record.

What’s DMARC alignment?

DMARC alignment is where either the Return Path (5321.From, Envelope From, Bounce String) or the DKIM d= value is in the same domain space as the visible from address (5322.From, sender).

Why do you think so?

I’m already seeing some delivery issues for certain domains that are unaligned, particularly at ISPs like AOL and Yahoo.

What do I do?

If you’re an ESP customer, ask your ESP about using a custom bounce string / return path so your domain aligns. You just need to add a MX record for that domain that points to the ESPs bounce handler.
If you’re an ESP customer and can’t add a MX, ask them about signing your mail with a custom DKIM key that is at your domain. You will need to do a little DNS work – either publishing your public key yourself or publishing a DNS record that points to their public key server.
If you’re an ESP, and you can’t sign with custom keys or handle custom 5321.From addresses, you need to look at your development path and figure out how fast you can do either.

I’m not publishing DMARC, so this doesn’t affect me.

ISPs are already evaluating DMARC alignment on all incoming mail.
dmarc=pass (aol.com: the domain example.com reports that SPF aligns in relaxed mode, DKIM is unaligned.) header.from=test.example.com;
It’s a short step to use that as part of their delivery decisions, particularly when there is no alignment.

My unaligned mail is delivering just fine.

I’m sure it is. I also don’t think that’s a given for the future. I think it’s wise to be looking to have as much of your mail as possible aligned sooner rather than later.

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:

How long is your DKIM key?

While we were at M³AAWG, Wired published an article talking about how simple it was to crack DKIM keys. I didn’t post about it at the time because it didn’t really seem like news. DKIM keys smaller than 1024 are vulnerable and not secure and the DKIM spec does not recommend using keys smaller than 1024. When I asked the DKIM-people-who-would-know they did tell me that the news was that the keys had been cracked and used in the wild to spoof email.
Fair enough.
If you are signing with DKIM, use a key 1024 or longer. Anything shorter and your risk having the key cracked and your mail fraudulently signed.
This morning M³AAWG published recommendations on keeping DKIM keys secure.

DMARC=BestGuessPass

Looking at the headers within the mail received with my Office365 domain I see dmarc=bestguesspass. BestGuessPass? That’s a new.
Authentication Results
A few days after seeing dmarc=bestguesspass, Terry Zink at Microsoft posted an explanation. Exchange Online Protection, the filtering system for Office365, is analyzing the authentication of incoming emails and if the domain is not publishing a DMARC record, EOP attempts to determine what the results would be if they did. If an email is received that is not authenticated with either SPF or DKIM, the dmarc= results show none just as it always had. DMARC=BestGuessPass will appear if the message is authenticated and the matching authenticated domain does not have a DMARC record.
Having this information is helpful to see what the results would be before setting up a DMARC record. If you are seeing dmarc=bestguesspass when your mail is sent to an Office365 address and you are considering DMARC, the next step would be to publish a p=none DMARC policy and begin to document where your mail is being sent from. P=none will not have an impact on your delivery and asks the receiving mail server to take no action if a DMARC check fails. Once you have setup SPF and DKIM for your mail, p=none policy gives you the ability to begin receiving failure reports from receiving mail servers when unauthenticated mail is sent from your domain.