How to set up DNS records for Microsoft 365?

Sajjad
DNS
10 Oct, 2026

To set up DNS records for Microsoft 365, add your domain in the Microsoft 365 admin centre and create the records it lists at your DNS provider: a TXT record starting with MS= to verify ownership, an MX record pointing to your tenant's Exchange Online host (such as example-com.mail.protection.outlook.com), a CNAME for autodiscover pointing to autodiscover.outlook.com, an SPF TXT record containing include:spf.protection.outlook.com, two DKIM CNAME records for selector1._domainkey and selector2._domainkey, and a DMARC record at _dmarc. Optional CNAMEs for device enrolment are only needed if you use Intune.

The admin centre shows the exact values for your tenant, and it's important to copy them from there, because some are unique to your organisation. This guide explains each record, what it does, how to enable DKIM (which the admin centre's wizard doesn't fully cover), how to verify everything with dig and PowerShell, and how to fix the most common setup problems.

The Records at a Glance

For a domain example.com on a tenant whose initial domain is contoso.onmicrosoft.com, the records look like this:

Purpose	Type	Name	Value
Verification	`TXT`	`@`	`MS=ms12345678`
Mail delivery	`MX`	`@`	`example-com.mail.protection.outlook.com` (priority 0)
Outlook client setup	`CNAME`	`autodiscover`	`autodiscover.outlook.com`
SPF	`TXT`	`@`	`v=spf1 include:spf.protection.outlook.com -all`
DKIM key 1	`CNAME`	`selector1._domainkey`	value from Defender portal
DKIM key 2	`CNAME`	`selector2._domainkey`	value from Defender portal
DMARC	`TXT`	`_dmarc`	`v=DMARC1; p=none; rua=mailto:dmarc@example.com`

In zone file form:

$ORIGIN example.com.

@                     3600  IN  TXT    "MS=ms12345678"
@                     3600  IN  MX     0 example-com.mail.protection.outlook.com.
autodiscover          3600  IN  CNAME  autodiscover.outlook.com.
@                     3600  IN  TXT    "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey  3600  IN  CNAME  selector1-example-com._domainkey.contoso.onmicrosoft.com.
selector2._domainkey  3600  IN  CNAME  selector2-example-com._domainkey.contoso.onmicrosoft.com.
_dmarc                3600  IN  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Treat contoso and ms12345678 as placeholders. Microsoft has changed the format of some of these values over time, so your admin centre is the source of truth.

Before You Start

You'll need:

Global Administrator (or Domain Name Administrator) access to the Microsoft 365 admin centre at admin.microsoft.com.
Access to your DNS provider.
A record of your current email setup, in particular any existing MX and SPF records.

Check where your DNS is hosted and what mail records already exist:

dig +short example.com NS
dig +short example.com MX
dig +short example.com TXT

On Windows:

Resolve-DnsName example.com -Type NS
Resolve-DnsName example.com -Type MX

Microsoft can configure DNS automatically for some providers through Domain Connect. If your provider supports it, the admin centre offers to sign you in and add the records for you. That works well, but you should still verify the result afterwards and handle DKIM separately.

Step 1: Add and Verify the Domain

In the admin centre, go to Settings → Domains → Add domain, enter example.com, and choose to verify with a TXT record. You'll see something like:

TXT name:  @
TXT value: MS=ms12345678
TTL:       3600

Add it as a new TXT record at the root of your domain. Don't replace any existing TXT records. Then check it's visible:

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

"MS=ms12345678"

Click Verify in the admin centre. Once verified, the record isn't strictly needed, but it does no harm to leave it.

Step 2: Add the MX Record

The MX record sends incoming mail to Exchange Online Protection. Its target is based on your domain name, with dots replaced by hyphens:

Type:     MX
Name:     @
Value:    example-com.mail.protection.outlook.com
Priority: 0
TTL:      3600

Microsoft has been introducing a newer MX format under the mx.microsoft domain, which supports DNSSEC and DANE for inbound mail. Depending on your tenant and when the domain was added, the admin centre may give you a target ending in mx.microsoft instead. Use whichever value the admin centre displays.

If some dashboards don't accept a priority of 0, use the lowest value allowed, such as 1 or 10.

