Microsoft 365 and Cloudflare: Email DNS Setup Checklist

Quick answer: what records do you need?

A basic Microsoft 365 + Cloudflare email setup usually needs these records:

Important: Do not guess the Microsoft MX, verification, or DKIM values. Use the exact values shown in your Microsoft 365 admin center, Microsoft Defender portal, or Microsoft-provided instructions.

Before you start: confirm Cloudflare is the active DNS host

Before adding Microsoft 365 records, confirm where live DNS is managed.

Cloudflare only controls your live DNS if your domain's nameservers point to Cloudflare.

Example

You bought the domain at Namecheap. Then you changed the nameservers to Cloudflare. Then your website was connected to Vercel. Now you want Microsoft 365 email.

In this setup, the correct place to add MX, SPF, DKIM, DMARC, autodiscover, and verification records is Cloudflare, not Namecheap and not Vercel.

A very common mistake is adding Microsoft 365 DNS records at the registrar while the active nameservers point to Cloudflare. The records look correct in the registrar, but Microsoft 365 and public DNS checks still cannot find them.

Do not change website records unless the website is the problem

Microsoft 365 email setup usually requires MX, TXT, and CNAME records.

Your website usually depends on A, AAAA, or CNAME records.

If your website is already working, do not delete or replace the website records while fixing email. A website can work perfectly while Microsoft 365 email is broken because website DNS and email DNS are separate.

Cloudflare proxy setting: what matters for Microsoft 365 email?

Cloudflare has an orange-cloud proxy setting for some DNS records. For email DNS, this is a common source of confusion.

MX and TXT records are DNS-only. You do not orange-cloud MX records, SPF TXT records, DMARC TXT records, or Microsoft verification TXT records.

For Microsoft 365 DKIM CNAME records, keep them DNS-only as well.

If a CNAME is used for Microsoft 365 email authentication or service discovery, do not proxy it unless Microsoft specifically instructs otherwise.

Step 1: Add and verify your domain in Microsoft 365

Before Microsoft 365 can fully use your custom domain, Microsoft needs to verify that you own it.

Microsoft usually asks you to add a TXT record. The value often looks like this:

MS=msXXXXXXXX

Do not copy this example. Use the exact value shown in your Microsoft 365 admin center.

Add Microsoft verification TXT in Cloudflare

Then return to Microsoft 365 admin center and verify the domain.

Common verification mistakes

The verification TXT record proves ownership. It does not route email by itself.

Step 2: Create users and mailboxes before changing MX

Before routing email to Microsoft 365, make sure the recipients exist.

For example, if you want to receive email at:

hello@example.com

then hello@example.com must exist inside Microsoft 365 as one of these:

• A licensed user mailbox
• An alias
• A shared mailbox
• A Microsoft 365 group
• A distribution list
• Another configured recipient

MX records tell the internet where to deliver email. They do not create mailboxes. If you change MX records before creating users or aliases, new incoming mail may reach Microsoft 365 but still bounce because the recipient does not exist.

Basic pre-MX checklist

• The domain is added in Microsoft 365.
• The domain is verified.
• Users are created.
• Required mailboxes are licensed.
• Aliases are created.
• Shared mailboxes or groups are configured.
• You know which email provider should receive new mail after the switch.

Step 3: Add the Microsoft 365 MX record in Cloudflare

MX records control incoming mail.

If someone sends email to:

hello@example.com

the sender's mail server checks the MX record for:

example.com

For Microsoft 365, the MX target is domain-specific and is shown in your Microsoft 365 admin center. It usually has this structure:

<domain-key>.mail.protection.outlook.com

Example only:

example-com.mail.protection.outlook.com

Do not guess your exact value. Copy it from Microsoft 365.

Add Microsoft 365 MX in Cloudflare

If you use Microsoft 365 for receiving email, the active MX record should point to Microsoft. Old MX records from your previous email provider should usually be removed when you are ready to route mail to Microsoft.

Step 4: Remove old MX records from previous email providers

Old MX records are one of the most common causes of broken Microsoft 365 email.

Previous providers may include:

• Google Workspace
• Zoho Mail
• Proton Mail
• Fastmail
• Namecheap Private Email
• cPanel hosting email
• Old web host email
• Email forwarding services

If Microsoft 365 should receive email, old MX records can cause mail to route to the wrong provider.

