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.
- Remove every trace of DomainKeys from your email flow
- Sign all your email with DKIM
- Publish SPF records
- Have your SPF records finish with ~all, not -all
- Ignore SenderID, unless you have delivery problems at Hotmail (and even then measure results rather than just assuming it will help)
- Don’t publish ADSP records
- 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”)
- Use that domain as the d= field when signing email (“d=customer.com”)
- 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>”)
- Pick a good email address to use in the From: field, don’t change it lightly
- 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?)
- 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
- dkimcore.org has more specific advice about which subset of DKIM to sign with
- Make sure your SPF records are valid
- 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)
- None of SPF, DKIM or TLS are really designed to protect or hide the contents of a message
- Customers who really want that could look at S/MIME or PGP
- … but better to design their business model such that they don’t need to, as client support is spotty at best
- Empirical evidence that doing something will make a customer happy trumps any of the above
- maybe because there’s evidence SenderID or ADSP or somesuch really helps that customer
- 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.
RSS - Posts
I don’t agree at all with #4. It leaves space for spammer to abuse of your brand with no advantage in turn: can you give some more detail? AFAIK deliverability is not better when you use ~all instead of -all.
Also, you could have sorted the points: SPF related stuff together, DKIM related stuff together.
There are many cases where SPF will fail (forwarding, for example). If you use ~all, mail will be delivered in those cases. If you use -all then it will not be delivered at an ISP that’s paying strict attention to SPF.
Conversely, there is no case when mail will be delivered with -all when it wouldn’t be with ~all, so delivery rates will never be better with -all, and almost always will be worse.
So the only situation when you want to use -all in an SPF record is when you want to reduce your delivery rates.
As for “spammer abusing a brand”… I can trivially send email that passes both SPF and DKIM, which uses your brand in the From: header, the subject line and the body of the email. So the concept of brand protection (at an email delivery level) is simply a red herring. There’s no such thing.
@steve Could you please send me a fake mail that passes SPF and DKIM with newsletter.srv2.de in FROM Header to lockhead883@googlemail.com? I’m going along with Stefano here, the main goal is to reach the customers inbox and I don’t think the percentage of people using mail forwarding is higher than the abuse risk in allowing anybody to spoof your from only to get a softfail…
Point 12: I only first heard of people talking of using TLS/SSL for “authentication”. So weird — I guess that they’re assuming that you could use the certificate’s CN as a key identifier for tying to reputation, but what they’re not considering, is that unlike DNS which has a single root, there are PLENTY of Certificate Authorities, and how can you say that all receiving MTAs will accept CNs signed by a certain set of CAs etc etc.
People boggle my brain.
[ forgot to write ]…
“talking of using TLS/SSL for “authentication” at the recent SF MAAWG.
There are a lot of people “doing email” who don’t really know it at a protocol level (not unreasonably, there’s a lot of protocol there) and some of them use “the web” as their mental model for it. Combine that with the common use of TLS for MUA submission (to encrypt the connection, and authenticate the server identity) and it’s not surprising their thoughts would head in that direction.
The big difference between the is that HTTP is an end-to-end protocol while SMTP is store-and-forward – so you can’t use TLS for end-to-end authentication of anything over SMTP.
Peter, apparently there’s a banking organization (not sure which) that has been talking about requiring all their members to use TLS for all email — which sounds fine, except that (as usual) it starts bleeding into the authentication discussions.
But the truth is, I only included TLS on the flowchart to make sure there’d be something to talk about. I knew there wouldn’t be any disagreement about most of the rest. *grin*
[…] Cheat Sheet – http://ow.ly/5KGTA – by @wise_steve – #envracemm […]