How to Configure DNS Records for Microsoft 365?

Adding a custom domain to Microsoft 365 means publishing a set of DNS records that tell the world your mail goes to Exchange Online, let Outlook find its settings automatically, and prove your outgoing messages are legitimate. Microsoft's admin center lists the records for you, but it doesn't explain which ones matter most, how they interact with records you already have, or how to check them. If you're coming from another mail provider, read how changing DNS affects email services first so the cutover doesn't surprise you.

This guide goes through each DNS record Microsoft 365 uses — the verification TXT, MX, autodiscover CNAME, SPF, DKIM, and DMARC, plus the optional device-management records — with the expected values, the order to add them, and PowerShell and dig commands to confirm everything is correct. For the equivalent Google setup, see how to configure DNS records for Google Workspace.

The Records at a Glance

Purpose	Type	Host / Name	Value
Domain verification	TXT	@	MS=ms12345678 (unique to your tenant)
Receive mail	MX	@	example-com.mail.protection.outlook.com, priority 0
Outlook auto-configuration	CNAME	autodiscover	autodiscover.outlook.com
Authorize senders (SPF)	TXT	@	v=spf1 include:spf.protection.outlook.com -all
DKIM selector 1	CNAME	selector1._domainkey	Tenant-specific value from Microsoft
DKIM selector 2	CNAME	selector2._domainkey	Tenant-specific value from Microsoft
Policy and reporting (DMARC)	TXT	_dmarc	v=DMARC1; p=none; rua=mailto:...

The verification code, the exact MX hostname, and the DKIM targets are specific to your tenant and domain. Copy them from the Microsoft 365 admin center or the Microsoft Defender portal rather than typing them from an example.

Step 1: Add the Domain and Verify Ownership

1. Sign in to the Microsoft 365 admin center and go to Settings, then Domains.
2. Select Add domain and enter your domain, such as example.com.
3. Microsoft checks whether your DNS host supports Domain Connect. If it does, you can sign in to the DNS host from the wizard and let Microsoft add the records automatically. Otherwise, choose to add a TXT record yourself.
4. Microsoft shows a TXT value beginning with MS=.

The record looks like this:

example.com.  3600  IN  TXT  "MS=ms12345678"

Add it at the root of the domain (Host @ or blank on most DNS providers), then select Verify. If verification fails, wait a few minutes and retry — most providers publish changes quickly, but some cache aggressively. You can check that the record is visible:

dig example.com TXT +short | grep "MS="

This TXT record can sit alongside SPF and other services' verification tokens at the same name. Unlike Google's, Microsoft's verification record can be removed after the domain is verified, though leaving it is harmless. The general pattern is explained in how to verify domain ownership with a TXT record.

Step 2: Choose Which Services to Set Up

After verification, the wizard asks how you want to connect the domain. Choose to add the DNS records yourself (or let Domain Connect do it), and select the services you use — typically Exchange and Exchange Online Protection. The wizard then lists exactly the records required for your tenant.

If you're migrating mail from another provider, you can add the verification record now and postpone the MX change until mailboxes are created and data has been migrated. The wizard lets you skip records and come back later.

Step 3: Add the MX Record

The MX record routes inbound mail to Exchange Online Protection:

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

The hostname is your domain with dots replaced by hyphens (plus other adjustments for long or unusual names), followed by .mail.protection.outlook.com. Microsoft has also begun issuing MX hostnames under a newer mx.microsoft namespace for some tenants as part of its DNSSEC and DANE support for inbound mail. Whichever form the admin center shows you is the one to use — don't construct it yourself.

Microsoft recommends priority 0 (or the highest priority your DNS host allows). Before you add it:

1. Lower the TTL of your current MX records a day in advance if you're switching providers.
2. Remove all other MX records when you add Microsoft's, unless you're deliberately running a staged coexistence with a third-party filtering service. Mixed MX records split incoming mail.

Verify:

dig example.com MX +short