Wrong mixed setup:

example.com MX example-com.mail.protection.outlook.com
example.com MX ASPMX.L.GOOGLE.COM
example.com MX mail.oldhost.com

Cleaner Microsoft 365 setup:

example.com MX example-com.mail.protection.outlook.com

Use your real Microsoft-provided MX target, not the example.

During a migration, timing matters. Do not delete access to the old email provider until you are sure old mail has been migrated or retained as needed.

Step 5: Add the Outlook autodiscover CNAME

Autodiscover helps Outlook and Exchange clients find mailbox settings automatically.

For Microsoft 365, the common autodiscover CNAME is:

autodiscover.outlook.com

Add autodiscover in Cloudflare

Without autodiscover, email may still flow, but Outlook setup can become annoying or unreliable. Outlook may not add the mailbox automatically, mobile Outlook may ask for manual settings, or users may see repeated login prompts.

Autodiscover is not the same as MX. MX routes incoming mail. Autodiscover helps mail clients discover the service.

Step 6: Add SPF for Microsoft 365

SPF helps receiving mail systems check whether Microsoft 365 is allowed to send email for your domain.

If Microsoft 365 is your only sending service, the common SPF record is:

v=spf1 include:spf.protection.outlook.com -all

Only one SPF record should exist for a domain. Do not add a new SPF record if one already exists. Instead, merge Microsoft's include into the existing SPF record.

Avoid duplicate SPF records

This is wrong:

v=spf1 include:spf.protection.outlook.com -all
v=spf1 include:_spf.google.com ~all

That creates duplicate SPF records, which can cause SPF evaluation errors.

Correct merged example if both Microsoft 365 and Google genuinely send email for the same domain:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all

Only include Google if Google really still sends email for that domain. If you fully moved from Google Workspace to Microsoft 365, you may not need the Google include anymore.

SPF when you use Microsoft 365 plus other senders

Many businesses use Microsoft 365 for mailbox email, but also send email from other platforms.

Examples:

• Website contact forms
• CRMs
• Email marketing tools
• Ecommerce platforms
• Helpdesk systems
• Invoicing tools
• Booking systems
• Transactional email providers
• Cold email tools
• Support platforms

If those services send email using your domain, they may require SPF, DKIM, or both.

Practical SPF process:

1. List every service that sends email from your domain.
2. Start with Microsoft 365 SPF.
3. Add only legitimate third-party sending services.
4. Keep everything in one SPF record.
5. Remove old providers you no longer use.
6. Avoid +all.
7. Watch the SPF DNS lookup limit if the record becomes long.

Example combined SPF:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

Do not copy this exact example unless that third-party sender is actually used by your domain.

Step 7: Set up DKIM for Microsoft 365 in Cloudflare

DKIM lets Microsoft 365 sign outgoing messages from your domain. This is important for email authentication, deliverability, and DMARC alignment.

For Microsoft 365 custom domains, DKIM uses two CNAME records:

selector1._domainkey
selector2._domainkey

The targets are generated by Microsoft. They may look like Microsoft-managed DKIM hostnames, but you should not construct them manually.

Add Microsoft 365 DKIM CNAME records in Cloudflare

For Microsoft 365 DKIM: use CNAME records, not TXT records; add both selector records; keep both CNAMEs DNS-only in Cloudflare; and use the exact values from Microsoft Defender portal, Microsoft 365 instructions, or Exchange Online PowerShell.

Do not include the full domain in the Cloudflare Name field if Cloudflare already appends it.

Correct Cloudflare name:

selector1._domainkey

Usually wrong in Cloudflare:

selector1._domainkey.example.com

The second version can accidentally become selector1._domainkey.example.com.example.com depending on the DNS provider.

Where to get Microsoft 365 DKIM values

Get DKIM values from Microsoft, not from a generic blog post.

You can usually find them in:

• Microsoft Defender portal
• Email authentication settings
• DKIM tab
• Your custom domain details
• Publish CNAMEs section

Advanced users may also retrieve them through Exchange Online PowerShell.

The values are domain-specific and tenant-specific.

Microsoft DKIM targets can vary by tenant and current Microsoft infrastructure. Some older-looking examples may point toward an onmicrosoft.com hostname. Newer Microsoft-generated targets may use Microsoft DKIM infrastructure hostnames.

