Do I still need the sip, lyncdiscover, and the two SRV records Microsoft used to ask for?

Almost certainly not. Those four records — the CNAMEs sip and lyncdiscover and the SRV records _sip._tls and _sipfederationtls._tcp — existed for Skype for Business Online, which Microsoft retired on July 31, 2021. A modern Teams-only tenant does not need them, and Teams works fine without a single one of them in your zone. The only time they still matter is a residual Skype for Business Server hybrid setup, or federation with a partner still running Skype for Business. If that's not you, skip them entirely. Microsoft still lists them on the DNS-records page as optional for those legacy scenarios, which is why tutorials and some registrar 'add Microsoft 365 records' buttons keep publishing them — but publishing records you don't use just adds noise and, in the SRV case, failure points that confuse troubleshooting later.

I verified my domain but Outlook still isn't receiving mail. Why?

Verifying and routing are two separate jobs, and the TXT verification record does nothing for mail flow. The MS=ms... TXT record only proves to Microsoft that you own the domain so the admin center will let you add it. Mail only starts arriving in Exchange Online once your MX record points at .mail.protection.outlook.com — and only after your old provider's MX is gone. The classic 'verified but no mail' cause is a split-MX: the Microsoft 365 MX is live but the previous host's MX is still published, so sending servers deliver to whichever one they pick, and half your mail lands in a mailbox nobody opens. Delete every non-Microsoft MX, confirm only the mail.protection.outlook.com host remains, and give DNS up to 72 hours before deciding anything is broken.

Why does my DKIM CNAME point to a contoso-com address that looks mangled?

That's not mangled — it's your domain with the dots turned into hyphens, and it's the same token that appears in your MX record. Microsoft builds the DKIM target as selector1- ._domainkey. .onmicrosoft.com. So for a domain example.com on a tenant example.onmicrosoft.com, selector1._domainkey is a CNAME to selector1-example-com._domainkey.example.onmicrosoft.com, and selector2 is the same with a 2. The CNAMEs point at Microsoft-hosted records that publish the actual public keys, which is how Microsoft can rotate the keys without you ever touching DNS again. Publishing the two CNAMEs is only half the job, though — you still have to switch DKIM signing on in the Defender portal, or the records resolve and sign nothing.

Microsoft 365 Domain Setup: TXT, MX, SPF, DKIM

What You’re Setting Up

Connecting a domain to Microsoft 365 is a short list of DNS records that have to go in the right order, and the order is where a day disappears. First you prove you own the domain (a TXT record). Then you route inbound mail to Exchange Online (one MX record). Then you let the rest of the internet send as you without landing in spam (SPF and DKIM). Do them out of sequence — or add the Microsoft MX without removing your old mail host’s — and you hit the classic symptom: the admin center says the domain is healthy, and mail still goes somewhere else.

There’s also a pile of records Microsoft used to hand you that you almost certainly don’t need anymore. I’ll get to that, because publishing the wrong ones is its own way to lose an afternoon.

Step 1: Prove You Own the Domain (TXT)

Before Microsoft 365 lets you turn on mail for your domain, it needs proof you control DNS. The admin center gives you a verification value that looks like MS=ms followed by a string of digits, and you publish it as a TXT record at the domain root (host @ or blank — not www, not a subdomain).

Two things trip people here:

It’s one TXT record at the apex. You don’t need one per subdomain, and you don’t need to invent anything — paste the exact MS=ms… value the admin center shows you.
Propagation is real. After you add it, Microsoft’s checker may not see it for minutes to a couple of hours. If verification fails the first time, wait and re-check instead of adding the record twice.

Unlike the Google verification TXT, Microsoft’s MS=ms… record is only needed for the initial ownership check — once the domain is verified you can leave it or remove it without breaking anything. Leaving it costs nothing, so most people just leave it.

Step 2: Route Mail to Exchange Online (MX)

This is the step that actually delivers mail, and it’s where the real failures live. You get exactly one MX record, and its target is built from your own domain name — dots replaced by hyphens:

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

The preference number is 0 — lowest number, highest priority. A few registrars won’t let you type 0 in the preference field; use the lowest value they allow (often 1) and it behaves the same, because there’s only one MX. The exact <your-domain-key>.mail.protection.outlook.com host is shown in the admin center’s DNS list for your domain; don’t guess the token, copy it.

