How to set up MX records for Google Workspace and Microsoft 365

Google Workspace: one record

Google's current guidance is a single MX record. The host is the domain root — entered as @, as a blank field, or as the domain itself depending on what your DNS panel asks for — with priority 1 and the value smtp.google.com.

That is the entire configuration. Every mailbox on the domain routes through it, and there is nothing tenant-specific about the value, so the same record is correct for every Workspace customer.

If your domain was set up before 2023 you will have a different set of records, with hostnames beginning aspmx. Google states plainly that these are still supported and that if your mail is working, no change is required. Any account may move to the single record, but there is no deadline and no benefit beyond having fewer records to maintain. This is a good example of a change not worth making during an incident.

The priority value on a single MX record does not affect anything, since preference only orders a choice between records. Google documents 1; google.com's own domain publishes the same host at priority 10, which is a useful reminder that the number is not load-bearing when there is only one.

; as you would enter it in a DNS panel
; Host: @ (or blank, or example.com)   Priority: 1   Value: smtp.google.com

example.com. 3600 IN MX 1 smtp.google.com.

; verified against Google's admin documentation and a live lookup, 2026-09-13

Microsoft 365: one record, with a value only you have

Microsoft also uses a single MX record, but the hostname embeds your tenant's domain key: it takes the form <domain-key>.mail.protection.outlook.com. The domain key is derived from your domain name with dots replaced by hyphens — a domain example.com typically becomes example-com — but you should not construct it from that rule. Read it from the admin centre, because the value Microsoft shows you is the one that is correct for your tenant.

To find it: Microsoft 365 admin centre, Settings, Domains, select your domain, Manage DNS, More Options, Add your own DNS records. Microsoft displays the exact record to publish there, and that display is the authoritative source.

Microsoft's own documentation is inconsistent about the priority, and it is worth knowing rather than guessing. The generic instructions say to set it to the highest available value, typically 0; the registrar-specific pages show 10 in their tables. Either works — with one MX record the preference is not compared against anything — so use whatever your admin centre displays.

On TTL, Microsoft is consistent: 3600 seconds. It also documents a hard ceiling that is easy to trip over — Exchange Online does not support TTL values of 6 hours or more, so a panel defaulting to 86400 needs changing.

; Host: @   Priority: 0 (admin centre may show 10)   TTL: 3600
; Value: <domain-key>.mail.protection.outlook.com

example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com.

; a real tenant, observed 2026-09-13:
microsoft.com. 1238 IN MX 10 microsoft-com.mail.protection.outlook.com.

The records that go with the MX record

An MX record only routes mail towards you. Three other records decide whether the mail you send is accepted by anyone else, and a migration that changes MX without changing them leaves outbound mail failing authentication from the moment the cutover completes.

• SPF. Google Workspace uses include:_spf.google.com; Microsoft 365 uses include:spf.protection.outlook.com. Add the include to your existing record — do not publish a second SPF record, which is a permanent error that removes SPF entirely. Microsoft's own documentation ends its example record in -all; that is only safe once you have confirmed the include covers every system that sends as your domain, so ~all is the safer value until you have.

• DKIM. Google publishes a TXT record at google._domainkey by default, generated in the admin console, and signing has to be switched on there separately from publishing the record. Microsoft uses two CNAMEs, selector1 and selector2, pointing into its infrastructure so it can rotate keys without you editing DNS. Microsoft changed the target format in May 2025: domains onboarded since then use a target ending in dkim.mail.microsoft, older domains keep the previous onmicrosoft.com form, and the two formats cannot coexist for one selector — so copy the values from the admin centre rather than from an article.

• DMARC, at _dmarc, which is independent of either provider and required by the large mailbox providers if you send them any volume.

There is also an autodiscover CNAME for Microsoft 365, which is a client-configuration convenience rather than a mail-routing record. Mail is delivered correctly without it; Outlook clients just have to be configured by hand.

Cutting over without losing mail

The MX change itself is one edit. The care goes into the order of operations around it, because during the window when some senders have the new record and some still have the old one, both destinations receive real mail.

• At least one full old-TTL period in advance — a day earlier if your MX records are still at 86400 — lower the MX TTL to 300 seconds and change nothing else. This is the step that makes the actual cutover short, and it does not work if you do it at the same time as the change.

• Create every mailbox on the new platform before you touch DNS. A message delivered to the new platform for an address that does not exist there is rejected, and the sender gets a bounce saying the recipient does not exist — which is worse than a delay.

• Publish the new MX record and remove the old one in the same edit. Leaving both, with the old one at a lower priority number, means it keeps being tried first and nothing has changed; leaving both with the new one first means mail still lands on the old platform whenever the new one is momentarily busy.

• Keep the old platform accepting and forwarding mail for at least a week. Sending servers that failed a delivery attempt retry for days, so a message accepted by the old system late in the window may not be delivered onward for some time after. This is the single most effective thing you can do to avoid losing mail, and it costs one more month of a subscription you were cancelling anyway.

• Send test mail from outside the organisation in both directions, and check the headers of a received message to confirm it actually arrived through the new platform rather than being forwarded by the old one.

• Raise the TTL back to an hour once you are confident, so you are not permanently paying for a short TTL you no longer need.

Verifying the change

Run an MX lookup against the domain once the short TTL has passed. Three things should be true: exactly the records you intended are present, no record from the previous provider survives, and each host actually answers on port 25.

The last of those is the one a plain DNS lookup will not tell you. A syntactically perfect MX record pointing at a host that no longer accepts connections is indistinguishable from a correct one until someone tries to send you mail, which is why our MX lookup resolves each host and opens a connection rather than only reading DNS.

Then check propagation across resolvers. Disagreement in the first few minutes is expected and is not a fault; what you are looking for is convergence within the TTL you set. Any resolver still serving the old record after that is worth investigating, because it usually means the edit did not go where you thought.

What commonly goes wrong

• Leaving the previous provider's MX record in place alongside the new one. Depending on the priorities, some or all mail continues to route to a platform nobody is monitoring, and it is silent.

• Entering the domain name in a host field that already appends the zone, producing a record at example.com.example.com. Look the record up after saving rather than trusting the form.

• Pointing the MX record at a CNAME. Both providers give you a hostname with its own address records; pointing MX at an alias is invalid and fails inconsistently across senders.

• Guessing the Microsoft domain key from the dots-to-hyphens rule instead of reading it from the admin centre. It is usually right and when it is not, all inbound mail fails.

• Cutting over before creating mailboxes, so early messages bounce as unknown recipients rather than queuing.

• Changing MX and forgetting SPF, so outbound mail from the new platform starts failing authentication at every receiver on the day of the move.

• Cancelling the old platform on the day of the cutover. Keep it receiving for a week; retries can outlive the change by days.