Remove Old MX Records

Delete any MX records for your previous email provider. If you leave them in place with a lower priority number, senders will keep delivering to the old system. If you're migrating mailboxes, plan the MX change for after mailboxes exist in Exchange Online, and lower the old MX record's TTL a day in advance so the switch takes effect quickly.

Check the result:

dig example.com MX +noall +answer

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

Step 3: Add the Autodiscover CNAME

Outlook uses Autodiscover to find mailbox settings automatically when someone adds their account:

Type:  CNAME
Name:  autodiscover
Value: autodiscover.outlook.com
TTL:   3600

Without it, Outlook may fail to set up accounts or keep asking for a password. If your old provider used an _autodiscover._tcp SRV record or an A record for autodiscover, remove it so Outlook doesn't find the wrong server first.

dig +short autodiscover.example.com

autodiscover.outlook.com.
autod.ha-autod.office.com.
...

The chain of CNAMEs that follows is managed by Microsoft and may change. What matters is that the first hop is autodiscover.outlook.com.

Step 4: Add SPF

For a domain that sends mail only through Microsoft 365:

Type:  TXT
Name:  @
Value: v=spf1 include:spf.protection.outlook.com -all

If you also send through other services, such as a newsletter platform or a CRM, merge them into one record:

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

A domain must have only one v=spf1 record. A second one causes SPF to fail for everything. Also keep an eye on the 10 DNS lookup limit when combining several includes.

Step 5: Enable DKIM

DKIM is the step most people miss. Microsoft 365 signs outgoing mail with a key for your onmicrosoft.com domain by default, which doesn't align with your custom domain for DMARC. To sign with your own domain, you publish two CNAME records and then turn DKIM on.

Get the CNAME Values

The values are specific to your tenant. You can find them in the Microsoft Defender portal under Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select your domain to see the two CNAME records.

Alternatively, use Exchange Online PowerShell:

Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
Connect-ExchangeOnline -UserPrincipalName admin@example.com

Get-DkimSigningConfig -Identity example.com |
    Format-List Name, Enabled, Status, Selector1CNAME, Selector2CNAME

If the command reports that no configuration exists for the domain, create one first, without enabling it:

New-DkimSigningConfig -DomainName example.com -Enabled $false
Get-DkimSigningConfig -Identity example.com | Format-List Selector1CNAME, Selector2CNAME

The output gives you the targets:

Selector1CNAME : selector1-example-com._domainkey.contoso.onmicrosoft.com
Selector2CNAME : selector2-example-com._domainkey.contoso.onmicrosoft.com

Newer tenants may see a different target format. Copy the values exactly as shown.

Publish the CNAMEs

Type:  CNAME
Name:  selector1._domainkey
Value: selector1-example-com._domainkey.contoso.onmicrosoft.com

Type:  CNAME
Name:  selector2._domainkey
Value: selector2-example-com._domainkey.contoso.onmicrosoft.com

Microsoft uses two selectors so it can rotate keys: one is active while the other is prepared. Both must be published.

Check them:

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

If you use Cloudflare, make sure these CNAMEs are set to DNS only, not proxied.

Turn DKIM On

Once the records resolve, enable signing in the Defender portal by toggling Sign messages for this domain with DKIM signatures, or with PowerShell:

Set-DkimSigningConfig -Identity example.com -Enabled $true

If you get an error saying the CNAME records don't exist, wait a few minutes for your DNS provider to publish them and try again.

Step 6: Add DMARC

Start in monitoring mode:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Watch the aggregate reports for a few weeks, then move to p=quarantine and finally p=reject once all legitimate mail passes. Microsoft's own inbound filtering, along with Google and Yahoo, take DMARC into account when deciding where to deliver your messages.

Check it:

dig +short _dmarc.example.com TXT

Optional Records

Intune and Device Enrolment

If you use Intune to manage Windows devices, the admin centre may list two more CNAMEs:

enterpriseregistration  3600  IN  CNAME  enterpriseregistration.windows.net.
enterpriseenrollment    3600  IN  CNAME  enterpriseenrollment-s.manage.microsoft.com.

