How to Check MX Records for Any Domain (2026 Guide)

If email is bouncing, deliverability is down, or you're setting up Google Workspace or Microsoft 365, MX records are the first thing to check. This guide shows every way to look them up and explains what the output means.

Table of Contents

• What an MX record is
• How MX priority works
• Method 1 — Check MX with an online DNS Lookup tool
• Method 2 — Check MX with nslookup
• Method 3 — Check MX with dig
• MX records for Google Workspace
• MX records for Microsoft 365 / Outlook
• Reading the priority values
• Common MX errors and fixes
• Testing deliverability end-to-end
• Common mistakes
• FAQ

What an MX Record Is

MX (Mail Exchanger) records live in the DNS zone of your domain. They answer one question: when someone sends email to name@yourdomain.com, which server should the sending mail server hand the message to?

Each MX record has a priority (an integer) and a hostname (like aspmx.l.google.com). Sending servers try the lowest priority number first, and fall back to higher numbers if the first is unreachable.

How MX Priority Works

A domain typically publishes several MX records. Example: 1 aspmx.l.google.com, 5 alt1.aspmx.l.google.com, 5 alt2.aspmx.l.google.com, 10 alt3.aspmx.l.google.com, 10 alt4.aspmx.l.google.com. Sending servers connect to priority 1 first; if it's down they try either of the priority-5 servers; last resort is the priority-10 pair.

Method 1 — Check MX with an Online DNS Lookup Tool

Fastest option. Enter the domain, choose MX from the record-type menu, and hit lookup. You'll see priorities and hostnames in a table. Works from any device without installing anything.

Method 2 — Check MX with nslookup

Windows, macOS, Linux all have nslookup built-in.

1. Open Command Prompt (Windows) or Terminal (mac/Linux).
2. Type: nslookup -type=MX gmail.com
3. Read the 'mail exchanger' lines — each shows priority and hostname.

Method 3 — Check MX with dig

On macOS/Linux, dig gives cleaner output: dig MX gmail.com +short. To see the full record with TTL, drop the +short.

MX Records for Google Workspace

Google Workspace requires exactly these five MX records on your domain:

• 1 aspmx.l.google.com
• 5 alt1.aspmx.l.google.com
• 5 alt2.aspmx.l.google.com
• 10 alt3.aspmx.l.google.com
• 10 alt4.aspmx.l.google.com

Newer Workspace tenants may see the simpler single MX record: 1 smtp.google.com. Both are supported; check the current values in the Google Admin console under Domains → Manage domains.

MX Records for Microsoft 365 / Outlook

Microsoft 365 gives you a single MX record in the format: 0 yourdomain-com.mail.protection.outlook.com. The exact hostname is shown in the Microsoft 365 admin center under Setup → Domains → your domain → DNS records. Priority is usually 0.

Reading the Priority Values

Priority values look like the opposite of intuition — lower is better. Priority 1 is tried before priority 10. Same-priority entries are used with roughly equal weight (round-robin or randomised).

Common MX Errors and Fixes

'No MX record for domain'

Either you never added an MX record, or you added it to the wrong subdomain. Verify with a DNS Lookup tool that MX resolves for the exact domain (usually apex, not www).

'MX record points to a CNAME'

MX targets must be hostnames with A/AAAA records, not CNAMEs. Fix by pointing MX at an A-resolving name.

Bouncebacks after Workspace/365 setup

Almost always TTL — the old MX is still cached at sending mail servers. Wait for the old TTL to expire (usually up to 24 hours), or lower TTL before you migrate.

Duplicate MX with different providers

Never mix old and new providers on the same priority. Traffic will split randomly. Cut over cleanly: remove all old MX records at the same time you add the new ones.

Testing Deliverability End-to-End

1. Send a test message from a Gmail account to your domain.
2. Send a message from your domain to check-auth@verifier.port25.com — it replies with a full SPF/DKIM/DMARC report.
3. Check MXToolbox, Google Postmaster Tools, or Microsoft SNDS for delivery reputation.

Common Mistakes

• Forgetting the trailing dot in DNS control panels — some accept it, some don't.
• Setting up MX but forgetting SPF / DKIM / DMARC — see our dedicated guide.
• Leaving old MX records live during migration, causing split delivery.
• Using CNAME as MX target — invalid per RFC.
• Assuming MX propagation is instant — respect the TTL.