Authentication Cheat Sheet

There are a several approaches to authenticating email, and the different authentication methods have a lot of different settings to choose from (sometimes because they’re useful, other times just because they were designed by committee). It’s nice that they have that flexibility for the complex situations that might benefit from them, but almost all the time you just want to choose a good, default authentication approach.
So here’s some short prescriptive advice in no particular order for “how to do email authentication at an ESP well” without the long discussions of alternative approaches and justification of each piece of advice.

  1. Remove every trace of DomainKeys from your email flow
  2. Sign all your email with DKIM
  3. Publish SPF records
  4. Have your SPF records finish with ~all, not -all
  5. Ignore SenderID, unless you have delivery problems at Hotmail (and even then measure results rather than just assuming it will help)
  6. Don’t publish ADSP records
  7. Have the customer pick a single domain to tie their reputation to – ideally their “main” domain, but if that’s not possible then a customer-specific domain owned by the ESP is the next best thing (i.e. “customer.com” is ideal, but “customer.esp.com” is much better than just “esp.com”)
    1. Use that domain as the d= field when signing email (“d=customer.com”)
    2. Use that domain, or a sub-domain of it, in the From: field of the email (“From: Someone <someone@customer.com>” or “From: Someone <someone@fooble.customer.com>”)
  8. Pick a good email address to use in the From: field, don’t change it lightly
  9. Use two-part selectors for DKIM, one specific to you, the ESP, on the right and one for key rotation on the left (why do this?)
  10. Use just what’s needed for DKIM – don’t use i=, l=, q=, x= or z= in the signature, don’t use g= or s= in the published key
    1. dkimcore.org has more specific advice about which subset of DKIM to sign with
  11. Make sure your SPF records are valid
  12. TLS/SSL isn’t useful for authenticating mail (it’s great for connecting to a smarthost from a mail client, but not for connections from the smarthost)
  13. None of SPF, DKIM or TLS are really designed to protect or hide the contents of a message
    1. Customers who really want that could look at S/MIME or PGP
    2. … but better to design their business model such that they don’t need to, as client support is spotty at best
  14. Empirical evidence that doing something will make a customer happy trumps any of the above
    1. maybe because there’s evidence SenderID or ADSP or somesuch really helps that customer
    2. or maybe because the customer just wants it, even if there’s no evidence it would help

Mail client use of authentication data is still in flux, so it’s likely that some of this may change slightly (interaction between SPF and DKIM d= domains, for example) but it’s a pretty good base to start with today.

Related Posts

Domain Assurance by Return Path

As often happens during MAAWG, email companies are announcing new products. One of the interesting ones is the new Domain Assurance product from Return Path.

Read More

Defending against the hackers of 1995

Passwords are convenient for the end user, but it’s too easy to lose control of them. People share them with other people. People write them down, where they can be read. People send them in email, and that email is easily intercepted. People’s web browsers store the passwords, so they can log in automatically. Worst of all, perhaps, people tend to use the same username and password at many different websites. If just one of those websites is compromised (or even run as a password collecting scam) then those passwords can be used to attack accounts at all of the others.
Two factor authentication that uses an uncopyable physical device (such as a cellphone or a security token) as a second factor mitigates most of these threats very effectively. Weaker two factor authentication using digital certificates is a little easier to misuse (as the user can share the certificate with others, or have it copied without them noticing) but still a lot better than a password.
Security problems solved, then?

Read More

ESPs, Non-portable Reputation and Vendor Lock-in

I’ve seen some mentions recently of ESPs suggesting that if you use your own domain in the From: of mail you send through an ESP then that ESP can’t “do email authentication” properly unless they require you to edit your domains DNS settings. That’s not really so, but there is a kernel of truth in there.
The real situation is, unsurprisingly, a bit more complicated.
What authentication features should you look for in an ESP?

Read More