To use Microsoft 365 for email on your domain, replace your domain's MX records with Microsoft's, add an autodiscover CNAME so Outlook can configure itself automatically, and update your SPF and DKIM records to authenticate Microsoft's servers. All of this happens in DNS, not in your hosting account. If your domain is pointed at our hosting, edit records in Services → your hosting → DNS Zone Editor. Don't add these records alongside your existing hosting email setup; MX changes replace where mail goes, they don't split it.
MX records for Microsoft 365
Microsoft 365 uses a single MX record per domain, unlike some providers that require several. It looks like this:
Priority: 0 Value: yourdomain-com.mail.protection.outlook.com
The exact hostname is domain-specific, using your domain name with dots replaced by hyphens. You'll get the precise value from the Microsoft 365 admin center when you add and verify your domain there. Remove any existing MX records pointing at mail.yourdomain.com or another provider before adding this one. Two competing MX records mean some mail goes to Microsoft and some goes to the old destination, which looks like random, unpredictable delivery failures to anyone emailing you.
Verifying domain ownership
Before Microsoft will accept your MX change, it asks you to prove you control the domain. It gives you a TXT record to add, usually in the form MS=msXXXXXXXX. Add this as a TXT record at your domain's root in DNS Zone Editor, then click verify in the Microsoft 365 admin center. Propagation is usually fast, but if verification fails immediately after adding the record, wait a few minutes and retry before assuming something's wrong.
The autodiscover CNAME
Outlook (desktop, mobile, and web) uses autodiscover to find server settings automatically instead of asking users to type in IMAP or SMTP hostnames. Add a CNAME record:
Host: autodiscover Type: CNAME Value: autodiscover.outlook.com
Without this record, Outlook clients can still be configured manually, but users will hit a setup wizard that can't find the account automatically, and mobile mail apps in particular tend to handle that badly. If you previously had an autodiscover record pointing at your old mail host, this replaces it, not adds to it.
SPF, DKIM, and DMARC
These three records authenticate outgoing mail and matter more once you're relying on Microsoft's infrastructure to send on your behalf. See SPF records: what they are and how to set one up for how the format works in general; the Microsoft-specific piece is the include.
SPF: update your domain's existing SPF TXT record to include Microsoft's sending infrastructure:
v=spf1 include:spf.protection.outlook.com -all
If you send from other services too (a marketing platform, a CRM), add their includes to this same record rather than creating a second SPF TXT record. Only one SPF record per domain is valid; a second one breaks authentication for everyone, including Microsoft.
DKIM: Microsoft 365 doesn't sign outbound mail with DKIM by default until you turn it on. In the Microsoft 365 admin center, go to the Defender portal's email authentication settings, select your domain, and enable DKIM. It gives you two CNAME records (selector1 and selector2) to publish in DNS. Add both as CNAMEs exactly as shown, then enable signing in the admin center. Skipping this step means your mail still sends, but without a DKIM signature, which some receiving servers weigh heavily when deciding what lands in spam.
DMARC: once SPF and DKIM are confirmed working, add a DMARC TXT record to tell receiving servers what to do with mail that fails both checks:
Name: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
p=quarantine sends failures to spam; p=reject drops them outright once you're confident legitimate mail isn't getting caught. Start with quarantine and tighten later.
SRV records for Skype for Business or Teams
If your Microsoft 365 tenant uses Skype for Business (legacy) or certain Teams federation features, Microsoft may ask for SIP-related SRV and CNAME records, such as _sip._tls and _sipfederationtls._tcp. Most Teams-only tenants on modern setups don't need these; add them only if the Microsoft 365 admin center's domain setup wizard specifically lists them as required for your domain. If DNS Zone Editor doesn't offer the record type you need, contact support.
After the switch
DNS changes typically propagate within a few minutes to a few hours. Send yourself a test email from an external address and confirm it arrives in Outlook or the Microsoft 365 web interface, and send one out to confirm delivery isn't landing in the recipient's spam folder. If you want a second opinion on whether SPF and DKIM are actually configured correctly once everything's live, checking SPF and DKIM with the Email Deliverability tool covers the general checks.
If your domain's nameservers point elsewhere and you can't find DNS Zone Editor for it, remember that Domains → your domain → DNS in our portal only edits nameservers, not individual records. You need your hosting's DNS Zone Editor, or your DNS provider's own dashboard if the domain isn't using our nameservers at all.
When to contact support
If MX changes have propagated but mail still isn't arriving after several hours, or if DNS Zone Editor doesn't show an option for a record type Microsoft's wizard is asking for, open a ticket from Support → New ticket in the portal. Include the exact record Microsoft asked for and a screenshot of what you currently have configured; that's usually enough for a human to spot the mismatch quickly.