Microsoft 365 MX Records Setup A Complete Step-by-Step Guide

Switching your domain's email to Microsoft 365 is straightforward in theory, but the MX record change is the single step that causes the most problems. Get it wrong and inbound mail either bounces, disappears into the old mailbox, or queues on the sending side for hours. This guide covers exactly what the correct MX record looks like, how to add it at the most common DNS hosts, how to verify the change worked, and what to watch out for when you have legacy records cluttering the zone.

What Is an MX Record and Why Does It Matter for Microsoft 365

An MX (Mail Exchanger) record is a DNS entry that tells the internet which mail server accepts email for your domain. When someone sends a message to you@yourdomain.com, the sending mail server queries DNS for your domain's MX records, then connects to the server listed there. If your MX still points to your old hosting provider while your mailboxes live in Microsoft 365, mail goes to the wrong place — full stop.

Microsoft 365 assigns every tenant a unique MX endpoint. It follows the format:

The hyphens replace dots in the domain name portion. So contoso.com becomes contoso-com.mail.protection.outlook.com. This is auto-generated; you do not choose it.

Finding Your Exact Microsoft 365 MX Value

Do not guess the MX value. Always pull it directly from the Microsoft 365 admin center to get the exact string and priority:

1. Sign in to admin.microsoft.com with a Global Administrator account.
2. Go to Settings > Domains.
3. Click your domain name.
4. Select the DNS records tab.
5. Find the row labeled MX. Note the Points to address or value column and the Priority (usually 0).

The admin center also surfaces the SPF, DKIM CNAME, and Autodiscover records you will need later. Keep this tab open while you work in your DNS host's control panel.

Required MX Record Settings

Regardless of which DNS provider you use, the fields map like this:

• Type: MX
• Host / Name: @ (or your bare domain, depending on the panel)
• Value / Points to: yourdomain-com.mail.protection.outlook.com
• Priority: 0
• TTL: 3600 (1 hour) or lower while migrating, raise to 86400 afterward

A priority of 0 is the lowest numeric value and therefore the highest preference. If you leave an old MX record with a lower priority number, mail may still route there. Delete all old MX records once Microsoft 365 mailboxes are ready to receive.

Adding the MX Record at Common DNS Hosts

GoDaddy

1. Log in, go to My Products, click DNS next to your domain.
2. Scroll to the MX section, click Add.
3. Set Host to @, Points to to your Outlook endpoint, Priority to 0, TTL to 1 Hour.
4. Save, then delete the old MX entry pointing to GoDaddy's or your previous host's mail server.

Cloudflare

1. Open the Cloudflare dashboard, select your domain, go to DNS > Records.
2. Click Add record, choose type MX.
3. Name: @, Mail server: yourdomain-com.mail.protection.outlook.com, Priority: 0, TTL: Auto.
4. Save. Remove any existing MX records for the old provider.

Important Cloudflare note: MX records must not be proxied (orange cloud). DNS-only (grey cloud) is the only correct setting for MX records. Cloudflare cannot proxy mail traffic, and an orange-clouded MX will simply not work.

Namecheap

1. Log in, go to Domain List, click Manage next to your domain.
2. Select the Advanced DNS tab.
3. Under Mail Settings, switch the dropdown from Namecheap Email Hosting (or similar) to Custom MX. This step is critical — Namecheap hides the manual MX fields until you select Custom MX.
4. Add a record: Host @, Value your Outlook endpoint, Priority 0.
5. Delete auto-generated Namecheap mail entries.

cPanel / Web Hosting Providers

1. Log in to cPanel, open Zone Editor (or Email > MX Entry on older versions).
2. Find your domain, click Manage.
3. Delete the existing MX record pointing to mail.yourdomain.com or similar.
4. Click Add Record, type MX, set the name to your domain with a trailing dot (yourdomain.com.), value to the Outlook endpoint with a trailing dot, priority 0.
5. If cPanel also controls your email routing under Email Routing, change it from Local Mail Exchanger to Remote Mail Exchanger — otherwise cPanel will intercept inbound mail before it ever leaves the server.

Route 53 (AWS)

1. Open the Route 53 console, select Hosted zones, click your domain.
2. Click Create record, choose MX as record type.
3. Leave the subdomain field empty for the root domain. Value format in Route 53 is priority hostname on one line: 0 yourdomain-com.mail.protection.outlook.com.
4. TTL: 300 seconds during migration. Save and delete old MX records.

Additional DNS Records Microsoft 365 Requires

The MX record gets mail into Microsoft 365, but without the supporting records, mail delivery will have problems in the other direction and spam filters at receiving servers will flag your outbound messages.

