Email Authentication in a nutshell

There are 3 types of authentication currently in use for email.

  • DKIM
  • SPF
  • DMARC

The different strategies do different things with email.

  • DKIM cryptographically signs emails, preventing changes in transit, and designates a “responsible domain” through the d= value in the signature.
  • SPF compare the sending IP and the envelope from (also known as the bounce string, return path or 5321.from) domain to determine if that IP is authorized to send mail using that envelope from domain.
  • DMARC uses DKIM authentication (d= value) or the SPF authentication (envelope from) to authenticate the visible from address (5322.from). DMARC requires that the d= value or the SPF value are in the same “organizational domain” as the visible from address. There is more data about this in my brief DMARC primer post from April 2014. In addition to authenticating the visible from address, there are two things senders can get from publishing a DMARC record. The first is a reporting scheme where you can get reports every time one of your email messages fails SPF or DKIM authentication. The second is a policy process where you ask receiving ISPs to implement a particular policy when the authentication fails (quarantine or reject).

We recommend all our clients authenticate with DKIM and SPF. The specifics of how to authenticate depend on the overall mail stream of the sender and technology available at different service providers.
Our recommendations for DMARC are a little more complex, due to the newness of the protocol and the choices that DMARC offers to senders. We’re currently recommending that clients be aware of the availability of DMARC reporting and start internal discussions and plan to implement reporting in the future. Managing DMARC reports requires some level of infrastructure to accept and process the incoming reports, and this will need to be planned for.
It’s important to understand that even if every message leaves fully authenticated different processes during mail sending (forwarding, etc) may result in authentication failures at the recipients.  This means senders publishing a p=reject policy will lose legitimate mail. In the absence of security concerns, we’re not recommending publishing a policy statement (p=reject or p=quarantine) at this time. For senders who still want to implement DMARC we’re currently recommending that clients collect failure reports for a period of time (6 – 12 months in cases with complex mail systems) before making the decision to publish a p=reject record. Senders with security concerns can implement a p=reject message, but need to be clear that this may result in legitimate mail being lost.
 
 

Related Posts

Hotmail moves to SPF authentication

Hotmail has recently stopped using Sender ID for email authentication and switched to authenticating with SPF. The protocol differences between SenderID and SPF were subtle and most senders who were getting a pass at Hotmail were already publishing SPF records.
From an email in my inbox from September:

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

DMARC: Please Be Careful!

(Cross posted from Spam Resource.)
Every couple of days, somebody new pops up on the DMARC-Discuss mailing list to ask some question or share an observation. It’s great to see people interested and joining the conversation. Clearly, DMARC interest and adoption are growing. What’s really frustrating, though, is that for about a quarter of the new subscribers, their first mailing list message goes to the spam folder in my Gmail account. It has become sort of an intelligence test I apply to new subscribers — I’ve stopped digging those messages out of the spam folder. I’m figuring that if they can’t figure out how to implement a DMARC record, or they don’t understand that it’s not really compatible with mailing lists nor is it meant for hobbyist domains, then I think perhaps they’ve got some things they’ve got to figure out before they’re ready to join the discussion.
To that end, let me take a moment to jot down some recommendations for folks who are considering implementing DMARC.

Read More