Browserside Network Tools
☰

Network Tools

More tools →

Guide

MX Record Guide

Understand mail exchanger priority, verify inbound mail routing, and troubleshoot missing delivery.

Open the tool

What it does

Mail exchanger (MX) records tell sending mail servers where to deliver email for a domain. An MX record contains a priority and a hostname, for example:

10 mx1.example.net
20 mx2.example.net

Lower numbers are tried first. If the preferred server cannot be reached, the sender can try a record with a higher number. Equal priorities allow senders to choose between hosts, but MX records are not a precise load balancer.

Run the lookup against the address domain, such as example.com for person@example.com. Do not enter a mailbox, URL, or the name of an individual mail server.

What this tool tells you

The lookup shows the public MX records in delivery order. It helps you verify that:

  • the domain publishes an inbound mail route;
  • the exchanger hostnames match the mail provider’s instructions;
  • priorities are sensible and backup routes are present when intended;
  • an old provider is no longer receiving new mail attempts.

A clean MX result narrows a delivery problem. If the expected records are present, move to hostname resolution, network reachability, SMTP behavior, and message rejection logs. If no explicit MX exists but the domain has an A or AAAA record, SMTP defines an implicit MX pointing to the domain itself. This tool labels that fallback as implicit. It is valid, but publishing explicit MX records is clearer and avoids surprising provider behavior.

Each exchanger hostname must resolve to an address. Open the DNS Lookup for every MX target and confirm it has the expected A and, if used, AAAA records. An MX target should be a hostname, not an IP address. It should not depend on a CNAME.

How it fits with other technologies

MX controls inbound routing. It does not authorize outbound senders and does not authenticate message contents.

  • A and AAAA records give senders an address for each MX hostname.
  • SMTP runs on the target server, normally on TCP port 25 for server-to-server delivery.
  • SPF authorizes hosts that send mail for the envelope sender domain. It can reference MX hosts, but it is a separate TXT policy.
  • DKIM signs messages so receivers can verify that signed content was not altered and that the signing domain accepts responsibility.
  • DMARC checks alignment between the visible From domain and SPF or DKIM, then publishes handling and reporting policy.
  • PTR or reverse DNS identifies the sending IP. Many receivers expect outbound servers to have consistent forward and reverse DNS.

Changing MX records does not automatically update SPF, DKIM, or DMARC. A mail migration often needs all four areas reviewed: inbound MX, outbound SPF sources, provider-specific DKIM keys, and DMARC alignment.

Troubleshooting unexpected results

  1. Use the mail domain. Look up the part after @, not mail.example.com unless addresses actually end in that subdomain.
  2. Compare with provider documentation. Hostnames, dots, and priorities should match exactly. DNS dashboards may append the zone name automatically, turning a mistaken relative value into mx.provider.example.example.com.
  3. Check delegation and caching. If the authoritative zone is right but this result is stale, wait for the old TTL to expire. Confirm the registrar delegates to the zone you edited.
  4. Resolve every target. An MX host with neither a usable A nor AAAA record is unusable. It does not need both. If an IPv6 address is published, verify that the SMTP service and firewall work over IPv6 too.
  5. Test TCP port 25 from an appropriate network. A correct DNS answer does not prove the server is reachable. Some consumer networks and cloud providers block port 25.
  6. Inspect the SMTP conversation. Use mail logs or a tool such as openssl s_client -starttls smtp -connect mx.example.net:25 to inspect the banner and STARTTLS. Do not use this to relay test mail through systems you do not control.
  7. Read the bounce. SMTP status codes distinguish unknown recipients, policy rejection, authentication failure, rate limiting, and temporary server errors.
  8. Check all priority levels. A forgotten backup MX can accept mail and queue or reject it differently from the primary.
  9. Check DNSSEC if answers fail intermittently. Broken signatures or a stale parent DS record can turn otherwise correct MX data into SERVFAIL for validating resolvers.

A single MX record containing 0 . is a Null MX declaration: the domain explicitly does not accept email. The tool preserves the . root label so it is distinguishable from a missing exchange. Do not replace it unless the domain should receive mail.

What this tool cannot prove

An MX lookup does not connect to the mail server. An implicit result only proves that address records exist; it does not prove the host accepts SMTP. The lookup cannot confirm that port 25 is open, TLS works, a mailbox exists, spam filtering accepts a message, or a provider has finished provisioning the domain. It also does not test outbound delivery.

The tool uses a public recursive resolver, so a recently changed record may remain cached. For a full diagnosis, compare the authoritative DNS answer, test each exchanger’s A and AAAA records, inspect SMTP connectivity, and use the sender’s bounce plus the receiving server’s logs.