On October 29, 2025, Microsoft experienced a significant global outage that affected millions of users and businesses worldwide. For eight hours—from approximately 12:00 PM ET to 8:00 PM ET—core Microsoft services, including Microsoft 365, Azure, Xbox Live, and Minecraft, were largely unavailable. As a developer of Outlook add-ins that depend on Azure infrastructure, Sperry Software’s Safeguard Send for Microsoft 365 was also temporarily impacted. Here’s what happened, why it mattered, and how we’re responding.
The Root Cause: A Configuration Error at Azure Front Door
The outage was triggered by an inadvertent configuration change in Azure Front Door (AFD), Microsoft’s global content delivery and traffic routing service. Azure Front Door sits in front of hundreds of Microsoft services—think of it as a massive traffic director that routes requests to the right destination at lightning speed.
The faulty configuration caused Azure Front Door nodes across the global infrastructure to fail to load properly. As traffic was rerouted to remaining healthy nodes, those surviving nodes became overwhelmed by the sudden surge. This cascading failure created a domino effect: Microsoft 365 authentication systems went down, which in turn caused Outlook to fail, which prevented on-send add-ins like Safeguard Send from operating.
The worst part was that the Azure Portal—Microsoft’s primary tool for diagnosing and responding to infrastructure problems—was itself inaccessible because it also depends on Azure Front Door. Microsoft engineers had to work around this “bootstrap problem” by temporarily routing the portal away from AFD, buying themselves time to identify and roll back the problematic configuration.
Why Safeguard Send and Other Outlook Add-Ins Were Affected
When the outage occurred, users of Safeguard Send and other on-send add-ins began experiencing issues. Here’s the technical reason why:
Outlook add-ins like Safeguard Send are cloud-hosted services that live in Azure. When users enable an on-send add-in, Outlook maintains a connection to retrieve the add-in code from Azure infrastructure. During the outage, Outlook couldn’t reach these Azure-hosted services, so the add-in became unreachable.
By default, Outlook has a security-first design: if an on-send add-in cannot be reached, Outlook blocks email from sending. This is intentional—it prevents users from accidentally bypassing security or compliance controls because the add-in is unavailable. As a result, users saw the message “Safeguard Send is working on your request” in perpetuity, with Outlook spinning in a wait loop.
Importantly, this affected all on-send add-ins, not just Safeguard Send—including add-ins from Microsoft itself and hundreds of independent developers.
Users without add-ins installed were unaffected and could send emails normally.
What We Learned and What’s Next
1. We’re Attending the Microsoft Office Developers Meeting
On November 8, 2025, the Microsoft Office Developers community will hold their monthly meeting to discuss the outage with hundreds of add-in developers from around the world. We will participate and learn about potential improvements for future resilience.
[Nov 13, 2025 Update: Insights from the Microsoft Office Developers Meeting
At the November 8 Microsoft Office Developers meeting, dozens of frustrated add-in developers representing tens of thousands of affected users shared their experiences. The feedback was clear: the Azure Front Door outage had a cascading impact far beyond what Microsoft’s initial messaging suggested. Developers reported that even add-ins hosted outside Azure (on AWS and other providers) failed to load because core dependencies like Office.js were unreachable due to the AFD outage. Most concerning was the timeline: while Microsoft began posting status updates at 17:27 CET (5:27 PM), the outage had actually started at 09:27 AM CET (9:27 AM)—meaning users were without communication or guidance for over 8 hours.
The Microsoft Outlook specialist acknowledged the problem and confirmed the team is working on a long-term solution. Notably, even alternative technologies like Safeguard Send Core (which uses Smart Alerts designed to allow email sending if the add-in is unreachable) were also blocked during the outage, indicating the issue was at the platform level, not specific to any particular add-in architecture. One practical workaround discovered by an IT Admin was composing emails on desktop, saving them to Drafts, then sending via mobile—a hassle, but it worked. We’re adding this mobile workaround to our dashboard emergency response guidance going forward.]
2. We Recommend Configuring Outlook’s Default Send Behavior
To help protect your organization against future outages affecting on-send add-ins, we strongly recommend reviewing our article on How to Change the Default Send Behavior of Outlook When Using Safeguard Send for Microsoft 365.
By changing a simple registry key, you can configure Outlook to allow emails to send even if Safeguard Send cannot be reached. This means:
-
During an Azure outage, users can still send emails if needed
-
Compliance and security policies continue to be enforced when the add-in is available
-
Business continuity is maintained during rare infrastructure failures
Important: This setting is entirely optional and controlled by your IT department—it’s not a workaround or bypass of security controls. It’s a resilience strategy for business continuity during infrastructure failures.
3. We’re Improving Our Customer Communication
We discovered that our customer notification system relies on Outlook to send emails—the very service that was down. This created a communication bottleneck during the crisis. Going forward, we’re implementing multiple communication channels for critical alerts:
-
HubSpot CRM emails (non-Outlook-based)
- Open a support ticket in the dashboard (this was already an option)
-
Dashboard alerts (which we deployed immediately during the outage)
-
Status page updates for real-time information
This ensures that if Microsoft services are unavailable, we can still reach you quickly.
Key Takeaways for IT Administrators
If you manage Outlook add-ins in your organization, here are the key takeaways:
During the Outage:
-
Outlook instances without add-ins functioned normally (including phones)
-
Users with Safeguard Send could still send emails by temporarily uninstalling the add-in (though this required manual intervention and could take anywhere between 12-24 hours to propagate through the systems)
-
The issue was infrastructure-level, not specific to any particular add-in vendor
For Future Resilience:
-
Configure your Outlook default send behavior to allow emails to send if the add-in is unreachable
-
Test your configuration periodically to ensure it works as expected
-
Communicate contingency plans to your users so they know what to do if an outage occurs
Industry Context:
-
99.9% SLA coverage means on average, you can expect approximately 9 hours of downtime per year across all cloud services
-
Major outages are rare but not impossible
The Bottom Line
The October 29 outage was a sobering reminder that even the most robust cloud infrastructure can experience major disruptions. However, it was also a testament to the power of planning and communication.
At Sperry Software, we’re committed to helping you navigate these challenges. That’s why we’ve invested in better communication systems, why we’re actively engaging with Microsoft’s developer community, and why we recommend robust contingency planning.
Questions? We’re here to help. Reach out to our support team with any questions about configuring Outlook’s default send behavior, disaster recovery planning, or how to implement the resilience strategies discussed in this article.