← Frankys Web GitHub Contact
Frankys Web Mailtools

Check and understand email configurations

MX Lookup

Resolve MX records sorted by priority, with the IP addresses of the mail servers.

A domain's MX record (Mail Exchange) states which servers accept email for it. A sending mail server queries the MX records, sorts them by priority and tries delivery at the host with the lowest value first. The MX record is therefore the first step of every email delivery and a common cause when mail to a domain does not arrive at all.

What this tool checks

It resolves all of the domain's MX entries, sorts them by priority and determines the A and AAAA addresses of each mail server. It also checks the typical error sources: an MX target that is directly an IP address or points to a CNAME (both against the rules per RFC 1035 and RFC 2181), mail servers without a resolvable address, IP addresses in ranges that are not publicly reachable, and the reverse DNS of each MX IP with FCrDNS confirmation (the PTR name must resolve forward to the same IP again). It also evaluates Null MX per RFC 7505 and the contradiction when a Null MX and real MX records sit side by side. The TTL of the MX record is shown as well.

Reading the result

Green stands for at least one MX record that points to a resolvable, publicly reachable host name, ideally with confirmed FCrDNS. Warnings appear for missing FCrDNS, for generic-looking PTR names, for a single MX with no fallback target, and for IP targets or CNAME targets. A note appears when no MX record exists at all (delivery then falls back to the domain's A record, the implicit MX per RFC 5321) or when a Null MX is set. An error stands for contradictory records or MX targets that cannot be resolved.

Background

The MX concept originates in RFC 974 and is today described in RFC 5321 section 5 (address resolution, implicit MX, priority order). RFC 2181 section 10.3 forbids MX targets that point to CNAMEs. RFC 7505 defines the Null MX (0 .) for domains that deliberately receive no mail. The requirement for valid reverse DNS on connecting mail servers comes from the practice of the large receivers, not from a single RFC.

Common problems and how to fix them

  • No MX record. For a domain that is meant to receive mail, set at least one MX entry pointing to the mail server's host name. Do not rely on the implicit MX through the A record, many senders expect a real MX.
  • MX points to a CNAME. Often set up wrong with cloud mail providers. The MX target must be a host name with its own A or AAAA record. Enter the MX host name given by the provider directly, do not put a CNAME in between.
  • Only one MX host. If it fails, mail piles up in the senders' queues and bounces as undeliverable after a few days. Add a second MX with a higher priority number that points to a separate server or the provider's backup service.
  • No or generic reverse DNS. If the MX IP's PTR entry is missing or carries a name automatically assigned by the host, receivers downgrade outgoing mail. Have the host set a PTR to the real MX host name and make sure that name resolves forward to the IP again (FCrDNS).
  • Null MX and real MX side by side. This is contradictory. Either the domain receives mail (then only real MX) or it does not (then only 0 .).

Common questions

What does the number before the MX host name mean?
The priority. Sending servers try the lowest value first; equal values are distributed at random and thereby act as load balancing. A second MX with a higher number serves as a fallback target if the first is unreachable.
May an MX record point to a CNAME?
No. RFC 2181 forbids this explicitly; the MX target must be a host name with its own A or AAAA record. Some sending servers fail delivery otherwise, others tolerate it. Only a direct host name is reliable.
What is FCrDNS and why does it matter?
Forward-Confirmed Reverse DNS: the PTR name of an MX IP must resolve, via an A or AAAA record, back to exactly that IP. Many receiving servers treat connections without valid FCrDNS as suspicious and delay or block them.
What is a Null MX?
The entry 0 . per RFC 7505. It states explicitly that the domain receives no email, useful for send-only, brand or parked domains. Senders then abort delivery immediately with a clear error message.
Do I need a backup MX?
Not necessarily. Modern senders keep undeliverable mail in the queue for several days and retry. A second MX only helps if it runs on independent infrastructure; a backup that just forwards the same delivery mostly adds extra spam acceptance.
Why does mail to my domain not arrive even though the MX is set?
Common causes: the MX points to a host without a matching A record, the target is a CNAME, the mail server accepts no connections on port 25, or the receiving side rejects due to missing reverse DNS. The SMTP Test checks the connection to the MX hosts shown here directly.