Mail Servers: MX Records and Reverse DNS
When someone sends mail to you@example.com, their server looks up the MX (mail exchanger)
records of example.com to find out which servers accept mail for it. If those records are
missing or point at names that no longer exist, mail is delayed, bounced or lost, often without
anyone noticing for a while.
MX records and priorities
Each MX record has a priority (lower is preferred) and a host name:
example.com. MX 10 mx1.mail.example.net.
example.com. MX 20 mx2.mail.example.net.
Senders try the lowest number first and fall back to the next one if it doesn’t answer. Records with the same priority share the load. An MX record must name a host, not an IP address, and that host needs its own A or AAAA record.
If a domain has no MX records at all, senders fall back to its A or AAAA record (RFC 5321, section 5.1), so mail may end up at your web server.
Domains that receive no mail
Publish a “null MX” (RFC 7505): a single MX record with
priority 0 and the host .. It tells senders straight away that the domain accepts no mail, instead
of letting them retry for days.
example.com. MX 0 .
Don’t add other MX records next to it. Pair it with v=spf1 -all and a DMARC p=reject record
(see Email Authentication).
Reverse DNS (PTR)
Reverse DNS maps an IP address back to a name through a PTR record. Receiving servers commonly check that a connecting server’s IP has a PTR name, and that this name resolves back to the same IP (forward-confirmed reverse DNS, FCrDNS). Google’s email sender guidelines require valid forward and reverse DNS for sending IPs. Small setups often send and receive mail on the same server, so a mail server without a PTR name is a delivery risk.
PTR records live in the zone of whoever owns the IP address, not in your domain’s DNS. You set them in your hosting or cloud provider’s panel, or ask them to do it.
How to fix
Google Workspace. Google’s current setup is one record:
example.com. MX 1 smtp.google.com.
Older setups with five aspmx.l.google.com records still work. Follow the values shown in your
Admin console.
Microsoft 365. The admin center shows your record, in the form:
example.com. MX 0 example-com.mail.protection.outlook.com.
cPanel and Plesk. If the hosting server handles your mail, the panel creates the MX record. If mail is hosted elsewhere, set the MX record to your mail provider and, in cPanel, switch Email Routing to “Remote Mail Exchanger” so the server stops delivering mail for the domain locally.
Cloudflare. MX records are always DNS only (they can’t be proxied), and the host they name must also be DNS only, because a proxied A record returns Cloudflare’s address, which doesn’t accept mail.
PTR on a VPS. Most cloud providers have a reverse DNS field per IP address. Set it to the
server’s mail name, for example mail.example.com, and make sure that name has an A record with
the same IP.
Verify
dig +short MX example.com
dig +short A mx1.mail.example.net
dig +short -x 203.0.113.25
How PerfoMetrix checks this
We query public DNS resolvers only. We never connect to your mail servers.
| Check | Result |
|---|---|
| Mail servers | passes when the first five MX hosts (by priority) all resolve to an IPv4 address |
| Reverse DNS | passes when every checked mail server IP has a PTR name |
- Mail servers fails when none of those hosts resolve and needs attention when some don’t. No MX records, or a null MX, is shown as information.
- An MX host that has only an IPv6 address is currently counted as not resolving.
- Reverse DNS looks at the first IPv4 address of each of the first three MX hosts. A missing PTR name needs attention. We check that the name exists, not that it resolves back to the same address, so test FCrDNS yourself with the commands above.