← Back to Learning Hub

Email Delivery • Intermediate • 5 min read

DNS Setup for Microsoft 365: Email, Autodiscover, and Auth

Microsoft 365 DNS done right: the MX record, Autodiscover CNAME, SPF include for Exchange Online, the two DKIM selector CNAMEs, and the Teams SIP records.

Setting up email for Microsoft 365 means publishing a specific set of DNS records so Exchange Online can receive your mail, so Outlook can configure itself automatically, and so receivers can trust that messages really came from you. The core set is one MX record, one Autodiscover CNAME, an SPF TXT record, and two DKIM CNAMEs, plus the Teams and Skype for Business service records if you use them. Several of these values are unique to your tenant, so you cannot copy them blindly. Here is the complete picture with exact formats and verification steps.

Where the values come from

When you add a custom domain in the Microsoft 365 admin center, Microsoft shows you the exact records to publish. The MX host and the DKIM CNAME targets contain your tenant name (the yourdomain-com.mail.protection.outlook.com and .onmicrosoft.com fragments), so always read them from the admin center rather than guessing. The SPF include, the Autodiscover target, and the Teams records are the same for every tenant and are listed below.

Step 0: verify the domain

Before Microsoft will let you route mail to a custom domain, it asks you to prove you own it by publishing a verification TXT record. Microsoft generates a unique token for your tenant, and you add it at the root of your domain. It has no effect on mail flow and can be left in place or removed once verification succeeds.

TypeHost/NameValue
TXT@MS=msXXXXXXXX (your unique token from the admin center)

Some registrars support an alternate MX-based verification instead, but the TXT method is the most portable and the one Microsoft shows by default. Confirm it before clicking Verify so the check does not fail on a record that has not propagated yet:

$ dig TXT example.com +short
"MS=ms12345678"

The MX record

The MX record routes inbound mail to Exchange Online. Microsoft 365 uses a single MX record whose host is built from your domain name with dots replaced by hyphens.

TypeHost/NamePriorityValue
MX@0yourdomain-com.mail.protection.outlook.com

Replace yourdomain-com with your real domain, so example.com becomes example-com.mail.protection.outlook.com. Use priority 0 and delete every MX record from any previous mail provider, because a leftover record will steal mail away from Microsoft. Confirm the record resolves:

$ dig MX example.com +short
0 example-com.mail.protection.outlook.com.

The Autodiscover CNAME

Autodiscover lets Outlook and mobile clients find the right Exchange server and configure an account from just an email address and password. It is a single CNAME.

TypeHost/NameValue
CNAMEautodiscoverautodiscover.outlook.com

This target is identical for all tenants. Verify it:

$ dig CNAME autodiscover.example.com +short
autodiscover.outlook.com.

SPF for Exchange Online

SPF is a single TXT record at the root of your domain that lists which servers may send mail as your domain. For Exchange Online the include does the work.

TypeHost/NameValue
TXT@v=spf1 include:spf.protection.outlook.com -all

Two rules keep SPF valid. A domain may publish only one SPF record, so if you also send through a newsletter tool or a CRM, merge every source into this one record rather than adding a second. SPF is also capped at 10 DNS lookups, and chaining many includes will cause a permanent error. If you are still testing other senders, use ~all (softfail) and switch to -all (hardfail) once you are confident everything legitimate is covered.

DKIM: the two selector CNAMEs

DKIM signs every outgoing message so receivers can verify it was not altered in transit. Microsoft 365 publishes DKIM as two CNAME records rather than a long TXT value, which neatly sidesteps the 255-character TXT limit. The targets are generated per tenant.

TypeHost/NameValue
CNAMEselector1._domainkeyselector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
CNAMEselector2._domainkeyselector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Publish both CNAMEs first, then go to the Microsoft 365 Defender portal, open the DKIM settings for the domain, and switch signing to Enabled. Microsoft rotates between the two selectors over time, which is why both must exist. Verify one of them:

$ dig CNAME selector1._domainkey.example.com +short
selector1-example-com._domainkey.yourtenant.onmicrosoft.com.

Teams and Skype for Business records

If your organization uses Teams with the Skype for Business federation features, add these four records. They are the same for every tenant. Plenty of email-only tenants skip them with no ill effect, so only add them if you need federation.

TypeHost/NameValue / TargetPort / Weight
CNAMEsipsipdir.online.lync.comn/a
CNAMElyncdiscoverwebdir.online.lync.comn/a
SRV_sip._tlssipdir.online.lync.comport 443, priority 100, weight 1
SRV_sipfederationtls._tcpsipfed.online.lync.comport 5061, priority 100, weight 1

A quick note on the older MSOID record: Microsoft once recommended an msoid CNAME for sign-in services, but that record is deprecated and no longer required for new setups. If a legacy tenant still has it, leaving it in place does no harm, but you do not need to create it today.

Add DMARC on top

MX, SPF, and DKIM get mail flowing and signed. DMARC ties them together and tells receivers what to do when both fail, while sending you reports. Start in monitoring mode.

TypeHost/NameValue
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@example.com

Collect reports at p=none for a week or two, confirm your legitimate mail passes, then ramp the policy to quarantine and eventually reject. Verify:

$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Recommended order and a real-message check

  1. Publish MX and confirm inbound mail arrives in a test mailbox.
  2. Publish the Autodiscover CNAME and test Outlook auto-setup.
  3. Publish SPF, send a test message to an external account, and check the headers for spf=pass.
  4. Publish both DKIM CNAMEs, enable signing in the portal, and confirm dkim=pass.
  5. Publish DMARC at p=none and watch the reports.

The single best confirmation is the receiver's own verdict. Send a message from your Microsoft 365 account to an external inbox, open the original source, and look for PASS on SPF, DKIM, and DMARC. A record can look perfect in a lookup yet still fail if a selector was not enabled or an old provider record was left behind.

Verify every record across regions

Each of these records fails silently when a value is off by one character, and a local query only reflects a single resolver. After publishing, run your domain through the Valla DNS propagation checker to confirm the MX, Autodiscover, SPF, and DKIM records have gone live everywhere rather than just on your machine. When you move into enforcement, our guides on the DMARC policy ramp and on SPF qualifiers will help you tighten things without breaking delivery. Set each record from the admin center, verify it, and Microsoft 365 email becomes something you can stop thinking about.

Troubleshooting box

If results look inconsistent, compare authoritative nameservers first, then recursive resolvers by region. Capture snapshots every 10 minutes for deterministic incident timelines.

Try VallaDNS free →

Intermediate • 5 min

How to Point a Custom Domain to GitHub Pages

Apex A and AAAA records vs the www CNAME for GitHub Pages, the CNAME file, enforcing HTTPS, and why DNS propagation matters before the TLS certificate.