MX Record Lookup: Troubleshooting Email Delivery

2026-03-28

MX (Mail Exchanger) records are the DNS records that tell the internet which mail servers handle email for your domain. When someone sends an email to [email protected], their mail server queries the DNS for example.com's MX records to find out where to deliver it.

Getting MX records wrong — or not having them at all — means email silently fails to arrive.

What an MX Record Looks Like

An MX record has two fields: priority (a number) and mail server hostname (an FQDN).

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Lower numbers mean higher priority. Mail servers try the lowest-priority value first. If it's unavailable, they fall back to the next one. This lets you configure a primary and backup mail server.

Looking Up MX Records

You can look up MX records with the DNS Toolkit API:

curl -X GET "https://dns.toolkitapi.io/v1/dns/lookup?domain=example.com&type=MX" \
  -H "X-API-Key: YOUR_KEY"

The response includes each MX record with its priority, hostname, and the TTL:

{
  "records": [
    { "priority": 10, "exchange": "mail1.example.com.", "ttl": 3600 },
    { "priority": 20, "exchange": "mail2.example.com.", "ttl": 3600 }
  ]
}

Common MX Troubleshooting Scenarios

No MX Records Found

If a domain has no MX records, email is undeliverable (unless the sending server falls back to an A record, which is rare and not reliable). Check that your MX records have been published and that the TTL has expired.

Wrong Hostname

MX records must point to a hostname, never an IP address. The hostname itself must have an A or AAAA record. If mail1.example.com has no A record, delivery will fail with a "Host not found" bounce.

Missing Trailing Dot

In raw zone files, hostnames require a trailing dot (mail1.example.com.). Without it, many DNS editors append the zone name, turning mail into mail.example.com.example.com. Always verify the resolved hostname with a live lookup.

TTL Too Long

If you're migrating email providers, a high TTL (e.g. 86400 = 24 hours) means old MX records stay cached across the internet for a day after you change them. Before a migration, lower the TTL to 300 (5 minutes) at least 24 hours in advance.

Verifying the Full Email Chain

An MX record lookup is just the first step. A complete email deliverability check also verifies:

SPF record — authorises which servers may send on your behalf
DKIM — adds a cryptographic signature to outbound mail
DMARC — specifies what to do with mail that fails SPF/DKIM

You can check all of these together with the Email Auth endpoint:

curl -X GET "https://dns.toolkitapi.io/v1/email/auth?domain=example.com" \
  -H "X-API-Key: YOUR_KEY"

Checking MX Records Programmatically

For bulk checks or monitoring pipelines, iterate over a list of domains and alert when MX records are missing or change unexpectedly:

import httpx

API_KEY = "YOUR_KEY"
domains = ["example.com", "example.org", "example.net"]

for domain in domains:
    resp = httpx.get(
        "https://dns.toolkitapi.io/v1/dns/lookup",
        params={"domain": domain, "type": "MX"},
        headers={"X-API-Key": API_KEY},
    )
    data = resp.json()
    records = data.get("records", [])
    if not records:
        print(f"WARNING: {domain} has no MX records")
    else:
        primary = min(records, key=lambda r: r["priority"])
        print(f"{domain}: primary MX is {primary['exchange']} (priority {primary['priority']})")

Summary

MX records are fundamental to email delivery. The most common failure modes are missing records, incorrect hostnames, and stale caches after a migration. Combine MX lookups with SPF, DKIM, and DMARC checks for a complete picture of email deliverability for any domain.

Try it out

Browse Tools →