Skip to main content
An MX lookup resolves the Mail Exchanger records published for a domain. MX records tell the internet which mail servers are responsible for receiving inbound email. Each record carries a hostname and a priority value — lower numbers are tried first. When any server wants to deliver email to you@example.com, it performs an MX lookup on example.com, connects to the highest-priority server, and falls back to lower-priority entries if the first is unreachable.
Run a one-off check at spotzee.com/tools/mx-lookup — enter any domain, get the MX record list and priority values. No signup.
This guide is for the API audience. Each call to POST /generic/email/mx-lookup deducts a small per-call amount from your Spotzee credit balance. See the Spotzee pricing page for live figures.

​
Why this matters

MX records are the first thing a sending server checks when delivering email. Missing MX records can indicate an inbound-mail configuration issue, although address-record fallback can apply. Records pointing at a decommissioned server after a migration means inbound email silently disappears. Neither failure is obvious on the sender’s side. For deliverability work, MX records are also an intelligence signal. The primary MX hostname usually reveals the email service provider — Google Workspace, Microsoft 365, Proofpoint, Mimecast, or a custom server. That matters when segmenting outbound lists, diagnosing provider-specific delivery rates, or vetting counterparties before onboarding. And for regulated firms, verifying inbound infrastructure is part of counterparty due diligence. A financial services firm still routing mail through a legacy on-premises server while claiming a cloud provider in their SPF record is a misconfiguration flag worth surfacing.

​
How it works

1

Query the domain for MX records

The API performs a DNS query for the domain’s MX records. All returned records are collected regardless of priority.
2

Sort by priority

The response preserves the MX records returned by DNS. Compare their numeric priority values yourself; lower values have higher preference.
3

Return the full list

The response contains exists and, when records are found, an mxRecords array of priority and hostname values. It does not identify a primary hostname.

​
What to watch for

  • No MX records. The API found no MX records. Check whether the domain intentionally uses address-record fallback or a Null MX record before drawing a delivery conclusion.
  • Stale records after migration. Old providers’ hostnames still in the MX list can cause partial delivery to decommissioned servers, which then bounce or silently drop messages. Remove old records promptly after cutover.
  • Single MX record with no fallback. Any downtime on that server blocks all inbound email. Critical domains should have at least one fallback record at a higher priority number.
  • Primary host doesn’t match expected provider. If SPF says Sendgrid but MX says a legacy on-premises host, the inbound and outbound paths are from different eras of the infrastructure. Likely a migration that wasn’t completed.
  • Equal-priority records for load balancing. Multiple records at the same priority are tried in random order. This is intentional for load distribution but can cause inconsistent delivery if the servers aren’t synchronised.

​
FAQs

An MX lookup queries the DNS records for a domain to retrieve its Mail Exchanger entries. Each MX record contains a hostname (the mail server that accepts inbound email for the domain) and a priority value. The lookup is the first step any SMTP server performs before attempting to deliver email to an address on that domain.
Lower priority numbers are tried first. A domain with records at priority 10 and 20 will have sending servers try the priority-10 server first. If that server is unreachable or returns a temporary error, they fall back to the priority-20 server. Equal priority values (e.g. two records both at priority 1) are tried in random order for load distribution.
Common causes: the domain was never configured for email, the MX records were deleted during a DNS migration, or the queried subdomain has no mail configuration of its own. A domain with no MX records may still receive mail through an address-record fallback, unless it publishes a Null MX record. Check the domain before treating an empty MX result as a delivery failure.
The primary MX hostname usually reveals the provider. Hostnames ending in .google.com or googlemail.com indicate Google Workspace. .mail.protection.outlook.com indicates Microsoft 365. .mimecast.com, .proofpoint.com, or .barracuda.com indicate third-party security gateways. Custom hostnames like mail.yourdomain.com indicate self-hosted or custom infrastructure.
MX records only control inbound delivery — they tell other servers where to send email addressed to your domain. They have no direct effect on outbound email. Outbound authentication is governed by SPF records and DKIM signing. Use the SPF lookup tool and email health check for outbound configuration.
This guide covers MX record structure and common failure patterns. For a full picture of your domain’s email authentication posture — covering MX, SPF, DKIM, DMARC, BIMI, MTA-STS, and blacklist status — run the email health check guide for the full audit walkthrough.

​
Try it

Run an MX record check at the free MX lookup tool for a one-off query, or call POST /generic/email/mx-lookup via the Extended API for batch domain audits and automated infrastructure checks.