The rule is simple: Use the exact selector CNAME values Microsoft gives you for your domain.

Step 8: Enable DKIM signing in Microsoft 365

Adding the CNAME records in Cloudflare is not always the final step.

After DNS has propagated, go back to Microsoft and enable DKIM signing for the custom domain.

DKIM setup flow

1. Add the custom domain in Microsoft 365.
2. Confirm the domain is verified.
3. Open DKIM settings in Microsoft Defender.
4. Copy the selector 1 and selector 2 CNAME values.
5. Add both CNAME records in Cloudflare.
6. Keep both DNS-only.
7. Wait for DNS propagation.
8. Return to Microsoft Defender.
9. Enable DKIM signing for the custom domain.
10. Send a test email and inspect authentication results.

Common DKIM problems

Step 9: Add a basic DMARC record

DMARC tells receiving mail servers what to do when email claiming to be from your domain fails authentication checks.

A safe starting DMARC record is:

v=DMARC1; p=none;

The full record becomes:

_dmarc.example.com

Do not place the DMARC record at @.

When should Microsoft 365 domains use stricter DMARC?

DMARC has three common policy levels:

A sensible rollout is:

p=none -> p=quarantine -> p=reject

Do not jump straight to p=reject if you are unsure about all legitimate senders.

This is especially important if your domain sends from Microsoft 365, website forms, CRM platforms, newsletter tools, ecommerce platforms, helpdesk tools, invoicing tools, booking systems, or transactional email services.

Step 10: Check optional Microsoft 365 service records

This guide focuses on email DNS.

Microsoft 365 may show additional DNS records for other services, such as Teams, Intune, Skype for Business, or mobile device management.

Examples may include additional CNAME records, SRV records, or service-specific DNS records.

Do not blindly add every optional record unless your organization uses that service.

For basic Microsoft 365 email, the most important records are usually:

• TXT verification
• MX
• SPF TXT
• Autodiscover CNAME
• DKIM CNAMEs
• DMARC TXT

If Microsoft 365 admin center shows additional required records for services you use, follow the exact values Microsoft provides.

Example Cloudflare DNS table for Microsoft 365 email

A clean basic Microsoft 365 email setup in Cloudflare may look like this:

Your Cloudflare DNS table may also contain website records such as A, AAAA, or CNAME records. That is normal.

Do not delete working website records just because they are not part of Microsoft 365 email.

Step 11: Test incoming email

After DNS changes, test receiving email. Send an email from an external mailbox to your Microsoft 365 address.

Example:

hello@example.com

Use an outside sender, such as a personal Gmail, Outlook, Yahoo, or another external account.

Check:

• Does the message arrive?
• Does it bounce?
• Does it land in junk?
• Does the sender receive an error?
• Is only one address affected?
• Is the entire domain affected?

If only one address fails

• User mailbox exists
• Alias exists
• Shared mailbox exists
• Group exists
• License is active
• Recipient is not blocked
• Mail flow rules are not redirecting it

If the whole domain fails

• MX record
• Old MX records
• Microsoft domain verification
• Cloudflare active DNS status
• Whether DNS was changed in the wrong account
• Whether mailboxes were created before the MX switch

Step 12: Test outgoing email

Send an email from Microsoft 365 to an external mailbox.

Check:

• Does it arrive?
• Does it land in inbox or spam?
• Does SPF pass?
• Does DKIM pass?
• Does DMARC pass?
• Does the visible From domain match the domain being authenticated?

For a proper Microsoft 365 setup, outgoing mail should eventually pass SPF and DKIM, with DMARC passing through aligned SPF or aligned DKIM.

Troubleshooting: Microsoft says domain verification failed

If Microsoft cannot verify your domain, check:

1. Is Cloudflare the active DNS host?
2. Did you add the TXT record in the correct Cloudflare zone?
3. Is the Name field correct?
4. Did you copy the full MS=ms... value?
5. Did you add extra spaces?
6. Did you accidentally add the record to a subdomain?
7. Has enough time passed for DNS propagation?
8. Are you trying to verify the correct domain in Microsoft 365?

A verification TXT record in the wrong DNS provider will not work.

Troubleshooting: Microsoft says MX is missing

If Microsoft says MX is missing, check:

