Adding your own domain to Microsoft 365 is what turns generic [email protected]
addresses into proper [email protected] mail. The process itself is short: prove you own
the domain, then publish a handful of DNS records so mail and the Office clients know where to
go. The part that trips people up is DNS — one wrong record, or an old MX left in place, and
mail either fails verification or quietly lands at the wrong provider.
This walkthrough covers the whole path: adding the domain in the admin center, the TXT record that proves ownership, and the records you actually need afterward (MX, autodiscover, SPF, and DKIM). It also covers the failures that generate most of the support tickets, because almost all of them come down to DNS rather than Microsoft 365 itself.
Before you start
Domain onboarding touches DNS, and DNS changes can break a live website or existing mail if you rush. A few checks first save a lot of grief.
Before you add the domain
- You're a Global Administrator (or Domain Name Administrator) in the tenant
- You can sign in to the domain's DNS host (where the nameservers point)
- You know whether the domain is already handling live email somewhere
- You've noted any existing MX, SPF, or TXT records so you don't clobber them
- You have a quiet window planned if this domain already receives mail
Step 1: Add the domain in the admin center
- Sign in to the Microsoft 365 admin center (
admin.microsoft.com). - Go to Settings → Domains.
- Click Add domain.
- Type your domain name (for example
yourcompany.com) and click Use this domain.
Microsoft now needs to confirm you actually own it before it will route mail. That’s the next step, and it’s done with a single TXT record.
Step 2: Verify ownership with a TXT record
Microsoft generates a unique verification value that looks like MS=ms12345678. You add it as
a TXT record at the root of your domain, and Microsoft checks for it.
Verification TXT record
| Type | TXT |
|---|---|
| Host / Name | @ (the root of the domain) |
| Value / Points to | MS=ms12345678 (use the exact value shown in the portal) |
| TTL | 1 hour (3600) is fine |
After you publish the record at your DNS host, return to the wizard and click Verify. If it fails on the first try, that’s almost always propagation lag, not a mistake — wait a few minutes and try again.
Step 3: Choose who manages DNS
After verification, the wizard asks how you want to handle records. You get two practical paths:
- Let Microsoft set up records (delegated DNS): you repoint the domain’s nameservers to Microsoft and it manages everything. Clean, but it means moving all DNS — including any website records — under Microsoft’s control.
- Add records yourself: you keep DNS at your current host and add only what Microsoft 365 needs. This is the right choice for almost anyone who already runs a website or other services on the domain.
The rest of this guide assumes you’re adding records yourself, since that’s the common case and the one where mistakes happen.
Step 4: The DNS records Microsoft 365 needs
Here are the records that make mail and the Office clients work. The exact MX and DKIM values include your tenant’s domain key, so copy them from the portal — but the shape is always the same.
Core Microsoft 365 DNS records
| MX | @ → yourdomain-com.mail.protection.outlook.com (priority 0) |
|---|---|
| CNAME (autodiscover) | autodiscover → autodiscover.outlook.com |
| TXT (SPF) | @ → v=spf1 include:spf.protection.outlook.com -all |
| CNAME (DKIM selector1) | selector1._domainkey → selector1-...._onmicrosoft.com |
| CNAME (DKIM selector2) | selector2._domainkey → selector2-...._onmicrosoft.com |
What each one does, in plain terms:
- MX routes inbound mail to Exchange Online. The hostname is built from your domain (dots
become dashes), ending in
.mail.protection.outlook.com. Priority is0. - Autodiscover CNAME lets Outlook and phones find the right server automatically when a user sets up the account. Skip it and people end up entering server settings by hand.
- SPF is a TXT record listing who may send mail for your domain. The Microsoft 365 value is
include:spf.protection.outlook.com. - DKIM is two CNAMEs that enable cryptographic signing of your outbound mail. They’re published but DKIM itself is switched on separately (Step 5).
If your tenant also uses Teams or Skype for Business calling, the wizard may list extra SRV and
CNAME records (sip, lyncdiscover, _sip, _sipfederationtls). Add those only if you use
those services — they’re not needed for email.
Step 5: Turn on DKIM
Publishing the two DKIM CNAMEs isn’t enough on its own — you enable signing afterward.
- Go to the Microsoft 365 Defender portal (
security.microsoft.com). - Open Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
- Select your domain and switch Sign messages for this domain with DKIM signatures to On.
If the toggle errors out, the CNAMEs usually haven’t propagated yet, or one of them has a typo.
Recheck the two selector1 / selector2 records, give DNS time, and try again.
Common verification and mail-flow failures
Most problems land in one of these buckets. Work through them before assuming something is wrong on Microsoft’s side.
What usually goes wrong
| Verification keeps failing | DNS hasn't propagated, or the TXT value was edited. Paste the exact MS= value and wait. |
|---|---|
| Record added on the wrong domain | You added it at the registrar but nameservers point elsewhere. Add it at the authoritative host. |
| Host field confusion | Some panels want @ for the root; others auto-append the domain. Adding the full domain twice creates yourdomain.com.yourdomain.com. |
| Mail still hits the old provider | Old MX record is still present. Remove it so only the Microsoft 365 MX remains. |
| Outbound mail marked as spam | SPF missing or has two records, and DKIM not enabled. Fix SPF, turn on DKIM. |
| Outlook won't autoconfigure | Autodiscover CNAME missing or pointing somewhere else. |
A couple of these deserve a closer look.
The duplicated-domain host trap
DNS panels disagree about the Host (or Name) field. Cloudflare and many others let you
type @ for the root and autodiscover for a subdomain, and they append the domain for you.
Other panels expect the fully qualified name. If you type autodiscover.yourdomain.com into a
panel that auto-appends, you end up with autodiscover.yourdomain.com.yourdomain.com, which
resolves to nothing. When a CNAME “just won’t work,” check for the doubled domain first.
Two MX records during a switch
If the domain already received mail elsewhere, you’ll have an existing MX record. Leaving it in
place alongside the Microsoft 365 MX means mail can be delivered to either service depending on
which record a sender’s server picks. Delete the old MX so only ...mail.protection.outlook.com
remains. If mail still isn’t arriving at the new mailboxes after the MX is correct, work through
Microsoft 365 email not sending or receiving
to check the rest of the mail-flow chain.
Quick verification
Once the records are in and DKIM is on, confirm the domain is genuinely working:
- In Settings → Domains, open the domain and check that Microsoft 365 reports Healthy (no missing records flagged).
- Send a test message from a new mailbox on the domain to an outside address (Gmail works well) and confirm it arrives in the inbox, not spam.
- In Gmail, open the message, choose Show original, and confirm SPF: PASS and DKIM: PASS.
- Set up Outlook on the domain account and confirm it configures automatically — that proves the autodiscover CNAME is right.
Wrapping up
Adding a custom domain is mostly a DNS exercise. Verify ownership with the temporary MS= TXT
record, then publish the records that matter long term: MX for inbound mail, the autodiscover
CNAME for client setup, one clean SPF record, and the DKIM CNAMEs plus the Defender toggle. Keep
SPF to a single record, remove any old MX, and watch for the doubled-domain host trap, and
verification usually goes through on the first real attempt.
If this domain is part of a wider move onto Microsoft 365, it pairs naturally with planning your mailbox migration — see cutover migration to Microsoft 365 — and once users are live you’ll likely want to set up team addresses with a shared mailbox.
