Gmail has long pushed for adoption of email authentication best practices from email senders, effectively making it tough to get to the inbox without proper email authentication in place. They also, for years now, have been very cautious about what mail they accept over IPv6, declining to accept mail over IPv6 that fails authentication checks. Well, now those same checks now apply to all mail sent to Gmail — over IPv4 or IPv6. Meaning, if you want to send mail to Gmail, you need to authenticate that mail with Domain Keys Identified Mail (DKIM) or Sender Policy Framework (SPF).If you’re trying to send mail to Gmail subscribers, and the mail doesn’t authenticate properly, it’ll be rejected with this error message:550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked. The sender must authenticate with at least one of SPF or
Looks like Microsoft has run into email authentication issues today. Specifically, the domain hotmail.com appears to have a broken SPF record wherein messages sent by Hotmail/Outlook.com/Microsoft OLC using a hotmail.com from address aren’t passing SPF authentication. Here’s a link to a KBXSCORE report I’ve run, showing the failure.While hotmail.com is affected, the outlook.com domain doesn’t appear troubled — my test sends from an outlook.com from address seem to pass SPF. (Microsoft has many other domains; I’ve only checked these two.)Looking at the SPF records for hotmail.com, here’s what I see:hotmail.com descriptive text “v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:126.96.36.199/25 include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com -all”outlook.com descriptive text “v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:188.8.131.52/25 include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com include:spf.protection.outlook.com ~all”The hotmail.com SPF record is missing “include:spf.protection.outlook.com” — which is present in the outlook.com SPF record. And I see it present in a cached copy of Hotmail’s SPF record that I collected last month. So, I suspect that to be
If you’re seeing intermittent DKIM authentication failures at Microsoft domains (outlook.com, hotmail.com, etc.) — meaning you’re seeing “dkim=fail (body hash did not verify)” instead of “dkim=pass (signature was verified)” in your “Authentication Results” email headers — then what likely has happened is that Microsoft has modified one or more characters in your email message.See, there’s multiple ways to encode email messages for sending them via the Internet — the oldest, default way of just plain text (7-bit ASCII text) doesn’t allow for emojis, accented characters, special character sets, Kanji, anything beyond just the simple characters used to write English-language text. And to allow email to be transmitted in this simplistic character set, but allow for additional, extended characters and alternative character sets, methods of encoding were created that allowed email platforms to do things like specify complicated multi-byte characters by “encoding” them into Quoted-Printable or Base64, to allow them to
Or, how to scare your potential new customers by doing a whole bunch of things wrong all at once, leading to the big warning box of doom. Cold leads, not sending using a full name, and not authenticating properly. Trying to be friendly and sending mail as “Bob” can backfire, especially if your employer has four other people already named Bob, Gmail can’t tell which is which, and Gmail is concerned because your DKIM configuration is busted and you didn’t configure SPF properly. Good job, Bob.This brings me back to the common question, are SPF and/or DKIM required for inbox placement? Well, the lack of them in this case sure didn’t help Bob. Don’t be like Bob. Make it easy for Gmail to identify you and authenticate your mail.
Microsoft OLC, aka “Microsoft Outlook Consumer,” aka what used to be called Hotmail, now called Outlook.com (which includes the domains hotmail.com, outlook.com, live.com, msn.com, and all the other Microsoft domains I’ve listed here), will soon respect DMARC policy on inbound mail, declining to accept unauthenticated mail from domains with a DMARC policy of “reject.” Yahoo and Gmail already reject this type of failed mail today.Current state: If an email message sent to Microsoft OLC domains failed DMARC and the DMARC domain had a policy of “reject,” Microsoft would not actually reject that email message. It would end up in the junk mail folder instead. (Even though the specification strongly suggests that this mail should be rejected.)Why this is sub-optimal: It overrode a domain owner’s publicly stated desire (via that DMARC record in DNS) to reject mail that failed DMARC checks. This meant that more bad mail was likely to get into
The other day, I ran across a complaint on Linkedin. “Just saw another email go to the Promotions Folder with DKIM, SPF, and DMARC set up perfectly. Stop telling people this will fix their e-mail problems!” It’s not the first time I’ve heard this, and I can understand why the author is frustrated. But, it’s important not to miss the true point — email authentication will help to improve inbox delivery. Because it does! But there’s a nuanced explanation to go along with that. The devil truly is in the details.Email authentication is fantastic. SPF and DKIM both allow you to set yourself up as YOU in the eyes of mailbox providers — as opposed to just being one of the many clients of ESP or CRM platform X, based on a shared IP address or shared DKIM domain. This is a good thing, but it’s just the start.Setting yourself
Rene Holt writing for We Live Security has shared a recent tale that gives me pause: What can go wrong if you get your SPF record wrong. Usually the risk here is that you make your SPF record too restrictive, resulting in the rejection of legitimate mail. But here’s an alternate case — what if your SPF record is so wide, so broad, that bad guys can easily send spam from certain IPs and pass authentication checks, successfully pretending to be you (or at least, successfully sending from your domain).I think the moral of the story is that you’ve got to get SPF right, both in how tight and how loose your SPF record should be. Don’t just blindly add a zillion IP addresses because somebody told you to; investigate and question and review.Rene Holt: How a spoofed email passed the SPF check and landed in my inbox
Another day, another ESP telling a client to publish a SPF include for the wrong domain. It shouldn’t annoy me, really. It’s mostly harmless and it’s just an extra DNS look up for most companies. Heck, we followed Mailchimp’s advice and added their include to our bare root domain and it’s not really a huge deal for companies with only a couple SaaS providers. Still, it’s an incorrect recommendation and it does cause problems for some senders who are using multiple SaaS providers and Google. Both Steve and I have written different posts about SPF over the years. In fact, the Authenticating with SPF: -all or ~all post is the most visited post on the blog. I’ve even written almost this same post, pointing out that a lot of ESPs have bad recommendations for SPF records. Steve’s written about the technical ins and outs of SPF records in DNS and…
Evan writes, “Hi Al, My email address has just been compromised and now I am receiving hundreds of System Administrator and Mail delivery failure notices sent to my inbox from all those poor people who have received unwanted spam from my address. I noticed your name on the web when I went searching to find out how and if I can stop this happening and was hoping that you might have some ideas other than changing my email address?”Hey Evan, I’m sorry to hear you’re going through that. But don’t despair, this soon will pass. In the mean time, here’s what you should do.Change your email password, just to be safe. All throughout history, it’s been pretty unlikely that the bounces coming back from spam have anything to do with sending from your actual email account and email system. Do change that password, though, just in case. If a bad guy had…
Over on the Kickbox blog, my colleague Jennifer Nespola Lantz talks about sending domains and what you need to think about if you want to share domains between multiple email provider platforms. It’s a common thing, right? You are probably using more than one service provider, CRM or automation platform. You’ve probably also got a corporate email system in the mix. Can you send from more than one platform using the same domain? And if so, should you? What are the limitations and concerns around using the same domain to send from multiple systems? Jen walks us through it.