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:

Authentication-Results: hotmail.com; sender-id=pass (sender IP is 65.55.240.72) header.from=******@microsoft.discoverbing.com; dkim=fail (testing mode) header.d=microsoft.discoverbing.com; x-hmca=pass
X-SID-PRA: *********@microsoft.discoverbing.com
X-SID-Result: Pass
X-DKIM-Result: Fail(t)
X-AUTH-Result: PASS

From an email I just sent myself:

Authentication-Results: hotmail.com; spf=pass (sender IP is 209.85.214.174) smtp.mailfrom=*****@gmail.com; dkim=pass header.d=gmail.com; x-hmca=pass
X-SID-PRA: ****@gmail.com
X-AUTH-Result: PASS
X-SID-Result: PASS

And, since we’re here, let’s look at how to read the Authentication-Results line.
Authentication-Results: hotmail.com; spf=pass (sender IP is 209.85.214.174) smtp.mailfrom=*****@gmail.com; dkim=pass header.d=gmail.com; x-hmca=pass
Authentication-Results: header added by Hotmail to give authentication results.
hotmail.com: domain doing the authenticating.
spf=pass (sender IP is 209.85.214.174) smtp.mailfrom=*****@gmail.com: Authentication results for SPF. This tells you what IP Hotmail received the email from, as well SMTP.mailfrom address they used when checking the SPF. In this case, 209.85.214.174 is a google IP and is authorized to use gmail in the SMTP.mailfrom / return path / envelope from.
dkim=pass header.d=gmail.com: Says that the DKIM signature validated and the signing entity (d=) is gmail.com.
 
 

Data, data, elections and data
Fun with Subject lines

Related Posts

Gmail sending out warnings for 512 bit DKIM keys

As an update to yesterday’s post, Gmail is contacting postmasters at domains signing with 512 bit keys to warn them of the upcoming changes. This message also clarifies “DKIM keys failing.” Messages signed with 512 bit keys or less will be treated as unsigned by Gmail in the next week or so.

Read More

Gmail shows authentication data to the recipient

Yesterday Gmail rolled out some changes to their interface. One of the changes is that they are now showing end users authentication results in the user screen.
It’s really the next step in email authentication, showing the results to the end user.
So how does Google do this? Google is checking both SPF and DKIM. If mail is authenticated and the authentication matches the from address then they display the email as:
mail from steve to me
If we click on “details” for that message, we find more specific information.
full details of message showing signing domain and spf domainIn this case the mail went through our outgoing mailserver to gmail.
Mailed-by indicates that the message passed SPF and that the IP address is a valid source of mail from wordtothewise.com.
Signed-by shows the domain in the DKIM d=. In this case, we signed with the subdomain dt.wordtothewise.com. That’s what happens when you sign using the domain in the From address (or a subdomain of it).
For a lot of bulk senders, though, their mail is signed using their ESP’s domain instead.  In that case Gmail shows who signed the mail as well as the from address.

And when we click on “details” for that message we see:
3rd party signature detailsThis is an email from a sender using Madmimi as an ESP. Madmimi is handling both the SPF authentication and the DKIM authentication.
As an aside, this particular  sender has a high enough reputation that Gmail is offering me an unsubscribe option in their interface.
Gmail is distinguishing between first party and third party signatures in authentication. If the mail is authenticated, but the authentication appears to be handled by a separate entity, then Gmail is alerting recipients to that fact.
What does this mean for bulk senders?
For senders that are signing with a domain that matches their From: domain, there is no change. Recipients will not see any mention of your ESP in the headers.
However, if you are using an ESP that is signing your mail with a domain they own, then your recipients will see that information displayed in the email interface. If you don’t want this to be displayed by Gmail, then you will need to move to first party signing. Talk to your ESP about this. If they’re unsure of how to manage it, you can point them to DKIM Core for an Email Service Provider.
Gmail blogpost about the changes
Gmail help page about authentication results

Read More

SPF records: not really all that important

I’ve been working through some Hotmail issues with a client over the last few months. One of the things that has become clear to me is how little Hotmail actually does with SPF records. In fact, Hotmail completely ignored my client’s SPF record and continued to deliver email into the inbox.
This isn’t just a sender that had a “well, we think most of our email will come from these IPs but aren’t telling you to throw away email that doesn’t” record. In fact, this client specifically said “if email doesn’t come from this /28 range of email addresses, then it is unauthorized and should be thrown away.” The email was being sent from an IP outside of the range listed in the SPF record.
As part of the process involved in fixing the delivery problems, I had the client update their SPF record and then I enrolled their domain in the SenderID program at Hotmail. This didn’t have any effect, though. Hotmail is still not checking SPF for this client. When I asked Hotmail what was going on they said, “We do not do lookups on every sender’s mail.”
So, there you have it folks. The last bastion of SPF/SenderID has abandoned the technology. Even a totally invalid SPF record doesn’t matter, mail can still reach the inbox at Hotmail.

Read More