• SPF TXT record: v=spf1 include:spf.protection.outlook.com -all — tells receiving servers that Microsoft 365 is authorized to send for your domain. Add as a TXT record at @. Only one SPF record is allowed per domain; if you already have one, merge the include rather than adding a second record.
• DKIM CNAME records: Two CNAMEs (selector1 and selector2) enable DKIM signing. Enable DKIM in the Microsoft 365 Defender portal under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM after adding the CNAMEs.
• Autodiscover CNAME: autodiscover pointing to autodiscover.outlook.com — allows Outlook and mobile clients to configure themselves automatically.

Use the DNS Lookup tool to confirm each of these records is resolving correctly from public DNS before you consider the setup complete.

How to Verify the MX Record Is Live

DNS changes can take anywhere from a few minutes to 48 hours depending on TTL and upstream resolver caching. To check the current state without waiting:

On macOS or Linux:

The answer section should show your Outlook MX endpoint with priority 0 and no other MX records. If you still see the old host's MX, the change has not propagated yet from Google's public resolver — try a different resolver like 1.1.1.1 to get a second opinion, or wait and check again.

You can also send a test message from a Gmail or other external account to a Microsoft 365 mailbox immediately after the TTL expires on the old record. Check the message headers in the received email — look for Received: from lines; they should reference outlook.com or protection.outlook.com infrastructure, not your old mail server.

Common Mistakes and How to Fix Them

Leaving the Old MX Record in Place

This is the number one error. If your zone has both the new Outlook MX at priority 0 and the old server's MX at priority 10, some senders will correctly use priority 0. Others with broken implementations try the next record if they get a temporary failure, and mail lands on the old server. Delete every MX record except the Microsoft 365 one.

Wrong MX Value Format

Microsoft 365 MX values end in .mail.protection.outlook.com — not @outlook.com, not smtp.office365.com. The smtp.office365.com hostname is for SMTP client submission (port 587), not inbound MX routing. Using it as an MX record will cause delivery failures.

SPF Record Conflicts

If your domain has a legacy SPF record like v=spf1 include:secureserver.net -all from GoDaddy hosting, you cannot simply add a second TXT record with the Microsoft 365 SPF. Having two SPF records causes a PermError. Combine them:

Or if you send from other services too:

cPanel Intercepting Mail

Described above under the cPanel section: if the server that hosts your website also previously hosted your email, cPanel's mail routing setting needs to be changed to Remote Mail Exchanger. Otherwise the local mail server accepts mail on port 25 before the MX record even matters, and messages pile up in the server's local mail queue instead of reaching Microsoft 365.

Domain Not Verified in Microsoft 365

Before the MX record change can work, Microsoft 365 must have your domain verified. During domain setup in the admin center, Microsoft asks you to add a TXT verification record (something like MS=ms12345678). That record proves ownership. If you skipped that step or it failed, Microsoft 365 will not accept mail for your domain even if the MX points correctly.

Timing the MX Cutover During a Migration

If you are migrating existing mailboxes (IMAP migration, cutover migration, or hybrid), do not flip the MX until the primary mailbox data is copied. Mail that arrives in Microsoft 365 before the mailbox exists will bounce with a 550 error. The general sequence for a simple cutover is:

1. Verify the domain in Microsoft 365 admin.
2. Create all mailboxes and assign licenses.
3. Run the mailbox migration (IMAP or cutover) to copy historical mail.
4. Lower the MX TTL to 300 seconds and wait 24–48 hours.
5. Flip the MX to the Outlook endpoint.
6. Confirm propagation with dig or the propagation checker.
7. Configure Outlook clients using Autodiscover or manual profile setup.
8. After 24–48 hours, raise TTL to 3600 or 86400.

After the MX Change Is Confirmed

Once mail is flowing into Microsoft 365, do a final audit of your DNS zone:

• Confirm only one MX record exists and it points to the Outlook endpoint.
• Verify SPF TXT is present and contains include:spf.protection.outlook.com.
• Enable DKIM signing in the Defender portal and confirm the CNAME records resolve.
• Consider adding a DMARC TXT record at _dmarc.yourdomain.com to instruct receiving servers on how to handle SPF/DKIM failures — start with p=none while monitoring reports before moving to p=quarantine or p=reject.
• Remove the old mail-related A records (mail.yourdomain.com) if the old server is being decommissioned, to avoid confusion.

A well-configured Microsoft 365 DNS zone with a clean MX, valid SPF, active DKIM, and a DMARC policy will deliver high inbox placement rates and protect your domain from spoofing — both outcomes that matter far beyond just getting the initial setup working.