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

Would you buy a used car from that guy?

There are dozens of people and companies standing up and offering suggestions on best practices in email marketing. Unfortunately, many of those companies don’t actually practice what they preach in managing their own email accounts.
I got email today to an old work email address of mine from Strongmail. To be fair it was a technically correct email. Everything one would expect from a company handling large volumes of emails.  It’s clear that time and energy was put into the technical setup of the send. If only they had put even half that effort into deciding who to send the email to. Sadly, they didn’t.
My first thought, upon receiving the mail, was that some new, eager employee bought a very old and crufty list somewhere. Because Strongmail has a reputation for being responsible mailers, I sent them a copy of the email to abuse@. I figured they’d want to know that they had a new sales / marketing person who was doing some bad stuff.
I know how frustrating handling abuse@ can be, so I try to be short and sweet in my complaints. For this one, I simply said, “Someone at Strongmail has appended, harvested or otherwise acquired an old email address of mine. This has been added to your mailing list and I’m now receiving spam from you. ”
They respond with an email that starts with:
“Thank you for your thoughtful response to our opt-in request. On occasion, we provide members of our database with the opportunity to opt-in to receive email marketing communications from us.”
Wait. What? Members of our database? How did this address get into your database?
“I can’t be sure from our records but it looks like someone from StrongMail reached out to you several years ago.  It’s helpful that you let us know to unsubscribe you.  Thank you again.”
There you have it. According to the person answering email at abuse@ Strongmail they sent me a message because they had sent mail to me in the past. Is that really what you did? Send mail to very old email addresses because someone, at some point in the past, sent mail to that address? And you don’t know when, don’t know where the address came from, don’t know how it was acquired, but decided to reach out to me?
How many bad practices can you mix into a single send, Strongmail? Sending mail to addresses where you don’t know how you got them? Sending mail to addresses that you got at least 6 years ago? Sending mail to addresses that were never opted-in to any of your mail? And when people point out, gently and subtly, that maybe this is a bad idea, you just add them to your global suppression list?
Oh. Wait. I know what you’re going to tell me. All of your bad practices don’t count because this was an ‘opt-in’ request. People who didn’t want the mail didn’t have to do anything, therefore there is no reason not to spam them! They ignore it and they are dropped from your list. Except it doesn’t work that way. Double opt-in requests to someone has asked to be subscribed or is an active customer or prospect is one thing. Requests sent to addresses of unknown provenance are still spam.
Just for the record, I have a good idea of where they got my address. Many years ago Strongmail approached Word to the Wise to explore a potential partnership. We would work with and through Strongmail to provide delivery consulting and best practices advice for their customers. As part of this process we did exchange business cards with a number of Strongmail employees. I suspect those cards were left in a desk when the employees moved on. Whoever got that desk, or cleaned it out, found  those cards and added them to the ‘member database.’
But wait! It gets even better. Strongmail was sending me this mail, so that they could get permission to send me email about Email and Social Media Marketing Best Practices. I’m almost tempted to sign up to provide me unending blog fodder for my new series entitled “Don’t do this!”

Read More

What is Two Factor Authentication?

Two factor authentication, or the snappy acronym 2FA, is something that you’re going to be hearing a lot about over the next year or so, both for use by ESP employees (in an attempt to reduce the risks of data theft) and by ESP customers (attempting to reduce the chance of an account being misused to send spam). What is Authentication?
In computer security terms authentication is proving who you are – when you enter a username and a password to access your email account you’re authenticating yourself to the system using a password that only you know.
Authentication (“who you are”) is the most visible part of computer access control, but it’s usually combined with two other A’s – authorization (“what you are allowed to do”) and accounting (“who did what”) to form an access control system.
And what are the two factors?
Two factor authentication means using two independent sources of evidence to demonstrate who you are. The idea behind it is that it means an attacker need to steal two quite different bits of information, with different weaknesses and attack vectors, in order to gain access. This makes the attack scenario much more complex and difficult for an attacker to carry out.
It’s important that the different factors are independent – requiring two passwords doesn’t count as 2FA, as an attack that can get the first password can just as easily get the second password. Generally 2FA requires the user to demonstrate their identity via two out of three broad ways:

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