microsoft

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:157.55.9.128/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:157.55.9.128/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

Starting on August 16th, Microsoft seems to have stopped sending feedback loop reports. Microsoft’s FBL is called the “JMRP” (Junk Mail Reporting Program) and multiple folks are indicating that the email feed of complaint reports that this entails seems to have dried up. Microsoft has been notified but I’ve not heard of any ETA for a fix at this time. I’ll be sure to update this post if/when I receive more information.[ H/T: LB Blair and others ]

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

Here’s some long-time-coming news from Microsoft, one of the world’s largest mailbox providers: they have started rolling out changes to honor DMARC policies as published in a domain’s DNS. Microsoft will now be treating the p=reject policy as intended; email failing DMARC authentication will not be delivered. Microsoft had been treating the DMARC policies of p=quarantine and p=reject the same way; email failing DMARC with a p=reject policy was delivered to the spam folder. Microsoft said they had operated this way “because some legitimate email may fail DMARC. For example, a message might fail DMARC if it’s sent to a mailing list that then relays the message to all list participants. If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they’ll be marked as spam and not rejected.” Microsoft signaled the change to

Microsoft’s SNDS (Smart Network Data Service) reputation feedback portal is having trouble at the moment. For at least the past week, people have been reporting that attempts to register and verify new IP addresses or ranges with SNDS are failing, because the verification email is not being sent by Microsoft. A few folks have mentioned discussing the issue with Microsoft, and being told to try again — and have done so, to no avail.At first I was assuming that Microsoft’s SNDS verification request emails were bouncing off of various folks’ spam filters. But in my testing, I don’t even see any attempt by Microsoft to connect to and deliver a message to my IP range’s verification address at my self-hosted email domain. So, something is definitely and significantly broken — I’ve got no proof that the SNDS system is even attempting to send verification messages.Thus, at this time, I don’t

Florent Destors, Deliverability Manager at Marigold, recently found and shared some very good and timely information related to an increase of mailbox full (over quota) bounces that folks are seeing when sending to Microsoft domains. With his permission (thank you!), I’m sharing his info here:Florent writes:In case you noticed a drop these last weeks on your delivery rates towards Microsoft domains and see an increase in mailbox full bounces received, you should be aware that Microsoft recently changed their cloud storage calculation method.Starting February 1, 2023, cloud storage used across Microsoft 365 apps and services will now include Outlook.com attachments data and OneDrive data. This update may reduce how much cloud storage users have available to use with their OneDrive. If they reach their cloud storage quota, their ability to send and receive emails in Outlook.com will be disrupted.According to Microsoft, the new quota bar should have been gradually rolled

It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection. Why do we care? It’s good to send syntactically valid email in a warm fuzzies sort of way – it shows we know what we’re doing, and aren’t dodgy spamware – but it’s increasingly important to delivery as mailbox providers are tightening up on their syntax checks. But why are mailbox providers doing that? One reason is that authentication tech like DKIM and DMARC is built around them only being applied to email. Not to messages that kinda look like email. There are ways to bypass DKIM protections by sending invalid messages. As one example, if you send multiple copies of the From: header with different values a DKIM checker

Successful inbox delivery to Microsoft consumer mailboxes (referred to as Outlook.com, Hotmail.com, or Microsoft “OLC”) can be tricky. Any deliverability consultant will tell you that Microsoft is often the quickest to block or junk your mail, and that it is relatively common to have deliverability issues at Microsoft only, and nowhere else. You are not alone.Not only can Microsoft often be “quicker on the trigger” when it comes to blocking, but also, resolution of deliverability issues can take longer here versus other mailbox providers. It’s not always clear what triggers spam folder placement or blocking — but like with so many other mailbox providers, the best thing you can do to minimize deliverability risk is to send truly wanted mail. No purchased lists, no email appends, no ten year old lists you found in the back of a filing cabinet. Sending engaging, wanted, recognized mail, is going to be your

Microsoft recently posted that their Exchange Online servers (which I think also includes Microsoft 365/Office 365, basically any business email cloud-hosted by Microsoft) will soon block mail from old, unpatched Microsoft Exchange servers.Unlike the recent DMARC changes for Microsoft OLC, this likely has no impact to email marketing senders. Few email marketers are using years-old versions of self-hosted Microsoft Exchange for sending email messages.This does likely have a positive impact on the email ecosystem as a whole, though. Setting aside the snark of Microsoft (new, cloud) blocking Microsoft (old, on premise) servers, rejecting mail from servers that are (or could be) engaging in potentially bad acts is a good way to protect users from malware, phishing and spam, and hopefully will also nudge admins of those outdated servers to either upgrade them or shut them down, which will eliminate them as spam and phish vectors, making all of our inboxes

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