How to Check MX Records for Any Domain

Mail is not delivered by magic. Every time someone sends an email to you@yourdomain.com, the sending mail server performs a DNS lookup to find the Mail Exchanger (MX) records for your domain, then connects to whichever server those records point to. If those records are missing, wrong, or pointing to a server that is not accepting connections, email bounces. Knowing how to check MX records quickly — from any device, on any operating system — is one of the most practical skills in any IT toolkit, and it takes less than two minutes once you know where to look.

What an MX Record Actually Contains

An MX record is a DNS resource record that specifies the hostname of a mail server responsible for accepting email for a domain. Unlike an A record (which maps a name directly to an IP address), an MX record always points to a hostname, never an IP. That hostname then has its own A or AAAA record that resolves to the actual server IP.

Every MX record has two key fields beyond the hostname:

• Priority (preference value): A lower number means higher priority. If you have two MX records — one at priority 10 and one at priority 20 — sending servers will always try the priority-10 host first and only fall back to priority 20 if the first is unreachable.
• Exchange (mail server hostname): The fully qualified domain name (FQDN) of the mail server, such as mail.yourdomain.com or aspmx.l.google.com.

A typical, healthy MX record set for Google Workspace looks like this:

The TTL (3600 in this case, meaning one hour) controls how long resolvers cache the record before re-checking. That number becomes very important during migrations.

Checking MX Records on Windows

Windows ships with nslookup, which has been available since the Windows NT era. Open a Command Prompt (Win + R, type cmd, press Enter) and run the following:

You will see output like:

The line that says Non-authoritative answer simply means the result came from a caching resolver, not directly from your domain's authoritative nameservers. That is normal. If you want to bypass caching and query the authoritative server directly, first find it:

This returns your nameservers (for example, ns1.registrar.com). Then query one of them directly:

If the authoritative answer differs from the cached one, you are likely in the middle of a propagation window after a recent change.

Checking MX Records on macOS and Linux

On macOS and Linux, you have two powerful options: dig and host. Both come pre-installed on most distributions and on macOS.

Using dig

The relevant section is the ANSWER SECTION. A clean result looks like:

To query a specific DNS server — useful for comparing your registrar's authoritative answer against what the public internet sees — use the @ symbol:

To get a short, no-noise answer:

Output will be clean priority-and-hostname pairs:

Using host

The host command is simpler and good for quick checks:

Output:

Checking MX Records Using an Online Tool

Command-line tools are great, but there are situations where you are on a locked-down corporate machine, helping a non-technical user over the phone, or you need to see what the world sees rather than what your local resolver sees. That is where web-based tools earn their place.

Our DNS Lookup tool lets you enter any domain, select MX as the record type, and instantly see the full MX record set including priorities, hostnames, and the resolved IP addresses behind each mail server hostname. No installation required, no command prompt needed.

When using any online MX checker, look for the following in the results:

• At least one MX record exists. If the lookup returns no records, email to that domain will fail with a bounce or queue until a record is added.
• MX records point to hostnames, not IPs. An MX record pointing directly to an IP address (like 203.0.113.45) is technically invalid per RFC 5321 and will be rejected by many sending servers.
• The hostnames in MX records resolve to valid IPs. A valid MX hostname that has no A record is just as broken as no MX record at all.
• Priority values make sense. If you have a backup mail server, it should have a higher priority number than your primary.

Common MX Record Problems and How to Fix Them

No MX Records Found

This is the most disruptive scenario. New domains, freshly migrated domains, and domains where someone accidentally deleted the MX record all share this symptom. Senders will receive a bounce message like 550 No such user here or Host or domain name not found.

Fix: Log in to your DNS host (this is usually your registrar or hosting provider, not your domain registrar if you have pointed nameservers elsewhere). Navigate to the DNS management section and add an MX record. For most providers, the fields are:

1. Type: MX
2. Host / Name: @ (represents the root domain)
3. Value / Points to: your mail server hostname (e.g., mail.yourdomain.com)
4. Priority: 10
5. TTL: 3600 (or leave as default)

MX Record Points to Wrong Server

This typically happens after a migration from one email provider to another. The old provider's hostname is still in DNS. Email arrives at the old server, which may have no mailboxes for your domain anymore.

Fix: Update the MX record value in your DNS panel to point to the new mail server hostname. Do not delete the old record and re-add — most panels let you edit in place, which avoids a gap in delivery. Lower the TTL to 300 (5 minutes) at least one TTL cycle before you make the change so the update propagates quickly.

MX Record Has Correct Hostname but No A Record

If your MX record says mail.yourdomain.com but there is no A record for that hostname, every sending server will fail during the connection phase. Check this with:

If that returns nothing, add an A record for the mail subdomain pointing to your mail server's IP address.

Multiple MX Records with Identical Priorities

Having two records with the same priority is actually valid — senders will load-balance between them. But if both point to the same IP, it is redundant and confusing. Audit your MX records periodically to make sure the configuration reflects your actual infrastructure.

Verifying Your MX Records After a Change

After editing an MX record, do not just assume the change worked. Follow this verification sequence:

1. Query your authoritative nameserver directly (using the @ syntax in dig or nslookup) to confirm the new record is live at the source.
2. Wait for one full TTL period to ensure caches have expired the old value.
3. Query a public resolver (8.8.8.8 or 1.1.1.1) to confirm they are returning the new record.
4. Use an online propagation checker to verify globally.
5. Send a test email from a third-party address (Gmail, Outlook, etc.) and check that it arrives at the new mail server.

Do not rely solely on sending a test email. Emails can queue silently for up to 72 hours if a server is temporarily unreachable, giving you false confidence that the old setup is still working.

MX Record Syntax Reference for Major Email Providers

If you are setting up MX records from scratch for a popular provider, here are the correct values as of current documentation:

Google Workspace

Microsoft 365

(The exact hostname varies — find it in the Microsoft 365 Admin Center under Domains.)

Zoho Mail

How to Prevent MX Record Problems

Most MX outages are preventable. These habits catch problems before users start complaining:

• Monitor MX records with an automated tool. Set up a cron job or use a monitoring service that alerts you if your MX records change unexpectedly. Unauthorized changes can indicate a DNS hijack.
• Keep TTLs sensible. A TTL of 3600 (one hour) is a good default. Drop it to 300 before planned changes, then raise it back once the migration is confirmed stable.
• Document your DNS before migrations. Export your full DNS zone before touching anything. Most registrar panels have an export option, or you can zone-transfer with dig AXFR if your nameservers permit it.
• Never point MX records directly to IP addresses. Always use a hostname. This is an RFC requirement and also makes future IP changes much simpler.
• Keep a backup MX record. Even a simple backup MX pointing to a secondary mail server (or a mail spooling service) prevents email loss during primary server outages.

MX records are not complicated, but they are unforgiving. A single typo in a hostname or a missing A record can silently drop email for hours before anyone notices. The two-minute habit of checking your MX records after any DNS change — using the command-line tools or an online lookup — is one of the cheapest insurance policies in IT operations.