1. Is Cloudflare the active DNS host?
2. Did you add the MX record at @?
3. Did you copy the Microsoft-provided <domain-key>.mail.protection.outlook.com value?
4. Is the priority correct?
5. Are old MX records still present?
6. Did you add the record to the wrong domain?
7. Has DNS propagation completed?
8. Did you accidentally add the MX under a subdomain instead of the root?

A correct-looking MX record in the wrong DNS zone will still fail.

Troubleshooting: Microsoft 365 receives no email

If incoming mail does not arrive, check:

• MX points to Microsoft 365
• Old MX records are removed or lower priority only during a controlled migration
• Domain is verified in Microsoft 365
• Mailbox exists
• User has a license
• Alias exists if using an alias
• Shared mailbox or group is configured correctly
• Mail is not going to junk
• Sender is not receiving a bounce
• Cloudflare is the active DNS host

If the sender gets a bounce, read the bounce message carefully. It often says whether the problem is recipient not found, domain not found, or delivery rejected.

Troubleshooting: Outlook cannot connect automatically

If mail flows but Outlook setup is difficult, check autodiscover.

The CNAME should be:

autodiscover

pointing to:

autodiscover.outlook.com

Troubleshooting: SPF duplicate record warning

If an SPF checker says your SPF is duplicated, check all TXT records at the root domain.

Look for TXT records that start with:

v=spf1

There should be only one.

Wrong:

v=spf1 include:spf.protection.outlook.com -all
v=spf1 include:_spf.google.com ~all

Correct if both senders are truly used:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all

But if Google no longer sends email for the domain, remove the Google include.

Troubleshooting: SPF does not include Microsoft 365

If Microsoft 365 sends email for your domain, SPF should include:

include:spf.protection.outlook.com

For Microsoft 365-only sending, the record is commonly:

v=spf1 include:spf.protection.outlook.com -all

Do not edit SPF blindly if your domain uses third-party senders. First list all legitimate senders.

Troubleshooting: DKIM is missing or CNAMEMissing

If Microsoft reports DKIM as missing or CNAMEMissing, check:

1. Did you add both selector CNAME records?
2. Are they CNAME records, not TXT records?
3. Are they published in Cloudflare?
4. Are they DNS-only?
5. Did you copy the exact targets from Microsoft?
6. Did you enter selector1._domainkey and selector2._domainkey correctly?
7. Did Cloudflare append the domain automatically?
8. Did you wait for propagation?
9. Did you enable DKIM signing after adding records?

Common DKIM mistake

Wrong when Cloudflare expects only the host label:

selector1._domainkey.example.com

Correct Cloudflare Name field:

selector1._domainkey
selector2._domainkey

Troubleshooting: DMARC is missing

If DMARC is missing, add a TXT record at:

_dmarc

with content:

v=DMARC1; p=none;

Do not add DMARC at @.

Wrong location:

example.com

Correct location:

_dmarc.example.com

Should you use p=reject immediately?

Usually no. Start with v=DMARC1; p=none;, then confirm SPF, DKIM, Microsoft 365 sending, and third-party senders before moving to stricter policies.

Troubleshooting: website broke after adding Microsoft 365

Microsoft 365 email DNS should not normally break your website.

If your website stopped working after the email setup, you may have accidentally changed website records.

Check:

• Root A record
• Root AAAA record
• www CNAME
• Website host CNAME
• Website verification records
• Cloudflare proxy status for website records
• Whether nameservers changed
• Whether someone removed records that looked unused

Email records and website records perform different jobs. Adding MX, SPF, DKIM, DMARC, and autodiscover should not require deleting website records.

Troubleshooting: email broke after moving to Cloudflare

This is common.

When you move a domain to Cloudflare, you must copy all important DNS records into Cloudflare. If only website records were copied, the website may work but email may fail.

Make sure Cloudflare contains:

• Microsoft verification TXT
• Microsoft MX record
• SPF TXT record
• Autodiscover CNAME
• DKIM selector CNAME records
• DMARC TXT record
• Any other required Microsoft 365 records
• Any required website records

If email worked before Cloudflare and stopped after Cloudflare, missing MX/TXT/CNAME email records are likely.

Migration checklist: moving from Google Workspace to Microsoft 365

Before switching MX

