How to Check MX Records for Any Domain (2026)

The fastest way to determine a domain's MX records is one of three commands: on Windows run 'nslookup -type=MX yourdomain.com', on macOS or Linux run 'dig MX yourdomain.com +short', or paste the domain into an online DNS Lookup tool. All three return the same list of mail servers and priorities — the lowest priority number is the server that receives mail first.

If email is bouncing, deliverability is dropping, or you're setting up Google Workspace or Microsoft 365, MX records are the first thing to verify. The rest of this guide walks through each method, shows real output for Gmail, Google Workspace and Microsoft 365, and explains how to fix the errors you're most likely to hit.

nslookup vs dig vs online DNS Lookup — which should you use?

• nslookup — built into Windows, macOS and Linux. Best when you're already in a terminal and just need a quick answer. Output is a little verbose.
• dig — cleaner output and supports '+trace' and '+short'. Preferred on macOS/Linux; on Windows install BIND tools or use WSL.
• Online DNS Lookup tool — no install, works from a phone, queries an external resolver so you see what the public internet sees (not your local cache). Best for verifying propagation after a change.

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
• Zero-downtime MX migration checklist
• MX vs SPF, DKIM and DMARC
• 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.

Zero-Downtime MX Migration Checklist

1. 24–48 hours before the cutover, lower the TTL on every existing MX record to 300 seconds.
2. Create the mailboxes on the new provider first, so mail has somewhere to land.
3. Record the current MX values (dig MX yourdomain.com) so you can roll back exactly.
4. Delete all old MX records and add the new set in the same save — never publish both provider sets at once.
5. Send a test message from an external account within five minutes and confirm it arrives at the new provider.
6. Update SPF to include the new provider, publish its DKIM key, and only then raise TTL back to 3600.

MX vs SPF, DKIM, and DMARC

MX controls inbound mail: it says which server accepts messages for your domain. SPF, DKIM, and DMARC control outbound trust: they prove that mail claiming to come from your domain really did. That distinction matters when you're diagnosing a problem — inbound bounces point at MX, while messages landing in spam point at SPF, DKIM, or DMARC. Fixing MX will never improve deliverability of mail you send, and tightening DMARC will never stop an inbound 'no such domain' bounce.