How to Verify Microsoft 365 Custom Domain MX Record Status During Email Failures

A microsoft 365 domain mx record check lets you quickly diagnose why your organization is not receiving incoming emails. When MX records are misconfigured, deleted, or pointed to the wrong mail server, inbound messages bounce back to senders with delivery failure notifications while outbound mail may continue to work normally.

Fixing email routing issues requires understanding how the Domain Name System (DNS) directs Simple Mail Transfer Protocol (SMTP) traffic. This guide covers how to verify your records, test routing, and fix common misconfigurations using standard command-line tools and diagnostic utilities.

Understanding Microsoft 365 MX Record Architecture

Microsoft 365 uses a single, highly specific Mail Exchange (MX) record for all custom domains. Unlike traditional multi-server environments that use multiple preference values (e.g., 10, 20, 30), Microsoft 365 relies on a routing pattern unique to your tenant name.

The Standard Microsoft 365 MX Syntax

Your MX record always follows this structural format:

[your-domain-com].mail.protection.outlook.com

For example, if your company domain is example.com, your MX record target must be:

example-com.mail.protection.outlook.com

Points to note for a valid configuration:

• Priority: Typically set to 0 (or 10 depending on the DNS registrar interface, though Microsoft 365 functions correctly as long as it is the primary active record).
• TTL (Time to Live): Set to 3600 seconds (1 hour) or lower during migrations, and up to 86400 (24 hours) for stable environments.

How to Perform a Microsoft 365 Domain MX Record Check

You can verify your mail routing configuration using command-line utilities or web-based tools. Before investigating DNS, you should also ensure your broader web infrastructure is reachable by running a quick diagnostic using the Website Down Checker to rule out wider routing or hosting outages affecting your domain's primary name servers.

Using dig on Linux and macOS

The dig utility is the industry standard for querying DNS name servers directly. Open your terminal and run the following command to query the MX record for your domain:

dig example.com MX +noall +answer

Expected Output:

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

If the output points to an old hosting provider, a third-party email gateway, or returns no records at all, inbound mail will fail.

Using PowerShell on Windows

If you are operating on a Windows system without Unix command-line tools, PowerShell provides the Resolve-DnsName cmdlet to check your mail routing records:

Resolve-DnsName -Name example.com -Type MX

Expected Output:

Name             Type   TTL   Section   NameExchange
----             ----   ---   -------   ------------
example.com      MX     3600  Answer    example-com.mail.protection.outlook.com

Querying Microsoft's Name Servers Directly

Sometimes public recursive resolvers like Google (8.8.8.8) or Cloudflare (1.1.1.1) cache outdated DNS records. To bypass local caching and check what Microsoft's own authoritative infrastructure sees, query your domain registrar's primary name server using dig:

dig @ns1.example-registrar.com example.com MX

Troubleshooting Common MX Record Failures

Email flow disruptions typically stem from a few predictable configuration mistakes. Review this comparison table to identify your symptoms and apply the correct fix.

Issue Symptom	Root Cause	Corrective Action
NDR 5.1.1 (User unknown)	MX points to old mail host (e.g., Google or cPanel).	Update MX record to point to [domain]-com.mail.protection.outlook.com.
Intermittent Mail Delivery	Multiple MX records with conflicting priorities.	Remove non-Microsoft MX records unless using a supported third-party spam filter.
DNS Propagation Delay	High TTL value set before making changes.	Lower the TTL to 300 seconds 24 hours prior to making future DNS changes.
Trailing Dot Error	Invalid syntax entered into DNS host panel.	Ensure you do not hardcode a double dot or miss the root dot depending on registrar requirements.
Missing TXT/SPF Record	Mail routed correctly, but flagged as spam.	Add the required v=spf1 include:spf.protection.outlook.com -all TXT record.

Step-by-Step Resolution Workflow

When inbound emails stop arriving, follow this structured troubleshooting workflow to isolate and resolve the issue.

Step 1: Verify Microsoft 365 Tenant Status

Log in to the Microsoft 365 admin center, navigate to the setup or domains section, and check the health status of your custom domain. Microsoft runs automated checks to verify whether your MX, SPF, and CNAME records are detected correctly.

Step 2: Check DNS Propagation Globally

Because DNS updates take time to propagate across global recursive resolvers, a change made at your registrar might not be visible worldwide. Use an external DNS lookup command to test propagation from different network vantage points:

nslookup -type=mx example.com 8.8.8.8

Step 3: Inspect Registrar Settings

Log in to your domain registrar's management console (such as GoDaddy, Cloudflare, Namecheap, or Route 53). Navigate to the DNS Management or Zone Editor section. Note that menu paths vary by provider—look for terms like DNS Records, Zone File, or Advanced DNS.

Ensure that:

• There is only one active MX record pointing to Microsoft 365 (unless routing through an approved email security gateway like Proofpoint or Mimecast).
• CNAME records for autodiscover and sip are intact, as email clients require them for automatic profile configuration.

Step 4: Test SMTP Handshake

You can manually test if Microsoft's mail servers are accepting connections for your domain by simulating an SMTP session using openssl or telnet (if enabled):

openssl s_client -connect example-com.mail.protection.outlook.com:25 -starttls smtp

This command establishes a secure connection to the Microsoft inbound gateway, confirming that ports are open and the server is responsive.

Pre-Flight Checklist for Domain Email Health

Before closing out an email troubleshooting ticket, verify that all supporting DNS records are in place:

• MX Record: Points strictly to [yourdomain].mail.protection.outlook.com.
• SPF Record: TXT record includes include:spf.protection.outlook.com.
• DKIM CNAMEs: Two CNAME records (selector1._domainkey and selector2._domainkey) are published for message signing.
• DMARC Record: TXT record exists at _dmarc.yourdomain.com specifying a policy (p=none, p=quarantine, or p=reject).
• TTL Values: Configured appropriately for operational stability.

Fixing inbound mail delivery comes down to systematic verification. By ensuring your MX target matches your tenant naming convention and clearing out legacy routing records, your Microsoft 365 environment will restore full email functionality.