1. Add the domain to Microsoft 365.
2. Verify the domain.
3. Create users and mailboxes.
4. Create aliases and groups.
5. Plan email migration.
6. Confirm old mail access.
7. Add Microsoft SPF carefully.
8. Prepare DKIM records.
9. Prepare DMARC with monitoring.
10. Decide when to switch MX.

During MX switch

1. Add Microsoft 365 MX record.
2. Remove or lower priority of Google MX records.
3. Confirm new mail arrives in Microsoft 365.
4. Test all important addresses.
5. Test sending.
6. Check SPF, DKIM, and DMARC.

After migration

1. Remove old Google SPF include if Google no longer sends.
2. Remove old Google DKIM if no longer needed.
3. Keep old records only if a service still depends on them.
4. Monitor bounces and spam placement.
5. Tighten DMARC later after testing.

Do not remove Google access too early if old messages still need to be migrated or exported.

Migration checklist: moving from cPanel or web host email to Microsoft 365

In this case, the website may still need the old A record pointing to the web host, but email should move to Microsoft 365 MX.

Do not delete the website A record just because you are no longer using the web host for email.

Instead:

1. Keep website A/CNAME records if the website still uses the host.
2. Change MX to Microsoft 365.
3. Remove old cPanel MX records when ready.
4. Add Microsoft SPF.
5. Add Microsoft DKIM.
6. Add DMARC.
7. Test sending and receiving.

Website hosting and email hosting can be separate.

Safe Microsoft 365 + Cloudflare setup order

Use this order for a clean setup:

1. Confirm Cloudflare is the active DNS host.
2. Add the domain in Microsoft 365.
3. Add Microsoft verification TXT in Cloudflare.
4. Verify the domain in Microsoft 365.
5. Create users, mailboxes, aliases, groups, or shared mailboxes.
6. Add Microsoft 365 MX record.
7. Remove old MX records when ready.
8. Add autodiscover CNAME.
9. Add or update SPF.
10. Make sure there is only one SPF record.
11. Add Microsoft DKIM selector CNAME records.
12. Enable DKIM signing in Microsoft 365.
13. Add DMARC at _dmarc.
14. Test receiving.
15. Test sending.
16. Inspect authentication results.
17. Confirm website still works.

This order reduces the risk of routing email to Microsoft before recipients exist.

What not to do

Avoid these mistakes:

• Do not add DNS records at the registrar if Cloudflare is the active DNS host.
• Do not delete website A/CNAME records while setting up email.
• Do not keep old MX records unless you know why.
• Do not mix Google, Zoho, cPanel, and Microsoft MX records casually.
• Do not create multiple SPF records.
• Do not guess Microsoft DKIM targets.
• Do not use TXT records for Microsoft 365 DKIM selectors.
• Do not proxy Microsoft 365 DKIM CNAME records.
• Do not add DMARC at @.
• Do not start with p=reject unless all legitimate senders are authenticated.
• Do not assume MX records create mailboxes.
• Do not keep changing DNS every few minutes before propagation.

Final Microsoft 365 + Cloudflare checklist

Use this final checklist:

• Cloudflare nameservers are active.
• Domain is added in Microsoft 365.
• Microsoft verification TXT record is published.
• Domain is verified in Microsoft 365.
• Users and mailboxes exist.
• Aliases, groups, or shared mailboxes exist if needed.
• Microsoft 365 MX record is published.
• Old MX records are removed or intentionally deprioritized.
• Autodiscover CNAME points to autodiscover.outlook.com.
• SPF includes spf.protection.outlook.com.
• There is only one SPF record.
• Third-party senders are included only if needed.
• DKIM selector1 CNAME exists.
• DKIM selector2 CNAME exists.
• DKIM CNAMEs are DNS-only.
• DKIM signing is enabled in Microsoft 365.
• DMARC exists at _dmarc.
• DMARC starts with p=none if unsure.
• Receiving email is tested.
• Sending email is tested.
• SPF, DKIM, and DMARC results are checked.
• Website records are still intact.

Run a Microsoft 365 email DNS check

Use Domain Email Doctor to scan your domain's public DNS records before changing anything.

A scan can help confirm whether Cloudflare is publishing the right Microsoft 365 MX, SPF, DKIM, DMARC, and autodiscover records.

Start with the records that affect email. Do not guess and accidentally break website DNS that is already working.