Most businesses run their mailboxes on Google Workspace or Microsoft 365, and both ask you to publish MX records so that mail for your domain reaches them. That makes "Google Workspace MX records" and "MX record for Office 365" two of the most common DNS searches. People want the values. This article intentionally does not print them. Providers change their mail routing, publish different values for different tenants and regions and revise setup instructions, so any list copied into an article ages quickly and, if it is out of date, breaks mail. Instead, we show where to get the correct values from your own admin console and the provider's documentation, how to enter them, how priority works across several records, how to migrate without losing mail and, importantly for anyone who also sends through a service like ours, how outbound authentication fits alongside. If you are new to the record itself, read MX records explained first.
Where to get the correct MX values
| Suite | Where to look |
|---|---|
| Google Workspace | The Admin console's domain setup instructions for your account, and Google's own Workspace Admin Help pages on setting up MX records |
| Microsoft 365 | The Microsoft 365 admin center's domain setup page, which shows the records for your specific domain, and Microsoft's documentation on adding DNS records |
Microsoft's admin center commonly generates a value that is specific to your domain, which is why you cannot reliably copy it from a blog. Google publishes its own setup values in its documentation. In both cases, use the current official page at the time you make the change, and do not rely on memory or on an old screenshot.
How to enter MX records
- Open DNS management at your authoritative host. See adding DNS records at GoDaddy, Namecheap and Cloudflare.
- Delete any previous MX records for the domain unless the provider tells you to keep them for a staged migration.
- Add each record the provider lists with the exact hostname and priority. The priority numbers decide which server is tried first; see the priority section below.
- Watch for the appended domain and trailing dot. If your panel adds your domain to what you type, do not enter a full hostname with the domain on the end unless the panel shows that it expects a trailing dot.
- Save and verify using the provider's verify button and a DNS lookup. See how to check MX records.
Priority across several records
Providers that list several MX records give each a priority. Enter them exactly as given, including equal values. Records with equal priority share the load; a higher-numbered record is a fallback. Changing the numbers because they look odd to you can alter how mail is routed. Do not add your own "backup" records to a suite unless you have a specific reason and know the consequences, because a backup host that accepts mail without checking recipients can accept spam and bounce it later.
Switching providers without losing mail
- Create the mailboxes in the new suite before changing MX, so that incoming mail has somewhere to go.
- Lower the MX record's TTL a day or two ahead if your DNS host allows it. See TTL and propagation.
- Change the records in one edit: add the new, remove the old.
- Expect a transition period. Some senders cache the old answer until the TTL runs out, so check both mailboxes for a day or so.
- Migrate old messages separately with the provider's migration tools. MX changes only affect new mail.
- Update authentication. The new suite will want its own SPF include and DKIM records. Merge them into your existing SPF record rather than adding a second one. See SPF with Google Workspace, Microsoft 365 and other senders.
Does sending through a service change your MX?
No. When you add a sending service for transactional or marketing mail, you publish authentication records, not MX records. Your mailboxes keep working as before. With our SMTP relay and email API, the steps are:
- Add your domain in the dashboard.
- Publish the DKIM records shown there.
- Add the SPF include shown there to your single SPF record, alongside the suite's include.
- Publish a DMARC record, starting in monitoring mode. See DMARC policy explained.
- Send from an address on that domain and check the headers.
Many teams send application mail from a subdomain, so reputation and records are separate from the people mailboxes on the main domain. See sending subdomain strategy. If you want replies to application mail to reach software instead of a person, give that subdomain its own MX with an inbound handler; see inbound email processing.
Common problems
| Problem | Likely cause | What to do |
|---|---|---|
| Verification in the admin console fails | Records not yet published or cached, wrong DNS host | Check the authoritative nameservers and wait for the TTL |
| Some mail still goes to the old provider | Old MX record left in place or caches | Remove stale records and wait |
| Mail bounces with a domain-not-found message | Records deleted during a DNS move | Re-add the full set at the new DNS host |
| Outgoing mail from another service lands in spam | SPF or DKIM missing for that service, not an MX issue | Authenticate the service. See authenticating your sending domain |
| SPF permerror after adding a suite | Two SPF records or too many lookups | Merge into one and count lookups |
A note on limits and policies
Mailbox suites have their own sending limits, relay options and security settings, and those change. If you are weighing a suite's built-in relay against a dedicated service for application mail, read the comparison of Google Workspace relay and a dedicated service, and check the provider's current documentation for the actual limits rather than relying on figures quoted elsewhere.
Checklist before you change MX records
- Confirm who is authoritative for your DNS and that you can edit it.
- Export or screenshot the current zone, so you can restore it.
- Confirm that mailboxes, aliases, groups and shared mailboxes exist in the new suite.
- Identify every service that sends as your domain and list its SPF and DKIM requirements.
- Plan the change for a quiet period and tell people what to expect.
- Decide who watches the old and new mailboxes during the transition.
What not to change
Do not edit the MX records of a domain just because outgoing mail from another service is failing. That is an authentication problem, and the fix is in SPF, DKIM and DMARC. Do not copy MX values from another company's domain, even if they use the same suite, because tenant-specific values will not work for you. And do not delete records you do not recognise: autodiscover, verification and service records often belong to the suite, and removing them can break mail apps or admin features.
After the change
Check delivery both ways. Send to your domain from several outside providers and confirm arrival. Send from your domain to those providers and read the authentication results in the headers; see reading email headers. Run the SPF, DKIM and DMARC checker, and review DMARC aggregate reports in the following days for senders you forgot. See reading aggregate reports. A short written record of what changed and when will save time at the next migration.
Keep your mailboxes, add a sending service Authenticate a subdomain with SPF and DKIM from the dashboard and leave your MX records untouched.
References and further reading
Frequently asked questions
What are the MX records for Google Workspace?
Use the values in your Admin console and Google's current Workspace Admin Help pages. They change, so copy them from the official source at the time you make the change.
What is the MX record for Microsoft 365?
The Microsoft 365 admin center shows the record for your domain on its domain setup page. It is specific to your domain, so use that rather than an example from a blog.
Do I need to remove my old MX records?
Yes when you switch providers, unless the provider tells you to keep some for a staged migration. Leftover records can send part of your mail to the old provider.
Does using a sending service change my MX records?
No. MX controls incoming mail. A sending service needs SPF and DKIM records, plus a DMARC policy, and your mailboxes keep working.
Why is my admin console not verifying the MX records?
Typical causes are editing the wrong DNS host, a doubled domain in the name, caching until the TTL expires or an old record that is still present.