Are you ready for DMARC?

secure_email_blogThe 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. 

Related Posts

Email predictions for 2015

Welcome to a whole new year. It seems the changing of the year brings out people predicting what they think will happen in the coming year. It’s something I’ve indulged in a couple times over my years of blogging, but email is a generally stable technology and it’s kind of boring to predict a new interface or a minor tweak to filters. Of course, many bloggers will go way out on a limb and predict the death of email, but I think that’s been way over done.
ChangeConstant
Even major technical advancements, like authentication protocols and the rise of IPv6, are not usually sudden. They’re discussed and refined through the IETF process. While some of these changes may seem “all of a sudden” to some end users, they’re usually the result of years of work from dedicated volunteers. The internet really doesn’t do flag days.
One major change in 2014, that had significant implications for email as a whole, was a free mail provider abruptly publishing a DMARC p=reject policy. This caused a lot of issues for some small business senders and for many individual users. Mailing list maintainers are still dealing with some of the fallout, and there are ongoing discussions about how best to mitigate the problems DMARC causes non-commercial email.
Still, DMARC as a protocol has been in development for a few years. A number of large brands and commercial organizations were publishing p=reject policies. The big mail providers were implementing DMARC checking, and rejection, on their inbound mail. In fact, this rollout is one of the reasons that the publishing of p=reject was a problem. With the flip of a switch, mail that was once deliverable became undeliverable.
Looking back through any of the 2014 predictions, I don’t think anyone predicted that two major mailbox providers would implement p=reject policies, causing widespread delivery failures across the Internet. I certainly wouldn’t have predicted it, all of my discussions with people about DMARC centered around business using DMARC to protect their brand. No one mentioned ISPs using it to force their customers away from 3rd party services and discussion lists.
I think the only constant in the world of email is change, and most of the time that change isn’t that massive or sudden, 2014 and the DMARC upheaval notwithstanding.
But, still, I have some thoughts on what might happen in the coming year. Mostly more of the same as we’ve seen over the last few years. But there are a couple areas I think we’ll see some progress made.

Read More

How long is your DKIM key?

While we were at M3AAWG, 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 M3AAWG published recommendations on keeping DKIM keys secure.

Read More

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.

Read More