How to Set Up Microsoft 365 and Intune DNS Records: Complete MSP Guide

Overview

Setting up DNS records for Microsoft 365 is one of the most routine tasks in MSP work. You've probably done it dozens of times. But the record requirements have evolved over the years — DKIM became essential, DMARC went from optional to expected, and some legacy records like Skype for Business SRV entries are still technically recommended by Microsoft even though Teams has largely replaced Skype.

This guide is a single reference you can come back to every time you onboard a new client domain to M365. No fluff, just the records, the values, and the reasoning behind each one.

What You'll Need Before Starting

• Admin access to the client's DNS registrar or hosting provider
• The Microsoft 365 tenant domain (usually yourdomain.onmicrosoft.com)
• Domain verified in the Microsoft 365 admin center (Admin > Settings > Domains)
• Access to the Exchange admin center and Microsoft 365 Defender portal for DKIM configuration

Required Records at a Glance

Here's the complete set of DNS records for a standard Microsoft 365 deployment:

The sections below walk through each record in detail.

MX Records for Exchange Online

The MX record tells the internet where to deliver email for your client's domain. For Microsoft 365, all mail routes through Exchange Online Protection (EOP).

The Record

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

How to Determine the Value

The MX endpoint follows a predictable pattern: take the domain, replace dots with hyphens, and append .mail.protection.outlook.com. For example:

You can also find the exact value in the Microsoft 365 admin center under Settings > Domains > [your domain] > DNS records.

Priority and TTL

• Priority: Set to 0 (highest priority). If you're migrating from another mail provider and want to do a gradual cutover, you can temporarily keep the old MX record with a higher priority number while testing. For a deeper look at how MX priority works, see our guide on What Is an MX Record?.
• TTL: 3600 seconds (1 hour) is standard. During migration, you may want to lower this to 300 (5 minutes) beforehand so the switch propagates faster, then raise it back afterward.

Important Notes

• Remove any old MX records pointing to previous mail providers once the migration is complete. Leaving stale MX records can cause intermittent delivery issues.
• If the client uses a third-party email filtering service (Mimecast, Proofpoint, Barracuda, etc.), the MX record points to the filter, not directly to Microsoft. The filter then routes to Exchange Online. Don't override this if a filter is in place.

Autodiscover CNAME

Autodiscover is how Outlook clients automatically find mailbox settings — server names, ports, authentication methods — without the user configuring anything manually.

The Record

autodiscover.yourdomain.com.    3600    IN    CNAME    autodiscover.outlook.com.

Why It Matters

Without Autodiscover, Outlook users have to manually enter server settings. This works, but it creates support tickets when users set up Outlook on a new device or when something changes. With the CNAME in place, Outlook handles it automatically.

Verification

dig CNAME autodiscover.yourdomain.com
# Should return: autodiscover.outlook.com.

nslookup -type=CNAME autodiscover.yourdomain.com
# Should return: autodiscover.outlook.com

SPF Record for Microsoft 365

SPF tells receiving mail servers that Microsoft's infrastructure is authorized to send email on behalf of your client's domain.

The Record

yourdomain.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com -all"

Combining with Other Senders

Most clients don't only send email through Microsoft 365. They might also use a CRM, helpdesk, marketing platform, or transactional email service. All of those need to be included in the same SPF record — you can only have one SPF TXT record per domain.

# Microsoft 365 + HubSpot + Mailgun
yourdomain.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com include:spf.hubspot.com include:mailgun.org -all"

# Microsoft 365 + Salesforce + SendGrid
yourdomain.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:sendgrid.net -all"

# Microsoft 365 + ConnectWise (on-prem mail relay)
yourdomain.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.50 -all"

The 10-Lookup Limit

SPF has a hard limit of 10 DNS lookups. Each include: counts as at least one lookup, and nested includes count too. Microsoft's include:spf.protection.outlook.com typically uses 2 lookups on its own. For a full breakdown of SPF syntax and mechanics, see our guide on What Is an SPF Record?.

If you're running into the limit:

• Audit the record — remove any services the client no longer uses
• Use ip4: or ip6: entries for static IPs instead of include: (these don't count toward the limit)
• Consider an SPF flattening service if you genuinely need more than 10 includes

-all vs ~all

• -all (hard fail): Reject email from unauthorized senders. Recommended for production domains.
• ~all (soft fail): Mark as suspicious but still deliver. Useful during initial setup and testing.

Start with ~all while configuring, switch to -all once you've confirmed everything works.

DKIM Setup for Microsoft 365

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails, letting recipients verify the message wasn't altered in transit and genuinely came from your domain. For a deeper dive into how DKIM works, see our guide on What Is a DKIM Record?.

The Records

Microsoft 365 uses two CNAME records for DKIM — a primary and a backup for key rotation:

selector1._domainkey.yourdomain.com.    3600    IN    CNAME    selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com.

selector2._domainkey.yourdomain.com.    3600    IN    CNAME    selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com.

How to Find Your Exact CNAME Values

The CNAME targets are specific to your tenant. To find them:

1. Go to the Microsoft 365 Defender portal (security.microsoft.com)
2. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings
3. Select the DKIM tab
4. Click on the domain you're configuring
5. Microsoft will show you the exact two CNAME records to create

Enabling DKIM Signing

After creating the DNS records, you need to enable DKIM signing in the Defender portal. The DNS records alone don't activate it — they just make the public keys available. You have to flip the toggle in the portal for Microsoft to actually start signing outbound mail.

It can take a few minutes after creating the DNS records for Microsoft to detect them. If enabling fails, wait 15-30 minutes and try again.

Why Two Selectors?

Microsoft uses two selectors so it can rotate keys without downtime. When it's time to rotate, Microsoft publishes a new key under the inactive selector, then switches signing to it. The old key stays available long enough for cached DNS entries to expire. This all happens automatically — you don't need to manage the rotation.

DMARC Record

DMARC ties SPF and DKIM together and tells receiving mail servers what to do when a message fails both checks. It also gives you reporting so you can see who's sending email as your client's domain. For a full explanation of DMARC policies and alignment, see our guide on What Is a DMARC Record?.

The Record

_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com;"

DMARC Policies Explained

Recommended Rollout

1. Start with p=none and set up a rua address to receive aggregate reports
2. Review reports for 2-4 weeks — identify any legitimate services failing SPF/DKIM
3. Fix any gaps (add missing SPF includes, enable DKIM for additional services)
4. Move to p=quarantine once you're confident
5. Move to p=reject when you're ready for full enforcement

A Practical Starting Point

# Monitoring only — start here
_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;"

# Quarantine with reporting — move here after review
_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100;"

# Full reject — final state
_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100;"

If you or your client uses a DMARC monitoring service (like Valimail, dmarcian, or EasyDMARC), point the rua address to that service instead for more readable reports.

Teams and Skype for Business SRV Records

Microsoft still recommends creating SRV records for SIP federation and Teams interoperability, even though Skype for Business Online was retired. These records support federation with external organizations and some legacy integrations.

The Records

_sip._tls.yourdomain.com.           3600    IN    SRV    100 1 443    sipdir.online.lync.com.
_sipfederationtls._tcp.yourdomain.com.    3600    IN    SRV    100 1 5061   sipfed.online.lync.com.

SRV Record Breakdown

Are These Still Necessary?

Practically speaking, most Teams-only environments work fine without them. But Microsoft still lists them as recommended, and they're needed if:

• The organization federates with external Skype for Business users
• Third-party SIP devices or integrations are in use
• You want to be thorough and avoid any edge-case issues

They're low-effort to add, so it's generally worth including them.

MDM CNAME Records

If the client uses Microsoft Intune for mobile device management, two CNAME records enable automatic device registration and enrollment. These two records serve different purposes, and the distinction matters.

The Records

enterpriseregistration.yourdomain.com.    3600    IN    CNAME    enterpriseregistration.windows.net.
enterpriseenrollment.yourdomain.com.      3600    IN    CNAME    enterpriseenrollment.manage.microsoft.com.

What's the Difference?

These are often confused because the names are similar, but they handle two separate processes:

enterpriseregistration handles device registration with Entra ID. When a user joins a device to the organization (either Azure AD Join or Workplace Join), this CNAME tells the device where to register. This is the foundation for conditional access policies, device compliance checks, and single sign-on. It applies to Windows, iOS, and Android devices.

enterpriseenrollment handles Intune MDM auto-enrollment. When a user signs into a personal device with their work account, this CNAME allows the device to automatically enroll in Intune for management — receiving configuration profiles, compliance policies, and app deployments. This primarily applies to Windows devices using auto-enrollment.

Do You Need Both?

In most cases, yes:

• Entra ID Join without Intune — You need enterpriseregistration only. The device registers with Entra ID but isn't managed by Intune.
• Intune MDM enrollment — You need both. A device must register with Entra ID (enterpriseregistration) before it can enroll in Intune (enterpriseenrollment).
• BYOD scenarios — enterpriseenrollment is particularly important here. It enables auto-enrollment when users add their work account on a personal device.

If the client doesn't use Intune or Entra ID device management today, it's still a good idea to create both records. It avoids a return trip to the DNS registrar when they eventually enable it.

Verifying Your Configuration

Once all records are in place, verify each one.

Using dig (macOS/Linux)

# MX Record
dig MX yourdomain.com +short
# Expected: 0 yourdomain-com.mail.protection.outlook.com.

# Autodiscover CNAME
dig CNAME autodiscover.yourdomain.com +short
# Expected: autodiscover.outlook.com.

# SPF (TXT record)
dig TXT yourdomain.com +short | grep spf
# Expected: "v=spf1 include:spf.protection.outlook.com -all"

# DKIM CNAMEs
dig CNAME selector1._domainkey.yourdomain.com +short
dig CNAME selector2._domainkey.yourdomain.com +short

# DMARC
dig TXT _dmarc.yourdomain.com +short
# Expected: "v=DMARC1; p=quarantine; ..."

# SRV Records
dig SRV _sip._tls.yourdomain.com +short
dig SRV _sipfederationtls._tcp.yourdomain.com +short

# MDM CNAMEs
dig CNAME enterpriseregistration.yourdomain.com +short
dig CNAME enterpriseenrollment.yourdomain.com +short

Using nslookup (Windows)

nslookup -type=MX yourdomain.com
nslookup -type=CNAME autodiscover.yourdomain.com
nslookup -type=TXT yourdomain.com
nslookup -type=CNAME selector1._domainkey.yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com
nslookup -type=SRV _sip._tls.yourdomain.com
nslookup -type=CNAME enterpriseregistration.yourdomain.com

Online Tools

• Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) — Tests Autodiscover, mail flow, and other M365 connectivity
• MXToolbox (mxtoolbox.com) — Quick MX, SPF, DKIM, and DMARC lookups
• Google Admin Toolbox Dig (toolbox.googleapps.com/apps/dig) — Web-based dig for any record type

