MX Record Inspector
Resolve MX hosts, check A/AAAA addresses, validate PTR records, and verify FCrDNS for any domain.
Try an example: google.com · outlook.com · proton.me · zoho.com · example.com
Validation results
How this MX record inspector works
MX records (RFC 5321 §5.1) tell the rest of the internet which hosts accept mail for your domain, and in what order. Each entry has a preference value. Senders try the lowest preference first and fall through to higher values on connection failure. Two MX hosts give you redundancy. One MX host is a single point of failure for everything coming in.
Type a domain above and the inspector resolves every MX host, fetches its A and AAAA addresses, runs a PTR lookup on each one, and confirms the PTR resolves forward to the same IP. You get priority order, the IP set, the hostname each IP claims to be, and a pass/fail on the FCrDNS round trip. The Mail Stack card identifies the operator behind each MX (Microsoft 365, Google Workspace, Proofpoint, Mimecast, Fastmail, Zoho, and the long tail) which is usually faster than reading raw hostnames.
What is FCrDNS and why do receivers care?
Forward-confirmed reverse DNS is the round trip from IP to hostname (PTR) and back to the same IP (A or AAAA). Receivers use it as a basic sanity check before they accept a connection. Gmail, Yahoo and Outlook.com all reject mail outright from any IP whose PTR doesn't resolve forward, and rejection happens at SMTP connect, before SPF, DKIM or DMARC even get a look. Microsoft turned this into a hard requirement in May 2025; Gmail and Yahoo have enforced it since the February 2024 bulk-sender rules. Generic AWS EC2 PTRs (the ec2-…compute.amazonaws.com form) that don't match the EHLO name the server announces sit behind most "our mail server is on a clean IP but nothing delivers" tickets.
Our take: if you don't control the PTR, your hosting provider or ISP does. Ask them to set it to the hostname your server advertises in HELO/EHLO, then verify it forward-resolves back. The reverse DNS checker walks the round trip for a single IP if you want to test it in isolation.
CNAME at an MX target is not allowed
RFC 2181 §10.3 is explicit. An MX record must point at a hostname that has address records of its own, not at a CNAME alias. The pattern works on lookup, which is why people get away with it for a while, but Postfix in default config and Microsoft Exchange both reject mail to a CNAMEd MX target. The fix is straightforward: replace the CNAME with the actual A and AAAA records of whatever it points at.
What is a null MX?
RFC 7505 defines the null MX as the correct way to say "this domain refuses mail":
example.com MX 0 .Senders see it and fail fast instead of timing out or falling back to the A record. A null MX must be the only MX on the domain. Pairing it with a real MX is a misconfiguration the inspector flags. Use it on parked domains, on look-alike defensive registrations, and on any subdomain that exists only to publish DKIM keys or DMARC reports.
Why this matters now
MX hostnames are the input every modern mail-security policy keys off. MTA-STS lists them in the mx: directive. DANE publishes TLSA pins at _25._tcp.<mx>. TLS-RPT only emits useful reports when the underlying policy matches the live MX set.
What to do: any time you change MX hosts (new gateway, mail-server migration, ESP switch), update the MTA-STS policy file at the same moment. The most common reason an MTA-STS deployment starts rejecting mail in production is an MX change nobody mirrored into mta-sts.txt.
Where to go next
If the inspector flagged an FCrDNS failure on a single host, the reverse DNS checker walks the round trip one IP at a time. For how MX, A/AAAA and PTR fit together at the record level, see the DNS record types reference.
Frequently Asked Questions
Common questions about MX records, mail routing and reverse DNS.
What is a null MX (RFC 7505)?
A single record with priority 0 and a target of . (one dot). It tells senders the domain refuses mail, so they fail fast instead of timing out or falling back to the A record:
example.com MX 0 .Use it on parked domains, defensive registrations and any subdomain that exists only to publish DKIM keys or DMARC reports. It must be the only MX on the domain. Mixing a null MX with a real MX is a misconfiguration the inspector flags.
My MX host fails FCrDNS. Does that hurt deliverability?
Depends who runs the MX host, and the inspector grades the two cases differently.
If your MX points at a recognised provider (Microsoft 365, Google Workspace, Proofpoint, Mimecast, etc.), a broken reverse-DNS round trip on their host is cosmetic. Receivers check FCrDNS on the IP that connects to send mail, and with a provider your outbound leaves through their own, separately configured egress IPs. RFC 5321 doesn't require reverse DNS on an MX host at all. The inspector reports an info note and your grade is untouched.
If the MX is a host the inspector doesn't recognise (usually self-hosted, where the same box receives and sends), the failure counts. Strict receivers refuse mail from IPs whose PTR doesn't resolve forward to the same address, and the refusal happens at SMTP connect, before SPF or DKIM get a look. PTR records live with whoever owns the IP block, usually your hosting provider or ISP. Ask them to set the PTR to the hostname your server announces in HELO/EHLO. Once the round trip closes, the warning clears.
What to do: if outbound reputation is the worry, test the IPs that actually send your mail with the reverse DNS checker and the blacklist checker, not the MX hosts that receive it.