At Daily Data, we’ve operated an email server for years. What began as an internal service eventually expanded to a small number of clients – many of whom chose it to avoid the operational friction of larger providers’ mail filtering, or to reduce dependence on “another party” when troubleshooting is needed.
Recently, we started seeing delivery failures to Microsoft consumer email accounts (hotmail.com, live.com, outlook.com, etc.). These changes appear to affect acceptance and delivery in ways that don’t line up well with Microsoft’s published criteria, and we occasionally see our messages blocked. [One documented example of the frustration this causes](https://www.engagor.ai/resources/blog/microsoft-s3150-most-frustrating-error-code) gives a sense of how widespread the problem is.
What happened (symptoms)
In our case, the first clear signal showed up when a user tried to reply to an email from a Hotmail account. We received a bounce message containing an S31520 error code. Our initial suspicion was that something was wrong with our outbound sending or that a user might have misused mailing-list workflows – but the issue wasn’t resolved by any of those explanations.
Over time, more users reported issues. The inability to send or receive affected multiple user domains (including dailydata.net). Replies and messages that previously worked would suddenly fail to arrive.
The “solution” we eventually found (sender-side)
This was not quick.
First incident (Dec 2025, resolved late Jan 2026):
- Microsoft initially asked for proof that we controlled the IP addresses involved (similar in spirit to proving control/ownership).
- Gathering the required proof took more than three weeks.
- When we attempted to follow Microsoft-provided links, at least one did not work (the URL returned an error in a browser), which added delay.
- After a ticket was opened, the initial response stated that we were not blocked.
- After further escalation and explanation of the actual delivery behavior, Microsoft provided a workaround: an exception added to their filtering rules that effectively bypassed their blocking behavior for our traffic. We don’t know the internal details of that exception, but it worked. By late January 2026, we were again able to communicate normally.
Second incident (May 2026):
This time, we had a better sense of what was happening:
- We ran the Microsoft tools and workflows we were instructed to use.
- The checks indicated we weren’t blacklisted, and the automated process returned the same result.
- Ultimately, we still needed a human at Microsoft to resolve the issue.
Impact on Microsoft-consumer recipients
This problem isn’t just an inconvenience for the sender.
When delivery fails:
- Recipients using Hotmail/Outlook.com accounts may receive **no clear notification** – messages simply don’t arrive.
- In at least one case, a user reported they could not receive an **invoice** from us.
- Some impacted recipients resorted to creating new Gmail accounts temporarily so they could receive our messages.
The practical bottom line: for affected senders, Microsoft consumer accounts can become effectively unreachable until the sender side is handled – often by getting Microsoft to apply an exception or manual review.
What you can do if you’re a Hotmail/Outlook.com user
If you are expecting an email that hasn’t arrived:
- Check your junk/spam folder.** Blocked mail sometimes lands there instead of bouncing.
- Ask the sender to check for bounce errors.** The error codes S3150, S3140, and S31520 are the ones to look for. If they see those, this article may help them understand what they’re dealing with.
- Use a non-Microsoft address temporarily.** Creating a free Gmail account to receive urgent messages (invoices, confirmations, etc.) is a reliable short-term workaround while the sender works on a fix.
- Know that this is not your fault.** The blocking happens on Microsoft’s side and requires the sender – or Microsoft itself – to resolve it. There is nothing a recipient can do to unblock a sender directly.
Once it starts, it can be silent
We didn’t receive any warning from Microsoft when delivery broke again. For us, once Microsoft’s mail servers started rejecting the traffic, it simply stopped.
Historical perspective
This isn’t the first time a major provider’s filtering rules have caused hard-to-remediate delivery failures for legitimate senders. A similar pattern occurred with AOL-era filtering changes around 2010, where remediation was difficult and recipients often had to switch to a different email provider to restore communication.
What’s different now is the scale and the lack of clear, consistent documentation that maps published acceptance criteria to observed behavior – at least based on our experience.
Further reading
Posted in Blog