Resolve-DnsName -Name example.com -Type MX

Both should show only the Microsoft hostname. For more on how MX priorities are evaluated, see what MX records are and how they work.

Step 4: Add the Autodiscover CNAME

Outlook and mobile mail apps use Autodiscover to find mailbox settings from just an email address and password. Add:

autodiscover.example.com.  3600  IN  CNAME  autodiscover.outlook.com.

Without it, users may be asked to enter server settings manually, or Outlook may keep trying to reach a stale on-premises Exchange server. If you previously ran on-premises Exchange, make sure no old autodiscover A record or SRV record (_autodiscover._tcp) still points at it.

dig autodiscover.example.com CNAME +short

Step 5: Add the SPF Record

SPF tells receivers which servers can send mail for your domain. If Microsoft 365 is your only sender:

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

Microsoft's documentation uses -all (hard fail). If you aren't yet sure every legitimate sender is listed, ~all is a safer starting point while DMARC reports confirm your setup.

As with any provider, a domain may have only one SPF record. If you also send from a marketing platform or an application server, merge them:

example.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.25 -all"

Keep total DNS lookups within the SPF limit of 10. More on SPF syntax and the lookup limit is in what an SPF record is and why it's important.

Step 6: Enable DKIM

Microsoft 365 handles DKIM differently from many providers. Instead of publishing a public key in a TXT record, you publish two CNAME records that point to keys Microsoft hosts and rotates for you. Two selectors let Microsoft rotate keys without downtime.

1. Open the Microsoft Defender portal and go to Email & collaboration, then Policies & rules, then Threat policies, then Email authentication settings, and select the DKIM tab.
2. Select your custom domain. The details pane shows the two CNAME records to create.
3. Add both CNAMEs at your DNS host.
4. Back in the portal, turn on Sign messages for this domain with DKIM signatures.

The records look like this, but the targets are tenant-specific:

selector1._domainkey.example.com.  3600  IN  CNAME  selector1-example-com._domainkey.contoso.onmicrosoft.com.
selector2._domainkey.example.com.  3600  IN  CNAME  selector2-example-com._domainkey.contoso.onmicrosoft.com.

Here contoso.onmicrosoft.com stands for your tenant's initial domain. Newer domains may be given targets in a different Microsoft-owned namespace, so copy the values exactly as the portal shows them.

You can also get the values and enable signing with Exchange Online PowerShell:

Connect-ExchangeOnline -UserPrincipalName admin@example.com

# Create the DKIM configuration if it doesn't exist yet (disabled until DNS is ready)
New-DkimSigningConfig -DomainName example.com -Enabled $false

# Show the CNAME targets you need to publish
Get-DkimSigningConfig -Identity example.com | Format-List Selector1CNAME, Selector2CNAME

# After both CNAMEs resolve, turn on signing
Set-DkimSigningConfig -Identity example.com -Enabled $true

New-DkimSigningConfig creates the signing configuration, Get-DkimSigningConfig displays the exact CNAME targets, and Set-DkimSigningConfig enables signing once DNS is in place. Enabling fails if the CNAMEs aren't resolvable yet, so check them first:

dig selector1._domainkey.example.com CNAME +short
dig selector2._domainkey.example.com CNAME +short

For how DKIM signatures are verified on the receiving side, see what a DKIM record is.

Step 7: Add a DMARC Record

DMARC isn't in Microsoft's required list for connecting a domain, but you should add it. It aligns SPF and DKIM with the visible From address, gives you aggregate reports, and is required by major mailbox providers for bulk senders. Begin in monitoring mode:

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

Once reports show your legitimate mail consistently passing, move to p=quarantine and then p=reject. Policy choice and reporting are covered in what a DMARC record is and how to set one up.

Optional Records

Device enrollment (Intune and Entra ID). If you manage devices with Microsoft Intune, two CNAMEs simplify enrollment:

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