These let users enrol devices with their work email address. If you don't use Intune or device registration, you can skip them.

Teams and Skype for Business Records

Older guides list SRV records such as _sip._tls and _sipfederationtls._tcp, plus CNAMEs for sip and lyncdiscover. These were for Skype for Business Online, which has been retired. Most Teams-only tenants don't need them. Add them only if the admin centre specifically shows them as required for your domain.

Verifying Everything

The admin centre has a built-in check: go to Settings → Domains, select your domain, and look at the DNS records tab. It flags missing or incorrect records.

You can also check from the command line. This PowerShell snippet works on Windows:

$domain = "example.com"

Resolve-DnsName $domain -Type MX | Select-Object NameExchange, Preference
Resolve-DnsName "autodiscover.$domain" -Type CNAME | Select-Object -First 1 Name, NameHost
Resolve-DnsName $domain -Type TXT | Where-Object { $_.Strings -match 'v=spf1|^MS=' } |
    Select-Object -ExpandProperty Strings
Resolve-DnsName "selector1._domainkey.$domain" -Type CNAME | Select-Object -First 1 NameHost
Resolve-DnsName "selector2._domainkey.$domain" -Type CNAME | Select-Object -First 1 NameHost
Resolve-DnsName "_dmarc.$domain" -Type TXT | Select-Object -ExpandProperty Strings

And the equivalent on macOS or Linux:

d=example.com
dig +short $d MX
dig +short autodiscover.$d CNAME
dig +short $d TXT | grep -E 'v=spf1|MS='
dig +short selector1._domainkey.$d CNAME
dig +short selector2._domainkey.$d CNAME
dig +short _dmarc.$d TXT

Finally, send a message from Outlook to an external account and check the headers. In Gmail, Show original should show SPF, DKIM and DMARC all as PASS, with DKIM aligned to example.com.

Common Problems

The Admin Centre Says the MX Record Is Wrong

Check for typos in the hyphenated target, extra MX records from an old provider, or a dashboard that appended your domain (...outlook.com.example.com). Query the authoritative server to see exactly what's published:

dig @$(dig +short example.com NS | head -1) example.com MX +short

Outlook Keeps Prompting for a Password

Usually a missing or wrong Autodiscover record, or a leftover SRV or A record for autodiscover from a previous host.

DKIM Can't Be Enabled

The CNAMEs aren't resolving yet, are proxied through a CDN, or have the full domain doubled in the name. Check with dig that selector1._domainkey.example.com returns the target you copied.

Mail From a Third-Party App Fails DMARC

Apps that send as your domain, such as a CRM, invoicing tool or website contact form, need their own SPF include and DKIM setup. DMARC reports will show which sources are failing.

FAQ: Microsoft 365 DNS

No. You can keep your current DNS provider and just add the records Microsoft lists. Changing nameservers to Microsoft is only an option for some setups and isn't required.

Microsoft recommends priority 0. If your DNS provider doesn't allow 0, use the lowest value it accepts, and make sure no other MX records with a lower number remain.

The CNAMEs point to keys that Microsoft hosts and rotates for you. Using two selectors lets Microsoft change keys without you having to update your DNS.

Not for receiving mail at the same addresses, because a domain's MX records can only send mail to one system in practice. You can use subdomains for different providers, or route mail through one system and forward to the other.

Usually not. Skype for Business Online has been retired, and most Teams-only tenants don't need those records. Add them only if the admin centre lists them as required for your domain.

Most records are picked up within an hour. MX changes can take longer to reach everyone if the old MX records had a long TTL, so lower it in advance if you're migrating from another provider.

Conclusion

Microsoft 365 needs a handful of DNS records: an MS= verification TXT, an MX record for Exchange Online, an Autodiscover CNAME, a merged SPF record, two DKIM CNAMEs and a DMARC record. Copy each value from the admin centre or the Defender portal rather than from examples, because MX and DKIM targets are specific to your tenant.

The two steps people most often miss are removing the old provider's MX records and actually turning DKIM on after publishing the CNAMEs. Verify the records with dig or Resolve-DnsName, check the admin centre's DNS status page, and review a test message's headers to confirm SPF, DKIM and DMARC all pass before tightening your DMARC policy.