MX lookup that knocks on every door.
Every MX by priority, every host resolved and reverse-checked, your provider fingerprinted. Then the half dig can’t reach — our probes connect on port 25, read the banner and test STARTTLS.
Four MX setups that lose mail
Every one of these answers dig. Every one passes a listing-only checker. Every one is losing mail, reputation, or both.
The PTR that says “pool”
Forward DNS says mail.caldmont.com; reverse says cust-45.pool.example.net. Big receivers score that mismatch on every connection this box makes — greylisting first, junk folder later.
FCrDNS: failThe backup nobody patched
Priority 20 points at a box last updated years ago — weaker filtering, older TLS. Spammers aim at the backup MX on purpose, because it’s the door nobody watches.
spam’s favorite doorThe IP pasted at 2 a.m.
An outage, a panic edit, and now MX 20 203.0.113.45 lives in your zone. MX data must be a hostname — conforming receivers skip it, which means the backup you think you have doesn’t exist.
RFC 5321 — not a hostnamePort 25, no STARTTLS
The server answers, encryption is never offered, and every message crosses the internet in cleartext. Peers that require TLS defer or bounce — and mail clients flag it to your recipients.
cleartext in 2026Six shapes an MX answer takes
The DNS answer is a line or five. What it commits your domain to differs wildly — two shapes look broken and aren’t, two look fine and are.
A provider set: a first door, a load-balanced pair, backups behind it. Equal priorities are round-robin by design — a feature, not a flag. This is what healthy looks like.
Null MX (RFC 7505): “this domain does no email — bounce now.” The deliberate, correct record for web-only and parked domains: senders get an instant answer instead of retrying for days.
Receivers fall back to the implicit MX rule (RFC 5321): they deliver to your A/AAAA record — the web server. It works until you move the website.
An IP literal where a hostname must go. Some receivers quietly try the address anyway; conforming ones treat the record as unusable. Your delivery now depends on who’s sending.
FCrDNS fail: the reverse record names an ISP pool or nothing at all. Receivers read it as “not a real mail server” — and this box sends every bounce and auto-reply you generate.
Port 25 answers but encryption is never on the table. Everything transits in cleartext, and TLS-requiring peers defer or bounce. One config line from fixed.
The reputation check inside reverse DNS
Forward-confirmed reverse DNS is a round trip: take the mail server’s IP, look up its PTR, resolve that name forward — and land on the same IP. One broken link and the trip fails. Receivers run it constantly:
- The trip: IP → PTR → hostname → A/AAAA → same IP. We walk it for every MX host, both directions.
- Google’s sender guidelines make a matching PTR a hard requirement for reaching Gmail; Microsoft weighs it in connection filtering.
- “But MX is inbound” — your MX box is never inbound-only. Bounces, out-of-office replies and forwards all leave from it. Its reputation is your reputation.
- Managed providers keep this immaculate for you. Self-hosting means owning the PTR — one support ticket to your ISP or host.
Provider fingerprints
what the MX pattern tells usWhat you can check yourself
The records are a dig away. The conversation isn’t — residential ISPs block outbound port 25, so the knock has to come from a network mail servers will talk to.
Common MX lookup questions
Type your domain above. We query its MX records, sort them by priority, resolve every hostname to IPv4 and IPv6, run the FCrDNS round trip on each address, fingerprint the mail provider from the pattern, and then connect to each server on port 25 from our probe network — reading the SMTP banner and testing STARTTLS. Free, no signup, a few seconds end to end.
Lower number = tried first. Senders work up the list only when the better-priority hosts don’t answer. Equal priorities are not an error — they’re round-robin load balancing, and large providers use them (Google’s classic set has two hosts at 5 and two at 10). The concern with multi-tier setups isn’t the numbers — the backup tier runs older software and looser filtering, which is exactly why spammers aim at it.
Forward-confirmed reverse DNS: your mail server’s IP must have a PTR record, and that PTR’s name must resolve back to the same IP. It’s cheap proof that whoever controls the IP also controls the name — spam cannons on hijacked ranges usually can’t manage it. Google’s sender guidelines make a valid, matching PTR a hard requirement for delivering to Gmail, and most filters score it. And before you file this under “outbound only”: your MX host sends too — every bounce, every out-of-office, every forward. A broken round trip on the inbound box quietly taxes all of it.
A single MX with preference 0 and the root as its host — 0 . — defined by RFC 7505. It’s the standard way to declare “this domain does not accept mail.” Senders see it and return a permanent bounce in seconds, instead of falling back to the implicit MX rule and hammering your web server with retries for days. It’s the right record for parked and web-only domains — paired with v=spf1 -all and a DMARC reject policy so nobody can send as the domain either.
Surprisingly, yes. RFC 5321’s implicit MX rule says that when no MX exists, senders treat the domain’s A/AAAA record as an MX with preference 0 — so mail gets delivered to whatever answers on your web server’s IP. If that box happens to run an MTA, mail flows; people run production email on this accident for years. It’s fragile — move the website, lose the mail — and rarely intentional. Publish explicit MX records for real mail, or 0 . for none.
No — and it’s a common confusion. MX answers “where does mail to this domain go”; your outbound reputation lives in the sending IP, SPF, DKIM and DMARC, which our sibling tools grade one by one. Two exceptions: if you self-host, the MX box is the sending box, so its FCrDNS and TLS hygiene count double; and some receivers sanity-check that a domain sending mail can also receive it — a broken MX set fails that quietly.
The probe opens a TCP connection to each MX host on port 25, reads the greeting banner, sends EHLO, and checks whether STARTTLS is offered — then negotiates it and records the TLS version and certificate. It sends no mail: the conversation stops before MAIL FROM. You can’t do this from a home connection because residential ISPs block outbound port 25 to fight botnet spam. One caveat worth knowing: STARTTLS on port 25 is opportunistic — an on-path attacker can strip the offer. MTA-STS is the lock; our TLS Version Checker walks every protocol version your server will actually speak.
Free tools are just the start.
Uptimia keeps your sites healthy.
Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.