Microsoft 365 Admin Center

The M365 admin center itself checks your DNS records under Settings > Domains. After adding all records, click Check DNS and Microsoft will flag anything missing or misconfigured. This is the most reliable check since it validates against what Microsoft actually expects for your tenant.

Common Mistakes

These are the issues that come up most often when configuring M365 DNS. None of them are catastrophic — they're just easy to overlook.

Multiple SPF Records

A domain can only have one SPF TXT record. If a previous provider's SPF record is still present, you'll end up with two, and SPF validation will fail for both. Merge all senders into a single record.

# Wrong — two separate SPF records
yourdomain.com.    TXT    "v=spf1 include:spf.protection.outlook.com -all"
yourdomain.com.    TXT    "v=spf1 include:_spf.google.com -all"

# Right — combined into one
yourdomain.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Forgetting to Enable DKIM in the Defender Portal

Creating the two DKIM CNAME records is only half the job. You also need to enable signing in the Microsoft 365 Defender portal. Without this step, Microsoft won't sign outbound mail even though the DNS records exist.

You can also enable DKIM signing via PowerShell using Microsoft Graph:

# Connect to Exchange Online
Connect-ExchangeOnline

# Enable DKIM signing for the domain
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true

# Verify it's enabled
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Domain,Enabled,Status

This is particularly useful when onboarding multiple client domains at once — you can script DKIM enablement across tenants rather than clicking through the Defender portal for each one.

Stale MX Records After Migration

After migrating to Exchange Online, old MX records pointing to the previous mail server should be removed. If they're left in place with a lower priority number (higher priority), some mail may still route to the old server.

Using ~all Indefinitely in SPF

Starting with a soft fail (~all) during testing is fine. But leaving it permanently means unauthorized senders get through with only a "suspicious" flag rather than being rejected. Move to -all once you've confirmed all legitimate senders are covered.

Incorrect DKIM CNAME Targets

The DKIM CNAME values are long and tenant-specific. A single character difference will break DKIM signing. Always copy the values directly from the Microsoft 365 Defender portal rather than typing them manually or adapting from another tenant.

Skipping DMARC

SPF and DKIM without DMARC means you have no policy enforcement and no visibility into who's sending email as your client's domain. Even a p=none DMARC record with reporting gives you valuable data.

Frequently Asked Questions

How long does it take for DNS changes to propagate?

Most records propagate within 15-60 minutes, but it can take up to 48 hours depending on TTL settings and DNS caching. If you lowered the TTL before making changes, propagation is faster.

Can I set up Microsoft 365 DNS records before migrating email?

Yes. You can add Autodiscover, SPF (with ~all), DKIM, DMARC, SRV, and MDM records ahead of time. Just hold off on changing the MX record until you're ready to switch mail flow.

What if the client uses a third-party email filter?

If the client uses Mimecast, Proofpoint, Barracuda, or a similar service, the MX record points to the filter, not directly to Microsoft. The filter handles routing to Exchange Online. The SPF record may also need to include the filter's sending IPs. Check the filter provider's documentation for their specific DNS requirements.

Do I need the SRV records if we only use Teams?

Microsoft still recommends them, but in practice, Teams-only environments generally work without them. They're primarily needed for federation with external Skype for Business users and some SIP integrations. They're quick to add, so it's usually not worth skipping them.

What if the domain has existing DNS records from another email provider?

Remove or update records that conflict. Specifically: replace the old MX record, merge SPF includes into one record, and remove any old DKIM records that point to the previous provider's keys. Leave unrelated records (A, CNAME for website, etc.) as they are.

How do I handle multiple domains in the same M365 tenant?

Each domain needs its own complete set of DNS records. The DKIM CNAME values will differ per domain (the domain name is embedded in the CNAME target), but the MX pattern, SPF include, Autodiscover CNAME, SRV records, and MDM CNAMEs follow the same structure.

Get Started with Unified DNS

Setting up M365 DNS for one domain is straightforward. Setting it up for 50 client domains across different registrars is where it gets tedious. Unified DNS lets you view, modify, audit, and backup DNS records across Cloudflare, Porkbun, NameSilo, NameCheap, and more — from one dashboard. See SPF, DKIM, and DMARC status at a glance across your entire client portfolio.

Unified DNS is live — try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or contact us for a walkthrough.