Friday the 13th came for Outlook, and a lot of people in Hong Kong found themselves staring at an uncooperative inbox.
We use Microsoft 365 with Exchange Online for our primary domain. Rather than wait for Microsoft's status page to turn green, we set up a parallel mail service with Google Workspace. In our case, we had email flowing both ways again in about 15–20 minutes.
That was our experience, not a promise that every setup will take 15 minutes. DNS changes, account setup and email authentication can take longer. But you don't need a large enterprise budget to have a backup plan.
Think of it as Li's Field (李氏力場) for your inbox: a little protection when the storm rolls in, except this time it's DNS doing the heavy lifting.
Check Microsoft 365 service health
What are we actually switching?
Your email address stays the same. What changes is where new incoming messages are delivered.
Your domain has an MX record, which tells other mail servers where to deliver mail for your domain. Think of it as the forwarding address on your office door. Normally, ours points to Microsoft. During an outage, we can change the sign so new mail heads to Google instead.
This does not copy your existing Outlook inbox, calendar or contacts into Google. Messages received during the switch live in the Google inbox unless you later migrate them. You may need to check both inboxes while the change takes effect and again when you switch back.
Before you start
You'll need:
- Administrator access to Microsoft 365 and to your domain's DNS settings. DNS might be managed at Cloudflare, your registrar or another provider.
- A Google Workspace account with your domain available to add, plus enough user licences for the mailboxes you need. Google offers a 14-day free trial for up to 10 users. Check the billing terms: a paid subscription can begin when the trial ends, or sooner if you add more users.
- A list of important addresses, including aliases, shared mailboxes and groups, so you can arrange equivalents in Google where needed.
Before changing anything, record your existing MX records, their priorities and TTL values. A screenshot is handy; a copy of the actual values is better. You'll need them when Microsoft is ready to take over again.
TTL, or time to live, tells DNS resolvers how long they can remember a record before checking it again. If your DNS provider allows it, set the TTL on the existing MX records to 1 minute (60 seconds) ahead of the switch. Use the same TTL for the Google MX record when you add it. A shorter TTL can help senders pick up a later change sooner.
Lowering the TTL doesn't erase copies that are already cached. Ideally, make the change in advance and allow at least the previous TTL to pass before switching mail. Some providers have a higher minimum, and some senders may take longer to notice the change, so one minute isn't a delivery guarantee.
Don't remove your Microsoft MX records or change their destination or priority before the Google side is ready. Otherwise, you risk sending mail towards a service that isn't ready to receive it. If DNS settings are unfamiliar, ask your IT administrator to help: this change affects the whole domain, not just one person's inbox.
Step 1: Prepare Google Workspace
- Add your existing email domain to Google Workspace and follow Google's instructions to verify ownership, usually by adding a TXT record in DNS. This verification record does not need to replace your Microsoft MX record.
- Create the Google user accounts for the addresses you need, and set up any essential aliases and groups. Make sure each person can sign in to Gmail with their new work account. A successful login alone does not prove that incoming mail is ready.
- Activate Gmail for the domain. In our setup, we could choose Skip Google MX setup and leave Microsoft as the primary mail destination while preparing Google.
If you don't see that option or aren't sure Gmail is ready, check with Google or your IT adviser before switching live mail.
See Google's guidance on skipping MX setup and setting up Google Workspace MX records.
Step 2: Prepare outgoing mail authentication
Getting mail into Google is only half the job. You also want replies sent from your domain to reach people rather than land in spam.
SPF is a DNS record that lists services allowed to send email for your domain. Keep one SPF record for the domain and update the existing one to include Google as well as Microsoft. Keep any other legitimate senders, such as your website or mailing platform. For a domain that sends only through Microsoft 365 and Google Workspace, Google's example is:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
That's an example, not a replacement to paste over every existing SPF record. Your current policy and other senders matter. Don't create a second SPF record: multiple SPF records can cause authentication errors.
DKIM adds a signature to outgoing mail. In the Google Admin console, generate the DKIM record for your domain, add the supplied TXT record to DNS, then start authentication in Google. Google's selector can coexist with Microsoft's existing DKIM selectors; don't remove Microsoft's records.
Check your existing DMARC policy too. It tells receiving servers what to do when messages fail authentication. Test that mail from Google passes the appropriate checks for your domain rather than changing the policy blindly.
One important timing catch: Google says a new Workspace organisation may need to wait 24–72 hours after turning on Gmail before it can generate a DKIM key. DNS and authentication changes can also take time to settle. If you're setting this up during an outage, don't assume every outgoing message will be trusted immediately. Preparing and testing this section in advance makes the emergency switch much easier.
Google's guides cover SPF, DKIM and DMARC.
Step 3: Add the backup MX record
With Google prepared, add its MX record to your domain's DNS. For illustration, the records might look like this:
Priority Destination
0 yourdomain-com.mail.protection.outlook.com
10 smtp.google.com
Replace the Microsoft destination with the one already configured for your domain. Google's current MX destination is smtp.google.com. Use the host format your DNS provider expects, and follow Google's instructions for your account.
The lower number is tried first: here, Microsoft remains primary and Google is the backup. In our case, some incoming bank emails reached the Google inbox while Outlook was timing out.
Don't rely on that as guaranteed automatic failover. Sending servers can respond differently depending on how Microsoft fails, and a Microsoft server may still accept a message even when someone can't access Outlook. Mail can therefore land in either system, be delayed or be retried later. Adding a second provider's MX record can also split delivery, so monitor both inboxes.
Step 4: Flip the switch and test
When you're ready to direct new mail to Google, change the priorities so Google has the lower number:
Priority Destination
10 smtp.google.com
20 yourdomain-com.mail.protection.outlook.com
Save the changes and check the published MX records using a DNS lookup tool, such as Google Admin Toolbox Dig. Then send a test message from an external address to each essential mailbox and send a reply back from Google. Check spam folders and, where possible, the receiving message's authentication results.
In our case, mail started flowing within about 15–20 minutes. Your mileage may vary: senders can have the old DNS information cached, and queued mail may be retried later. A quick update at your DNS provider doesn't mean every sender on the internet sees it immediately. Keep checking both Microsoft and Google until you're satisfied that messages are arriving.
Step 5: Flip the switch back
Once Microsoft confirms the service is back and you've tested access, change the MX priorities so Microsoft has the lower number again. For example, set Microsoft to 0 and Google to 10 or 20. You can also restore the Microsoft priorities you saved earlier, as long as they are lower than Google's. Check the published records and send another external test message.
Keep monitoring both inboxes during the transition. Messages that arrived in Google don't automatically appear in Outlook, and some senders may still have the previous DNS settings cached. Decide whether to migrate the Google messages back before closing the temporary service. If you won't keep Google as a backup, remove its MX record only after Microsoft is working and you've checked the transition.
If you can, keeping Google ready may be worthwhile for a future outage. But having both MX records does not guarantee automatic failover, and some mail may still go to Google while Microsoft is working. Keep checking both inboxes and review the cost and setup with your IT adviser. A backup plan is most useful when it's tested before the next Friday the 13th.
Need a hand setting this up or guidance on keeping your business email running? Tell us what is getting in the way.