MX Record Lookup

How to Check MX Records for a Domain

1. Enter the domain name: Use the root domain (example.com) — MX records are almost always published at the apex domain, not on subdomains. Do not include "mail." or "www." prefixes unless you have a specific reason to query a subdomain's MX records.
2. Select MX as the record type: Choose MX from the record type dropdown — this returns all mail exchanger records for the domain with their priority values and target hostnames.
3. Read priority values: Lower numbers = higher priority. MX 10 is tried before MX 20. If your primary provider specifies priority 1 and backup specifies priority 5, verify the lookup reflects this order exactly.
4. Verify target hostnames resolve: Each MX record's target hostname must itself resolve to an IP (A or AAAA record). An MX record pointing to a non-resolving hostname silently drops email — look up the hostname separately to confirm it resolves.
5. Cross-check SPF records: After verifying MX records, query TXT records to confirm your SPF record includes all the mail servers listed in your MX records — inconsistencies cause outbound email spam failures.

Real-World Use Case

A company migrates from Google Workspace to Microsoft 365 over a weekend. Monday morning, 30% of inbound emails are missing. An MX record lookup reveals the domain still has both the old Google MX records (aspmx.l.google.com at priority 1) and the new Microsoft records (company-com.mail.protection.outlook.com at priority 10) — during migration, no one deleted the old Google records. Mail from some senders is delivered to Google (where no mailboxes exist), others to Microsoft. The fix is to remove the Google MX records entirely; the MX lookup makes the double-routing problem immediately visible without any server log access.

Best Practices for MX Record Management

• Use exactly the MX records your provider specifies: Email providers publish exact MX hostnames and priority values in their documentation — copy them exactly, including trailing dots if your DNS editor uses zone file syntax.
• Remove old MX records completely during provider migrations: Leaving old MX records alongside new ones causes split-routing — some email goes to the old provider, some to the new. Remove old records before or simultaneously with adding new ones.
• Ensure MX targets are hostnames, not IPs: MX records must point to hostnames, not IP addresses — DNS standards prohibit using an IP directly in an MX record. If you accidentally add an IP, mail delivery will fail with a "invalid MX" error.
• Verify backup MX servers actually accept your mail: A backup MX at priority 20 only helps if that server can actually deliver to your mailboxes — test it by lowering its priority temporarily or by sending test email when your primary server is down.
• Monitor MX records with regular checks: DNS records can be accidentally deleted during DNS provider migrations or zone imports — schedule periodic MX record checks to catch misconfigurations before users report missing email.

Performance & Limits

• Returns all MX records: Domains with multiple MX records (primary + backup mail servers) display all entries with their priority values and target hostnames.
• Live authoritative results: Queries live public resolvers via DNS-over-HTTPS — results reflect current authoritative data, not cached stale records.
• Response time: MX record lookups typically return within 200-500ms — fast enough for rapid diagnostic iteration during active email outages.
• No command-line tools required: Works from any browser without dig, nslookup, or terminal access — useful for support teams and non-technical administrators.
• Any domain supported: Look up MX records for any domain on the public internet, including competitor domains to understand their mail infrastructure.

Common MX Record Mistakes to Avoid

• Adding MX records for subdomains when they belong at the root: MX records for email@company.com go on company.com, not mail.company.com — adding them to the wrong hostname means email delivered to your domain is never routed to these servers.
• Setting the same priority for all MX records: Multiple MX records with identical priority numbers cause random load balancing, not predictable failover — assign distinct priority values to establish a clear preference order.
• Forgetting to update SPF after adding MX records: If your new mail server's IP isn't in your SPF record, outbound email from that server will fail SPF checks and land in spam — always update SPF when adding or changing MX records.
• Confusing MX lookup with testing deliverability: A valid MX record means a mail server is configured to accept connections — it doesn't mean email will be delivered successfully. SMTP authentication, SPF, DKIM, and DMARC all affect final deliverability independently.

Privacy & Security

• Encrypted DNS queries: Uses DNS-over-HTTPS to protect lookup privacy from network-level interception.
• Public record data only: MX records are publicly accessible — any resolver on the internet can retrieve them. This tool queries the same public data.
• No logging: Domains queried are not stored or shared beyond the current browser session.
• No account required: Check MX records without registration or personal information.