MX and reverse DNS: the records that make a mail server exist

A domain only receives mail if it publishes MX records, and a server only keeps sending mail for long if its IP address has a consistent reverse DNS. These two mechanisms are the foundation on which SPF, DKIM, DMARC and MTA-STS are built.

The MX record#

An MX (Mail eXchanger) record names the server or servers responsible for receiving a domain's mail. Each entry carries a priority (an integer, the lowest being tried first) and a hostname, never an IP address directly.

example.com.    3600  IN  MX  10 mx1.example.com.
example.com.    3600  IN  MX  20 mx2.example.com.
mx1.example.com. 3600 IN  A   203.0.113.10
mx2.example.com. 3600 IN  A   203.0.113.11

A sending MTA contacts mx1 first; if it does not answer, it moves on to mx2. Two entries with the same priority are used alternately. To look the records up:

$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

When a domain outsources its inbound mail, the MX records point at the provider's servers. The most common shapes are aspmx.l.google.com for Google Workspace, <domain>.mail.protection.outlook.com for Microsoft 365, or the hostnames of an external spam filter placed in front of an on-premises mail system. It is from these MX hostnames that SenderRadar identifies the provider receiving a domain's mail.

Two special cases are worth knowing:

• No MX at all: RFC 5321 says that, with no MX, the MTA falls back to the domain's own A record. This works but signals a careless setup.
• Null MX (RFC 7505): a domain that never receives mail publishes example.com. IN MX 0 . to say so explicitly. MTAs then reject immediately instead of retrying for days.

Reverse DNS and the PTR record#

Reverse DNS goes the other way: it maps an IP address to a hostname. It relies on a PTR record published in the in-addr.arpa zone (IPv4) or ip6.arpa (IPv6), which is managed by whoever holds the address block, that is the hosting company or network operator, not the domain owner.

For the address 203.0.113.10, the octets are reversed:

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mx1.example.com.

$ dig +short -x 203.0.113.10
mx1.example.com.

Mailbox providers check the PTR of every inbound SMTP connection. An IP with no PTR, or whose PTR is a generic operator-assigned name (203-0-113-10.dyn.example-isp.net), is treated as a residential machine or a compromised host and is frequently refused before the 220 banner.

FCrDNS: closing the loop#

Forward-Confirmed reverse DNS (FCrDNS) requires that the name returned by the PTR resolves back to the original IP address:

1. 203.0.113.10 → PTR → mx1.example.com
2. mx1.example.com → A → 203.0.113.10

If both steps agree, the address is confirmed. A PTR pointing at a name whose A record returns a different address is worthless. Google, Microsoft and Yahoo require valid FCrDNS for any server sending in volume, and the name announced in EHLO should ideally be that same hostname.

What to check#

On the receiving side:

• Every MX hostname has an A record (and AAAA if IPv6 is used); an MX pointing at a CNAME is forbidden by RFC 2181 and mishandled by some MTAs.
• The MX servers actually answer on port 25 from the Internet, with a 220 banner and STARTTLS.
• Secondary MX servers accept mail for the domains concerned; a misconfigured secondary becomes an open relay or a black hole.
• TTLs are reasonable (one hour is common) so that a migration can happen without downtime.

On the sending side:

• Every sending IP has a PTR pointing at a name within the sender's or provider's domain, and that name resolves back to the IP.
• The PTR name, the EHLO name and the TLS certificate subject all line up.
• The PTR is requested from the hosting company as soon as an IP is provisioned, before any mail goes out.

Common mistakes#

• Putting an IP address as the MX target: the record is syntactically invalid and ignored.
• Leaving an old MX in place after a migration, so mail keeps landing on an abandoned server.
• Forgetting that the PTR is managed by the hosting company: the domain is perfect, but the IP stays anonymous.
• Sharing an IP between a website and a mail server, with a PTR pointing at the website's name: FCrDNS passes, but the identity is muddled.
• Publishing a priority-0 MX towards an external filter without closing port 25 on the internal server, which lets anyone bypass the filter.

Clean MX and reverse DNS records do not give a domain a good reputation on their own, but a domain without them will never earn one.