← Back to Blog

Setting up Microsoft 365 for your domain requires 6 to 8 DNS records configured correctly. Miss one and Outlook autoconfiguration breaks. Get the SPF record wrong and your email lands in spam. Forget DKIM and forwarded messages fail authentication. Leave DMARC at p=none and your domain is open to spoofing.

This guide covers every DNS record Microsoft 365 requires, what each one does, the exact values to use, common mistakes that cause outages, and how to verify your configuration.

The Complete Record Set

Here's every DNS record a standard Microsoft 365 deployment needs, organized by function. Replace yourcompany and yourcompany-com with your actual domain values, which you'll find in the Microsoft 365 Admin Center under Settings, then Domains.

1. Domain Verification (TXT Record)

Before Microsoft 365 will accept your domain, you need to prove you own it by adding a verification TXT record.

yourcompany.com.  3600  IN  TXT  "MS=ms12345678"

The MS=ms######## value is unique to your tenant. Find it in the Admin Center when you add your domain. This record can be removed after verification is complete, but there's no harm in leaving it.

2. Mail Routing (MX Record)

The MX record tells the internet where to deliver email for your domain.

yourcompany.com.  3600  IN  MX  0 yourcompany-com.mail.protection.outlook.com.

The priority should be 0 (highest priority). The target hostname follows the pattern yourdomain-tld.mail.protection.outlook.com, where dots in your domain name are replaced with hyphens.

Important update for 2026: Microsoft is migrating MX records to a new endpoint format under mx.microsoft with DNSSEC and DANE support. New domains provisioned after July 2026 will use the new MX format automatically. Existing domains can opt in via PowerShell. The mail.protection.outlook.com endpoint continues to work, but the new endpoint provides stronger transport security. Check Microsoft's documentation for the latest guidance.

Common MX Mistakes

  • Leaving old MX records in place. If you're migrating from another email provider, remove their MX records. Having two sets of MX records means email is split between providers based on priority values, causing inconsistent delivery.
  • Wrong priority. The Microsoft MX record should have the lowest priority number (highest priority). If another MX record has a lower number, some email will route there instead.

3. Autodiscover (CNAME Record)

Autodiscover enables Outlook and other email clients to automatically configure connection settings (server addresses, ports, protocols) without the user manually entering them.

autodiscover.yourcompany.com.  3600  IN  CNAME  autodiscover.outlook.com.

This is one of the most frequently forgotten records, and the symptoms are frustrating: Outlook prompts users for server settings, mobile devices fail to set up email, and the "Repair account" option in Outlook doesn't work.

Migration Warning

If you're migrating from on-premises Exchange, check for an existing autodiscover A record or internal Service Connection Point (SCP) that might take priority over the CNAME. Outlook checks multiple autodiscover locations in a specific order, and an old on-premises record can override the Microsoft 365 CNAME, causing Outlook to attempt connecting to the old server after migration.

4. SPF Record (TXT Record)

SPF tells receiving mail servers that Microsoft 365 is authorized to send email on behalf of your domain.

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

If you also send email through other services (marketing platforms, CRM, transactional email providers), add their includes too:

"v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com -all"

Critical SPF Rules

  • Only one SPF record per domain. If you have two TXT records starting with v=spf1, SPF evaluation returns a permanent error. Combine all includes into a single record.
  • Stay under 10 DNS lookups. Each include counts as a lookup, and nested includes compound the count. Microsoft's include:spf.protection.outlook.com alone uses several lookups. Monitor your total count as you add services.
  • Use -all in production. Start with ~all (soft fail) during initial setup, then switch to -all (hard fail) once you've confirmed all legitimate senders are covered.

Check your current SPF record with the DNS lookup tool at dnsassistant.com/tools by querying TXT records for your domain.

5. DKIM (CNAME Records)

DKIM adds cryptographic signatures to outgoing email, proving messages haven't been modified in transit. Microsoft 365 requires two CNAME records for DKIM:

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

The exact CNAME targets are unique to your tenant. Find them in the Microsoft 365 Defender portal under Email and Collaboration, then Policies, then DKIM.

Enabling DKIM

Adding the CNAME records alone doesn't enable DKIM signing. After the DNS records are in place and propagated, you must enable DKIM in the Defender portal by toggling the "Sign messages for this domain with DKIM signatures" switch. Microsoft will verify that the CNAME records resolve correctly before allowing activation.

This two-step process (DNS first, then portal activation) trips up many admins who add the records and assume DKIM is working. Always verify in the portal that signing is active.

6. DMARC (TXT Record)

DMARC ties SPF and DKIM together and defines what happens when messages fail authentication.

_dmarc.yourcompany.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Start with p=none to collect reports without affecting delivery, then progress to p=quarantine and finally p=reject once you're confident all legitimate sending sources are authenticated.

Consider adding sp=reject to protect subdomains:

"v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; pct=100"

For a detailed walkthrough of the DMARC deployment process, see our SPF, DKIM, and DMARC guide.

7. SRV Records (Skype for Business / Teams)

If your organization uses Skype for Business Online or is in a hybrid configuration with Teams, two SRV records are required:

_sip._tls.yourcompany.com.        3600  IN  SRV  100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp.yourcompany.com.  3600  IN  SRV  100 1 5061 sipfed.online.lync.com.

The first enables SIP connectivity for presence and instant messaging. The second enables SIP federation, allowing communication with external organizations.

For organizations fully on Microsoft Teams with no Skype for Business, Microsoft's current guidance is that these SRV records are optional but recommended for backward compatibility and federation scenarios.

8. Additional CNAME Records (Optional)

Depending on your Microsoft 365 services, you may need additional CNAME records for Exchange Online Protection and Mobile Device Management:

enterpriseregistration.yourcompany.com.   3600  IN  CNAME  enterpriseregistration.windows.net.
enterpriseenrollment.yourcompany.com.     3600  IN  CNAME  enterpriseenrollment.manage.microsoft.com.

These are used for Azure Active Directory device registration and Intune MDM enrollment. They're required if you use Azure AD Join or Intune for device management.

Complete Record Summary

Record Type Name Value
Verification TXT @ MS=ms########
Mail routing MX @ 0 yourcompany-com.mail.protection.outlook.com
Autodiscover CNAME autodiscover autodiscover.outlook.com
SPF TXT @ v=spf1 include:spf.protection.outlook.com -all
DKIM (key 1) CNAME selector1._domainkey selector1-yourco-com._domainkey.yourco.onmicrosoft.com
DKIM (key 2) CNAME selector2._domainkey selector2-yourco-com._domainkey.yourco.onmicrosoft.com
DMARC TXT _dmarc v=DMARC1; p=reject; rua=mailto:[email protected]
SIP SRV _sip._tls 100 1 443 sipdir.online.lync.com
SIP Federation SRV _sipfederationtls._tcp 100 1 5061 sipfed.online.lync.com

Verification Checklist

After configuring all records, verify each one before considering the deployment complete:

  1. MX record: Use the DNS lookup tool to query MX records for your domain. You should see only the Microsoft 365 endpoint with the lowest priority number.
  2. SPF record: Query TXT records and verify a single SPF record exists with include:spf.protection.outlook.com.
  3. DKIM CNAMEs: Query CNAME records for selector1._domainkey.yourcompany.com and selector2._domainkey.yourcompany.com. Both should resolve to your onmicrosoft.com targets.
  4. DKIM activation: Confirm in the Microsoft 365 Defender portal that DKIM signing is enabled (not just that the DNS records exist).
  5. DMARC: Query TXT records for _dmarc.yourcompany.com. Verify the policy and reporting address.
  6. Autodiscover: Query CNAME for autodiscover.yourcompany.com. Should resolve to autodiscover.outlook.com.
  7. Send test email: Send a message to a Gmail address and inspect the email headers for spf=pass, dkim=pass, and dmarc=pass.

For a comprehensive scan of your DNS and email authentication configuration, run a Free Domain Risk Report.

Common Problems After Setup

Outlook Keeps Prompting for Credentials

Usually caused by a missing or incorrect autodiscover CNAME. Can also occur if an on-premises autodiscover record is taking priority over the Microsoft 365 CNAME.

Email Going to Spam at External Recipients

Check SPF (is Microsoft's include present?), DKIM (is signing enabled in the portal, not just DNS?), and DMARC (is the policy set?). All three must pass for optimal deliverability. Also verify your sending IP has a valid PTR record (see our reverse DNS guide).

Email From Third-Party Services Failing SPF

If you send email through services beyond Microsoft 365 (marketing tools, CRM, ticketing systems), each one needs to be included in your SPF record. Adding a new service without updating SPF means messages from that service fail SPF checks.

DKIM Showing as "Not Enabled" Despite DNS Records

The CNAME records are necessary but not sufficient. You must also enable DKIM signing in the Microsoft 365 Defender portal. The portal verifies the CNAME records resolve before allowing activation. If activation fails, the CNAME targets are likely incorrect or haven't propagated yet.

Ongoing Monitoring

Microsoft 365 DNS records are configured once but can break over time. Common causes include well-intentioned changes that accidentally modify SPF, DKIM key rotations that require CNAME updates, domain transfers that drop existing records, and security incidents that modify MX routing.

DNS Assistant monitors all Microsoft 365 DNS records continuously and alerts your team when anything changes. Whether it's an MX record modification that reroutes email, an SPF change that breaks authentication, a missing DKIM CNAME after a domain migration, or a DMARC policy downgrade, you'll know immediately rather than discovering it when users report email problems.

For continuous monitoring of your Microsoft 365 DNS configuration, sign up at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free