The split-MX trap

The single most common “Microsoft 365 isn’t receiving mail” cause isn’t a wrong Microsoft value — it’s the old value still being there. You add the Exchange Online MX, you don’t remove your previous host’s MX, and now the domain advertises two mail destinations. Every sending server on the internet gets to choose based on preference numbers and its own retry logic, and the choice isn’t stable. Some messages go to Exchange Online, some go to the old mailbox nobody logs into, and the split drifts as DNS caches expire. Worse, Exchange Online Protection can decide your domain isn’t authoritative when a competing MX is present, and start mishandling bounces. The moment the Microsoft MX is confirmed working, delete every other MX record for the domain. The only exception is a deliberately designed hybrid or third-party-gateway mail flow, and if you had one of those you wouldn’t be reading a setup guide.

Step 3: Authorize Yourself to Send (SPF, then DKIM)

Inbound is done. Now stop your outbound mail from landing in junk.

SPF is one TXT record at the root that tells receivers Microsoft’s servers may send for you:

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

The trap here is silent and fatal: a domain may publish only one SPF record. If you already have an SPF record for another service, you do not add a second v=spf1 line — two SPF records is a permerror that makes SPF fail outright. You merge: keep one record and add include:spf.protection.outlook.com inside it alongside whatever was already there.

DKIM is two CNAME records, and they look alarming the first time because the target contains your domain with the dots turned into hyphens:

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

example.onmicrosoft.com is your tenant’s original sign-up domain — substitute yours. Two selectors exist so Microsoft can rotate keys by flipping which one is active, without you ever editing DNS again. The step people forget is the last one: after the CNAMEs resolve, you still have to go into the Microsoft Defender portal and enable DKIM signing for the domain. Publishing the CNAMEs without flipping that switch signs nothing.

While you’re in the mail-auth records, publish a starter DMARC record too — _dmarc TXT, beginning at p=none with a reporting address so you can watch before you enforce:

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

Start at p=none, read the reports, and only then walk up to quarantine and reject. Jumping straight to reject before you know every system that sends as you is how people quarantine their own invoices.

Skip the Skype/SIP Records

Older Microsoft 365 setup walkthroughs — and some registrar “add Office 365 records” buttons — still publish four extra records: CNAMEs sip and lyncdiscover, and SRV records _sip._tls and _sipfederationtls._tcp. These were for Skype for Business Online, which Microsoft retired on July 31, 2021, and whose infrastructure Microsoft began decommissioning in 2022. A Teams-only tenant does not need any of them, and omitting them changes nothing about mail or Teams. The only reason to keep them is a surviving Skype for Business Server hybrid or federation with a partner who still runs Skype for Business. If that’s not your world, don’t publish them — unused SRV records are just extra things to misread when you’re debugging later.

Diagnose with DechoNet

Email Check reads your domain’s MX, SPF, and DKIM the way a receiving server does — so you can confirm the Exchange Online MX is the only MX (catching a split-MX leftover), that SPF is a single valid record containing spf.protection.outlook.com, and that both DKIM selectors resolve, in one pass.
DNS Check resolves an individual record on its own. Use it to confirm the MS=ms… TXT is live at the root, or that selector1._domainkey.example.com returns a CNAME into …onmicrosoft.com.

Verification Checklist

dig MX example.com +short shows only …mail.protection.outlook.com and nothing from a previous provider.
There is exactly one SPF record, and it contains include:spf.protection.outlook.com.
dig CNAME selector1._domainkey.example.com +short and selector2._domainkey.example.com both return the …onmicrosoft.com targets.
DKIM signing is switched on in the Defender portal, not just published in DNS.
A _dmarc TXT record exists, starting at p=none.
You did not publish the sip/lyncdiscover CNAMEs or the SIP SRV records unless you actually run Skype for Business hybrid.
You’ve waited out the TTL / up to 72 hours before concluding anything is broken.

When It’s Not DNS

If the MX is the only MX, SPF is single and correct, DKIM resolves and is switched on — and mail still misbehaves — DNS has done its job and the problem moved into Microsoft 365 itself: a mailbox that isn’t licensed, a mail-flow rule or connector in the Exchange admin center, or a domain that was added but never set as the default. At that point it’s an account-and-routing question inside the admin center, not a records question in DNS.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.