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.

AOL admits to security breach

According to Reuters AOL has admitted there was a breach of their network security that compromised 2% of their accounts. Users are being told to reset their passwords, and security questions.
AOL started investigating the attack after users started reporting an uptick in spam from aol.com addresses. This spam was using @aol.com addresses to send mail to addresses in that user’s address book.
According to the AOL mail team, they are still investigating the attack, but they do not believe financial information was compromised. Their statement reads in part:

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:

Compromises and phishing and email

Earlier this month, Sendgrid reported that a customer account was compromised and used for phishing. At the time Sendgrid thought that it was only a single compromise. However, they did undertake a full investigation to make sure that their systems were secure.
Today they released more information about the compromise. It wasn’t simply a customer account, a Sendgrid employee’s credentials were hacked. These credentials allowed the criminals to access customer data, and mailing lists. Sendgrid has a blog post listing things customers should do and describing the changes they’re making to their systems.
Last month it was Mandrill. Today it’s Sendgrid. It could be anyone tomorrow.
Security is hard, there’s no question about it. Users have to have access. Data has to be transferred. Every user, every API, every open port is a way for a bad actor to attempt access.
While it wasn’t said directly in the Sendgrid post, it’s highly likely that the employee compromise was through email. Most compromises go back to a phish or virus email that lets the attacker access the recipient’s computer. Users must be ever vigilant.
We, the email industry, haven’t made it easy for users to be vigilant. Just this weekend my best friend contacted me asking if the email she received from her bank was a phishing email. She’s smart and she’s vigilant, and she still called the number in the email and started the process without verifying that it was really from the bank. She hung up in the transaction and then contacted me to verify the email.
She sent me headers, and there was a valid DMARC record. But, before I could tell her it wasn’t a phishing email, I had to go check the whois record for the domain in question to make sure it was the bank. It could have been a DMARC authenticated email, but not from the bank. The whois records did check out, and the mail got the all clear.
There’s no way normal people can do all this checking on every email. I can’t do it, I rely on my tagged addresses to verify the mail is legitimate. If the mail comes into an address I didn’t give the sender, then it’s not legitimate – no matter what DMARC or any other type of authentication tells me. But most people don’t have access to tagged or disposable addresses.
I don’t know what the answers are. We really can’t expect people to always be vigilant and not fall for phishing. We’re just not all present and vigilant every minute of every day.
For all of you who are going to tell me that every domain should just publish a p=reject statement I’ll point out DMARC doesn’t solve the phishing problem. As many of us predicted, phishers just move to cousin and look alike domains. DMARC may protect citi.com, but citimarketingemail.com or citi.phisher.com isn’t.
We’ve got to do better, though. We’ve got to protect our own data and our customer’s data better. Email is the gateway and that means that ESPs, with their good reputations and authentication, are prime targets for criminals.