Microsoft 365 experienced a major outage today, affecting Outlook, Teams, SharePoint and other services.
Like many businesses, I spent most of the day checking Microsoft’s service-health updates and waiting for things to return to normal.
Nine hours later, I needed to access a system that required a verification code sent to my email.
Unfortunately, I could not access my mailbox.
That was when I decided I had waited long enough.
About ten minutes later, I had configured a temporary route for new incoming email around the affected Microsoft 365 environment. Then I sent a test message from an external provider.
It arrived.
Sometimes you do not need to wait for the provider
DCX uses Microsoft 365 for email, but we also have independent web-hosting infrastructure capable of receiving mail.
So I decided to use it.
I created an emergency mailbox on our web server, configured a temporary catch-all address and updated our domain’s MX records so new incoming mail would be directed to the alternative server.
Within about ten minutes, the configuration was in place. Local delivery worked, the updated DNS records were resolving correctly, and an external test message reached the emergency mailbox.
That final external test mattered. A configuration looking correct is not the same as mail actually arriving from outside your network.
This was not a fix for Microsoft’s outage. It did not restore access to messages already accepted by Exchange Online, bypass Microsoft authentication or recover anything sitting inside the affected mailbox.
It simply gave us another place to receive new messages while Microsoft 365 was unavailable.
And it made me wonder why I had spent nine hours waiting.
Your business might have options you have not considered
When a major cloud service goes down, it is easy to assume there is nothing you can do.
After all, if Microsoft’s infrastructure is having problems, what can your technology provider possibly fix?
Microsoft’s infrastructure? Nothing.
Your options around it? Potentially quite a lot.
Depending on the way your environment is set up, it may be possible to:
- create temporary independent reception for urgent incoming email;
- redirect new messages to an alternative mail service;
- provide emergency webmail access outside the affected Microsoft 365 environment;
- use pre-agreed alternative channels for critical communication; and
- return carefully to the normal configuration once services recover.
Not every outage has a sensible workaround. Any temporary mail route needs to be implemented carefully so it does not create security, privacy or delivery problems that are worse than the outage.
But sometimes the answer is simpler than you might expect.
This was a controlled workaround, not a security bypass
Changing an MX record tells sending mail systems where to deliver new messages for a domain. It does not switch every sender instantly, move existing mail or restore the Microsoft services behind Outlook.
DNS caching means different senders may see the change at different times. Messages already accepted by Microsoft remain there. Some senders may retry delivery rather than immediately following the new route.
The temporary server also needs appropriate access controls, spam and malware protection, logging, storage and a clear rollback plan. A badly configured server could become an open relay, mishandle confidential messages or create another problem during an already difficult day.
If the temporary environment is also used to send email, SPF, DKIM and DMARC need separate attention. Receiving mail somewhere new does not automatically make outgoing mail trustworthy.
This is not a recipe for changing MX records during every outage. It is an example of why understanding your existing environment matters.
A temporary solution does not have to become a major project
Technology problems can quickly turn into unnecessarily complicated projects.
New infrastructure. Expensive subscriptions. Lengthy implementation plans.
Sometimes those are justified.
Other times, the capability you need is already available. You need someone who understands how the systems connect, what can be changed safely and how to put everything back afterwards.
Our temporary route took about ten minutes to configure because we already had the infrastructure, access and technical knowledge required. We also tested external delivery before relying on it.
That does not mean every business can be switched over in ten minutes. Many cannot, and trying an improvised change without understanding DNS and mail security could cause lost or misdirected messages.
But it does demonstrate that an urgent technology problem does not always require an elaborate or expensive solution.
The real lesson is preparation
The best time to design an emergency communication route is not nine hours into an outage.
Businesses should already know:
- who controls their domain and DNS;
- which systems depend on Microsoft 365;
- how management will contact staff if email and Teams are unavailable;
- how urgent customer and supplier messages will be handled;
- which financial and identity checks must remain in place; and
- who has authority to activate and reverse a temporary arrangement.
As I wrote in Microsoft 365 Outage: How Prepared Is Your Business?, continuity should include both operational alternatives and protection against phishing and payment-redirection fraud.
A workaround created under pressure is useful. A tested plan is better.
Technical note
The temporary route described here redirected new incoming email to an independent mail server. It did not bypass Microsoft authentication or security controls, recover messages already accepted by Exchange Online, or guarantee immediate delivery from every sender.
DNS caching, sender behaviour and mail-server configuration can affect results. Local delivery, DNS resolution and external delivery were tested successfully before the route was relied upon.