Legacy Skype for Business and Teams records. Older guidance included SRV records for _sip._tls and _sipfederationtls._tcp and CNAMEs for sip and lyncdiscover. Most Teams-only tenants no longer need them. Add them only if the admin center's domain setup page lists them for your tenant, and copy the targets from there. The SRV format itself is explained in what an SRV record is.

Check Everything with PowerShell

This PowerShell snippet runs the core checks from a Windows machine using the built-in Resolve-DnsName cmdlet:

$domain = "example.com"

"--- MX ---"
Resolve-DnsName -Name $domain -Type MX | Select-Object NameExchange, Preference

"--- Autodiscover ---"
Resolve-DnsName -Name "autodiscover.$domain" -Type CNAME | Select-Object Name, NameHost

"--- SPF ---"
$spf = Resolve-DnsName -Name $domain -Type TXT |
  Where-Object { ($_.Strings -join "") -like "v=spf1*" }
"Found $(@($spf).Count) SPF record(s)"
$spf | ForEach-Object { $_.Strings -join "" }

"--- DKIM ---"
foreach ($sel in "selector1", "selector2") {
  Resolve-DnsName -Name "$sel._domainkey.$domain" -Type CNAME -ErrorAction SilentlyContinue |
    Select-Object Name, NameHost
}

"--- DMARC ---"
(Resolve-DnsName -Name "_dmarc.$domain" -Type TXT -ErrorAction SilentlyContinue).Strings -join ""

The script lists MX targets, confirms the autodiscover CNAME, counts SPF records (anything other than one is a problem), checks both DKIM selectors, and prints the DMARC policy. The admin center also has a domain health check under Settings, then Domains: select the domain and look at its DNS records status, which flags missing or incorrect entries.

To confirm end to end, send a message from a Microsoft 365 mailbox to an external account, view the message headers, and check the Authentication-Results header for spf=pass, dkim=pass, and dmarc=pass.

Common Mistakes

1. Constructing the MX hostname by hand. Use the exact value from the admin center; it isn't always a simple dot-to-hyphen conversion.
2. Leaving an old MX or autodiscover record. A leftover on-premises autodiscover record keeps Outlook pointed at the wrong server.
3. Adding a second SPF record instead of merging include:spf.protection.outlook.com into the existing one.
4. Publishing DKIM as TXT. Microsoft 365 DKIM uses CNAME records; a TXT record at the selector name won't work and can block the CNAME.
5. Enabling DKIM before the CNAMEs resolve. The portal or PowerShell returns an error. Wait for DNS, then enable.
6. Host field doubling. Entering selector1._domainkey.example.com in a provider that appends the domain creates a record at the wrong name.

---

Microsoft 365 DNS FAQ

Conclusion

Connecting a domain to Microsoft 365 takes a verification TXT, an MX record pointing to your tenant's Exchange Online Protection hostname, an autodiscover CNAME, a single SPF record that includes spf.protection.outlook.com, two DKIM CNAMEs, and a DMARC policy. The admin center and Defender portal give you the tenant-specific values; your job is to publish them at the right names and remove anything that conflicts.

Most problems come from what's left behind — old MX or autodiscover records, a second SPF record — or from Host field mistakes. Check each record with dig or Resolve-DnsName, enable DKIM once the CNAMEs resolve, and confirm a test message passes SPF, DKIM, and DMARC. With that done, Microsoft 365 mail will route and authenticate reliably.

Here are some useful references for Microsoft 365 DNS configuration:

1. Microsoft Learn: Add a domain to Microsoft 365 — the official walkthrough for adding and verifying a custom domain.
2. Microsoft Learn: Add DNS records to connect your domain — the full list of records for any DNS hosting provider.
3. Microsoft Learn: Set up SPF to help prevent spoofing — Microsoft's SPF guidance for Microsoft 365 domains.
4. Microsoft Learn: Set up DKIM to sign mail from your domain — enabling DKIM in the Defender portal and PowerShell.
5. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — the DMARC specification.