Free MX Lookup

01 · Definition

What is mx lookup?

An MX lookup resolves the Mail Exchanger records published for a domain — the DNS entries that tell the internet which mail servers are responsible for receiving inbound email. Each MX record carries a hostname (the mail server) and a priority value (lower number = higher priority). When another server wants to deliver mail to you@example.com, it performs an MX lookup on example.com and connects to the highest-priority server first.

The tool above queries the MX records for any domain and returns every server, sorted by priority, along with the primary hostname. Read the in-depth MX lookup guide for what MX priorities mean, how fallback delivery works, and what to check when inbound delivery breaks.

02 · Process

How it works

1. 1Query the domain for MX records.DNS resolves the domain and returns all TXT records of type MX. If none exist, the domain cannot receive email via standard SMTP delivery.
2. 2Sort by priority.MX records carry a numeric priority. Lower numbers are tried first. If the highest-priority server is unreachable, sending servers fall back to the next in the list.
3. 3Surface the primary server.The record with the lowest priority number is the primary mail server. Its hostname typically identifies the email service provider — Outlook, Google Workspace, ProtonMail, or a custom server.
4. 4Return the full list.Multiple records at the same priority value are contacted in random order, providing load distribution. Records at higher priority values are fallback servers.

03 · Risk

Why it matters

MX records are the first thing a sending server checks when delivering email. If no MX records exist, delivery fails immediately with a bounce. If the records point to a decommissioned server or an incorrect host, inbound email silently disappears. Neither failure generates an obvious error on the sender side.

For regulated firms, MX records are also an intelligence signal. A counterparty still routing mail through a legacy on-premises server when their SPF record claims a cloud provider is a misconfiguration flag worth investigating before you onboard them. And for any firm migrating email infrastructure, MX record verification is a mandatory pre-cutover check.

04 · Use cases

Common ways to use this tool

• Provider identification. The primary MX hostname reveals which email service handles a domain — useful for filtering outbound lists by provider, diagnosing provider-specific delivery rates, or qualifying a vendor.
• Inbound delivery troubleshooting. When a domain stops receiving email, an MX lookup confirms whether the records exist, are correctly pointed, and have not expired or been deleted.
• Migration verification. After cutting over to a new email provider, verify the MX records have propagated and the old server is no longer listed before decommissioning it.
• Counterparty due diligence. Checking an incoming sender's MX records confirms their infrastructure matches their claimed identity — a quick signal for financial services compliance teams vetting communication channels.

05 · Interpretation

What to check in the result

Read the result in this order:

• Records exist. No MX records means the domain cannot receive email. Any send attempt will bounce immediately with a "no MX record" error on the sender's side.
• Primary host is correct. The lowest-priority hostname should point to the expected mail server — the cloud provider you migrated to, or your on-premises relay. A stale record pointing at a decommissioned server will cause delivery failures.
• Fallback records are present for critical domains. A single MX record with no fallbacks means any downtime on that server blocks all inbound email. Two or more records at different priorities provide resilience.
• No stale or duplicate records. Old providers' hostnames still appearing in the MX list can cause partial delivery to decommissioned servers, which then bounce or drop messages. Remove them after migration.
• Priority values are intentional. Multiple records at priority 0 or equal priorities distribute load randomly. Records at different priorities establish a clear primary/fallback order. Verify the configuration matches your intent.