Navigating Email Deliverability Challenges with Microsoft

On February 24, 2026, a sudden wave of user complaints revealed that emails sent to Microsoft domains like Hotmail and Outlook were being deferred, causing significant disruptions. Despite a high sending reputation and adherence to email best practices, our emails were temporarily rate-limited by Microsoft due to IP reputation issues. Initial investigations pointed to a potential problem on Microsoft's end, possibly an outage or misconfiguration, as other email providers were unaffected.

Email deliverability is vital for our operations, with around 350,000 emails sent monthly, including 39,000 transactional emails. Both our dedicated IPs faced rate limitations, prompting us to reassure users through Helpscout, which was unaffected by the issue. Despite believing the problem would resolve itself, I delved into Microsoft's email deliverability processes, discovering their hypersensitivity compared to Gmail and learning about SNDS, Microsoft's tool for checking IP reputation.

Driven by a need to address the issue, I contacted Microsoft support, providing detailed logs and evidence. During this process, I realized that spiky send traffic might have triggered the rate limit. Our weekly newsletters, sent in batches without throttling, could have appeared as suspicious spikes to Microsoft's systems.

To mitigate future risks, I developed a Redis-backed throttler to control our sending rate to Microsoft users. This tool, integrated into our infrastructure, ensures our send rate does not exceed 10 emails per minute per IP, reducing the likelihood of triggering rate limits. Meanwhile, Microsoft adjusted our IP's connection limitations, and email delivery resumed within 72 hours, preventing any permanent email loss.

Reflecting on the incident, I suspect that a perceived spike in email traffic during a newsletter batch job led to the temporary block. While similar volumes were sent in the past without issue, recent sensitivity changes or the spiky nature of the sends might have contributed. To prevent future disruptions, I plan to eventually dedicate an IP for transactional emails once volume justifies it. Despite the challenges, Sendgrid's service remains reliable, though I believe they should implement throttling at the IP level to prevent such incidents.