Microsoft 365 domains and DNS setup

Adding a custom domain to a Microsoft 365 tenant takes a handful of DNS records. Most of them are non-negotiable for mail to flow and clients to autoconfigure. Skipping any of them tends to produce subtle problems that take longer to diagnose than to fix up front.

The required records

For a tenant using yourcompany.com as the primary domain:

Domain ownership

• TXT record at the apex: MS=ms12345678 (the value Microsoft generates during domain verification). Used only for the initial verification; you can leave it in place or remove it after verification.

Mail flow

• MX record at the apex pointing to yourcompany-com.mail.protection.outlook.com. (priority 0).
• SPF TXT record at the apex: v=spf1 include:spf.protection.outlook.com -all. Hard-fail (-all) is best practice once you've confirmed all legitimate senders are included.

Anti-spoofing

• DKIM CNAMEs:

  • selector1._domainkey.yourcompany.com → selector1-yourcompany-com._domainkey.yourcompany.onmicrosoft.com.
  • selector2._domainkey.yourcompany.com → selector2-yourcompany-com._domainkey.yourcompany.onmicrosoft.com. Then enable DKIM signing in the Defender for Office 365 portal.

• DMARC TXT record at _dmarc.yourcompany.com: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com. Start at p=none (reporting only), move to p=quarantine, then p=reject once you're confident.

Autodiscover (Outlook)

• CNAME at autodiscover.yourcompany.com → autodiscover.outlook.com.. Used by Outlook and other clients to find their mailbox server settings.

Teams (Skype legacy CNAMEs)

Two CNAMEs still relevant for Teams federation and some scenarios:

• lyncdiscover.yourcompany.com → webdir.online.lync.com.
• sip.yourcompany.com → sipdir.online.lync.com.

Two SRV records for SIP:

• _sip._tls.yourcompany.com → sipdir.online.lync.com. port 443 weight 1 priority 100.
• _sipfederationtls._tcp.yourcompany.com → sipfed.online.lync.com. port 5061 weight 1 priority 100.

(These are increasingly optional for cloud-only Teams, but federation with some external systems still uses them.)

Optional but useful

• MTA-STS policy at _mta-sts.yourcompany.com plus a policy file — enforces TLS for inbound mail.
• TLS-RPT record at _smtp._tls.yourcompany.com — reporting endpoint for TLS failures.
• BIMI record at default._bimi.yourcompany.com — shows your brand logo in supported email clients (Gmail, Apple Mail) once DMARC is p=quarantine or stricter.

DNS hosted at Microsoft

For tenants without an existing DNS provider, Microsoft can host the domain DNS for you — the records above are pre-populated automatically. For most established organisations, your existing DNS provider (Cloudflare, AWS Route 53, GoDaddy, etc.) is fine; Microsoft generates the records and you add them.

Verifying the setup

After publishing the records:

• MXToolbox or dmarcian verify SPF, DKIM, DMARC.
• The Microsoft 365 admin center verifies domain ownership.
• Outlook Autodiscover Tester (Microsoft Remote Connectivity Analyzer) verifies autodiscover.
• A test email from outside your tenant should land cleanly and pass SPF/DKIM/DMARC.

Get the DNS right once, document it, and forget about it. Get it wrong, and you'll be debugging delivery problems for months.

Why order matters during cutover

Migrating a domain's mail flow to Microsoft 365 goes wrong most often when records are published in the wrong sequence relative to actually moving mailboxes. The safe order is: verify the domain (TXT record) and publish SPF/DKIM/autodiscover before any mailbox is live on Microsoft 365 — none of those records affect where mail currently flows, so they can sit alongside an existing mail system with zero risk — and only cut the MX record once mailboxes are actually migrated and ready to receive. Cutting MX prematurely, before mailboxes exist in Microsoft 365, means mail addressed to those users has nowhere to land; cutting it too late after mailboxes have already moved means new mail keeps arriving at the old system while the new one sits empty. This is also why a hybrid or staged migration keeps MX pointed at the old system until the very last cohort has moved.

Frequently asked questions

What happens if SPF is set to a soft fail (~all) instead of a hard fail (-all)? A soft fail tells receiving servers to accept but flag messages that fail the SPF check, rather than rejecting them outright — useful as a cautious first step while confirming every legitimate sending source is actually included in the record, but it leaves a meaningful spoofing gap open indefinitely if never tightened to a hard fail once confidence is established.

Does adding these DNS records affect an existing website hosted on the same domain? No — none of the Microsoft 365 records (MX, SPF, DKIM, DMARC, autodiscover) touch the A or CNAME records that point a website's root or www subdomain to its hosting provider; they coexist on the same domain without interfering with unrelated web hosting.