Home/Insights/Azure

Troubleshooting M365 Domain DNS Setup Issues

A Microsoft 365 domain DNS checklist for validating ownership, MX, Autodiscover, SPF, Teams/Skype records, propagation, and rollback before changing production mail flow.

Quick Read

  • Symptom: A Microsoft 365 domain DNS checklist for validating ownership, MX, Autodiscover, SPF, Teams/Skype records, propagation, and rollback before changing production mail flow.
  • Check first: Capture the affected source, destination, protocol, port, DNS name, VLAN or subnet, and exact error before changing policy.
  • Risk: Changes system state

Symptoms

Users are unable to access Microsoft 365 services due to incorrect DNS settings for their domain.

Environment

Microsoft 365, DNS management platforms (e.g., GoDaddy, Cloudflare, AWS Route 53)

Most Likely Causes

Misconfigured DNS records for the domain associated with Microsoft 365 services, such as missing or incorrect MX, CNAME, or TXT records.

What to Check First

  1. Capture the affected source, destination, protocol, port, DNS name, VLAN or subnet, and exact error before changing policy.
  2. Verify path, name resolution, authentication, and firewall policy separately so one symptom does not hide multiple failures.
  3. Check whether the issue is isolated to one client, one subnet, one VPN profile, or every path.

Fix Steps

  1. Verify Domain Ownership in Microsoft 365

    Ensure that the domain is verified in the Microsoft 365 admin center.

    Example pattern only. Adjust for your environment before running.

    Log in to the Microsoft 365 admin center.
Navigate to 'Setup' > 'Domains'.
Check if the domain status shows 'Verified'.
  2. Check DNS Records

    Access your DNS management platform to review the DNS records for the domain.

    Example pattern only. Adjust for your environment before running.

    Log in to your DNS management platform (e.g., GoDaddy, Cloudflare).
Locate the DNS settings for your domain.
Verify the following records are present and correctly configured:
1. MX records for mail delivery.
2. CNAME records for Autodiscover and other services.
3. TXT records for SPF and domain verification.
  3. Update MX Records

    Ensure that the MX records point to Microsoft 365 mail servers.

    Example pattern only. Adjust for your environment before running.

    In the DNS management console, locate the MX records section.
Delete any existing MX records that do not point to Microsoft 365.
Add the following MX record:
Host: @
Points to: <your-domain>.mail.protection.outlook.com
Priority: 0
  4. Update CNAME Records

    Ensure that CNAME records for Autodiscover and other services are correctly set.

    Example pattern only. Adjust for your environment before running.

    In the DNS management console, locate the CNAME records section.
Add or update the following CNAME records:
1. Host: autodiscover, Points to: autodiscover.outlook.com
2. Host: www, Points to: <your-domain>
3. Host: sip, Points to: sipdir.online.lync.com
4. Host: lyncdiscover, Points to: webdir.online.lync.com
  5. Update TXT Records

    Ensure that the TXT records for SPF and domain verification are correctly configured.

    Example pattern only. Adjust for your environment before running.

    In the DNS management console, locate the TXT records section.
Add or update the following TXT records:
1. Host: @, Value: v=spf1 include:spf.protection.outlook.com -all
2. Host: @, Value: MS=msXXXXXXXX (replace with your Microsoft verification code)
  6. Check DNS Propagation

    Verify that the DNS changes have propagated successfully.

    Example pattern only. Adjust for your environment before running.

    Use a DNS propagation checker tool (e.g., whatsmydns.net).
Enter your domain and check for MX, CNAME, and TXT records.
Ensure that the records match the expected values.
  7. Test Microsoft 365 Services

    After DNS changes have propagated, test access to Microsoft 365 services.

    Example pattern only. Adjust for your environment before running.

    Try sending and receiving emails using the domain.
Access Microsoft Teams and check for connectivity.
Log in to SharePoint and verify access to documents.

Validation

  • The same client and network path can reach the target after the change.
  • Firewall, VPN, DHCP, DNS, or switch logs show allowed traffic or successful negotiation instead of the prior failure.
  • A second path check confirms that the fix did not open unintended access or break another subnet.

Logs to Check

  • Firewall, VPN, DNS, DHCP, or switch logs for the failing timestamp.
  • Client resolver, route table, VPN client, or browser/network diagnostics.
  • Packet capture or flow logs when policy and routing disagree.

Rollback and Escalation

  • Export or screenshot the original policy, route, resolver, or interface configuration before changing it.
  • Remove temporary allow rules, test DNS records, or route changes after validation.
  • Restore the previous VPN profile, firewall rule, or switch configuration if reachability worsens.

Escalate When

  • Escalate if the same error persists after rollback and a clean retry from the original failing path.
  • Escalate if logs show authorization, data loss, certificate, replication, or production availability risk outside the local service owner scope.

Edge Cases

  • If DNS records are correct but issues persist, check for local DNS caching issues.
  • If using a third-party email service, ensure that it is not conflicting with Microsoft 365 settings.

Notes from the Field

  • Most network incidents need source and destination evidence. A successful test from an admin laptop does not prove the affected client path is fixed.
  • For VPN and firewall changes, keep the blast radius narrow and time-box any temporary allow rule.