MAIL SERVER DIAGNOSTICS

Mail Server Diagnostics

Enter a domain to see how senders will route mail to it. The tool lists MX priorities, checks that each target resolves, and examines the reverse DNS of the addresses behind them.

Run MX records check

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What the check covers

When a server wants to deliver mail to [email protected] it asks DNS for the MX records of example.com, sorts them by preference number and tries the lowest first. This tool performs that lookup, then examines what it finds: the targets, whether they resolve, whether they are CNAMEs or non-public addresses, whether the list is redundant, and whether each address has a matching reverse DNS name.

If a domain has no MX record at all, RFC 5321 says senders fall back to the domain's own address records, the implicit MX. The tool reports that case explicitly rather than calling the domain mail-less.

How to read the result

The table lists priority, target host, a provider guess where the host name is recognised, the resolved addresses and a short list of checks per row. Lower numbers are preferred; equal numbers share load. Redundancy is judged by distinct hosts, so two records pointing at the same host name count once. Several hosts from one provider are noted, since such providers normally run redundant servers behind their own names.

A null MX (0 ., RFC 7505) is a deliberate statement that the domain accepts no mail. The tool treats it as a pass and the other mail checks as not applicable, because there is no server to test. Reverse DNS is shown as forward-confirmed when the PTR name resolves back to the same address; this is informational, and many receivers use it as one reputation input for the servers that send mail, which matters if the MX hosts also send.

Common problems

  • Target does not resolve. An MX target with no A or AAAA record cannot be reached. If every target is unresolvable, delivery fails.
  • MX points to a CNAME. RFC 2181 and RFC 5321 expect an MX target to be an address-bearing name, not an alias. Some senders cope; others do not.
  • Target resolves to a private address. Addresses from private ranges cannot be reached from the public internet.
  • One MX host only. If it is down, senders queue the message and retry rather than failing at once, but delivery is delayed.
  • Duplicate MX records. The same target repeated adds nothing.
  • Old provider left behind after a migration. A leftover low-preference record can steal mail.
  • Backup MX that accepts everything. It becomes a spam path unless it knows valid recipients.

How to change mail routing safely

Prerequisites: the exact MX names and priorities from your mail provider, and a way to test delivery from an outside mailbox. Operational risk: a wrong MX record sends inbound mail to the wrong system, and the mistake is cached for the record TTL. Rollback: keep the previous record set written down, lower the TTL a day or more before the change, and restore the old set if test messages do not arrive.

  1. Record the current MX set with priorities and TTL.
  2. Lower the TTL ahead of the change window.
  3. Publish the new records and remove old ones only after you confirm the new system accepts mail for the domain.
  4. Re-run this check to confirm each target resolves and the priorities are as intended.
  5. Send a message from an outside account to a real mailbox and confirm arrival; then restore the TTL.

What this check does not show

It reads DNS and, for the address records, reverse DNS. It does not connect to the servers. Whether they accept mail, offer STARTTLS or present a valid certificate is covered by the SMTP test and the STARTTLS checker. Only up to 10 MX targets and 8 addresses are examined, and what you see is what this resolver returned at the time of the query.

Frequently asked questions

Does a lower MX number mean higher priority?

Yes. Senders try the lowest preference value first and move up only if it is unavailable.

What is a null MX?

A single record 0 . stating that the domain does not accept mail. Senders should stop immediately instead of retrying for days.

Do I need reverse DNS on my MX hosts?

It is not required to receive mail, but the check is informational and matters when the same addresses also send outbound mail.

Can the MX target be an IP address?

No. The target must be a host name that has address records.

A domain has no MX record. Can it receive mail?

Possibly. Senders fall back to the domain's A or AAAA record. The tool tells you if that implicit MX is in use.

Does this prove mail will be delivered?

No. It proves only that DNS points somewhere sensible. Use the SMTP and STARTTLS tools to test the servers.

Written by DNS Tools editorial · Last updated 2026-10-09