DNS Records Required for Microsoft 365 (Complete Setup Guide)

A Microsoft 365 deployment relies on multiple DNS record types to support email delivery, domain verification, client connectivity, and email authentication.

Mail flow (Exchange Online), service discovery (Autodiscover), and security controls (SPF, DKIM, DMARC) all depend on DNS being configured correctly.

Microsoft provides official DNS setup guidance.

• Microsoft 365 DNS setup guide

Because of these dependencies, partial or incorrect DNS changes can result in mail delivery failures, login issues, or inconsistent client behaviour.

• MX record for inbound email routing to Exchange Online
• TXT record for domain verification (MS=msXXXXXXXX)
• TXT record for SPF (authorising Microsoft 365)
• CNAME records for services such as autodiscover
• DKIM records for email signing
• DMARC record for policy enforcement and reporting

Microsoft 365 uses a tenant-specific MX record that routes mail through Exchange Online Protection.

The MX record typically follows this format:

0 yourdomain-com.mail.protection.outlook.com

The exact hostname is unique to your tenant and must match the value provided in the Microsoft 365 admin portal.

Leaving legacy MX records in place alongside this record can cause split delivery or inconsistent routing.

TXT records serve two main purposes in Microsoft 365: domain verification and SPF.

Domain verification records typically look like:

MS=ms12345678

SPF records define which servers can send email on behalf of the domain. A standard Microsoft 365 SPF record is:

v=spf1 include:spf.protection.outlook.com -all

• SPF standard (RFC 7208)
• SPF troubleshooting guide

Only one SPF record should exist. If multiple SPF records are published, SPF evaluation will fail with a PermError.

CNAME records are used to support Microsoft 365 services such as Autodiscover, which allows Outlook and other clients to automatically configure mail profiles.

autodiscover.example.com CNAME autodiscover.outlook.com

If this record is missing or incorrect, users may experience login prompts, connection failures, or manual configuration requirements.

Additional CNAME records may be required depending on services in use such as Teams or device management.

DKIM is used to sign outgoing emails, allowing receiving servers to verify authenticity.

Microsoft 365 requires two CNAME records for DKIM, but the exact target values should be copied from the Defender portal or Exchange Online PowerShell for your domain.

selector1._domainkey.example.com CNAME <selector1-cname-from-microsoft-365>
selector2._domainkey.example.com CNAME <selector2-cname-from-microsoft-365>

That matters because Microsoft introduced an updated DKIM target format for some custom domains in May 2025. Older examples that always point into the tenant's onmicrosoft.com namespace are no longer universally correct.

• Microsoft DKIM setup guide
• DKIM standard (RFC 6376)

After publishing these records, DKIM must be enabled within Microsoft 365, and the live CNAME answers should match the exact values Microsoft provided.

DMARC builds on SPF and DKIM to define how receiving servers should handle authentication failures.

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

• DMARC standard (RFC 7489)

Policies can be gradually strengthened from monitoring to enforcement as confidence increases.

• Verification TXT record is present and correct
• MX record matches the Microsoft 365 tenant value exactly
• SPF includes spf.protection.outlook.com and does not exceed lookup limits
• Autodiscover CNAME is configured correctly
• No legacy MX or SPF records remain from previous providers
• DKIM records are published and enabled
• DMARC record is present and aligned with policy requirements

• Leaving old MX records active alongside Microsoft 365
• Publishing multiple SPF records instead of merging them
• Forgetting to configure autodiscover CNAME
• Adding DKIM records but not enabling signing in Microsoft 365
• Skipping DMARC configuration
• Assuming migration is complete without testing mail flow and authentication

After configuring DNS, validation is essential to ensure everything is working correctly.

Start by checking MX, TXT, and CNAME records using a DNS lookup tool.

• How to check Microsoft 365 DNS
• Microsoft 365 SPF, DKIM, and DMARC setup
• Email Provider Setup Checker
• Microsoft Remote Connectivity Analyzer

Send a test email and review message headers to confirm SPF, DKIM, and DMARC all pass.

• How to read email headers

A properly configured environment should result in consistent mail delivery and aligned authentication results.

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.

• Email Provider Setup Checker
• How to Check Microsoft 365 DNS
• Microsoft 365 SPF, DKIM, and DMARC Setup
• MX Lookup
• Email Security Check