When inbound mail starts bouncing, the first instinct is to check the MX records. That’s necessary but rarely sufficient. The MX might be correct in DNS while one of the IPs behind it has lost its PTR, or the SMTP listener has been firewalled off, or the host moved and DNS hasn’t caught up. The PortJar MX Diagnostics tool runs the whole chain in one shot — MX, A, PTR, and SMTP reachability on 25, 465, and 587 — so you can see in fifteen seconds whether a sending mail server has any real chance of delivering to you.
What the tool does
You give it a domain and it works through the top three MX hosts in priority order. For each one it resolves the A and AAAA records, captures the reverse DNS (PTR) for the first IP, and probes TCP/25, TCP/465, and TCP/587 from PortJar’s network to see whether the SMTP listener actually answers. The output groups everything per MX host so you can read a single hostname’s situation without losing context.
This is the same chain a sending mail server walks when it tries to deliver to you. If any link breaks, mail queues, retries, and eventually bounces. Seeing the failure here means a sender out on the internet is seeing it too.
How to use it
Open portjar.com/tools/mx-diagnostics, type the recipient domain (the part after the @, no scheme, no path), and read the result. There is one form field and no options to tune — the tool always probes the standard SMTP ports against the top three MX hosts.
If you only see one or two MX hosts in the output, the domain has only one or two published — that’s expected for many small operators. If a port shows as “closed” or “filtered,” that’s the answer about why a sender is having trouble, not a tool error.
When you’d reach for it
- A user reports bouncing mail. Before you start tcpdumping on the mail server, run the diagnostic from outside. If everything is green, the problem is on the sender’s side; if anything is red, you’ve isolated it without leaving the browser.
- You just cut over MX records. Confirm propagation has reached an external resolver, that the new IPs answer SMTP, and that PTR points back to a name that resolves forward — the three checks every receiver does.
- Reputation troubleshooting. A receiver is rejecting mail with “PTR doesn’t match.” The diagnostic shows you the PTR each MX IP actually returns, which usually exposes that one host out of three was never given a proper reverse record.
- Listener verification after a kernel or firewall change. OS upgrades and host firewall rules silently break inbound 25 more often than you’d expect. The probe answers “is the listener still accepting connections from the internet” without you having to sit on a remote shell.
- Vendor handoff. A managed mail provider claims they’ve moved the MX. The diagnostic gives you a copyable report — three hosts, their IPs, their PTRs, and the port states — that confirms or refutes the claim in one page.
What to make of the output
Three things need to be green for inbound mail to work: the MX must resolve to at least one IP, that IP must have a usable PTR, and one of the SMTP ports must answer. If any of those is broken, you have the answer about why mail is failing.
A “no PTR” finding on one host out of several is usually low-impact — the sending server will normally fall through to the next MX in priority order. A missing PTR on all hosts means a meaningful subset of senders will reject your mail outright on reputation grounds, even before they read a single header.
Closed TCP/25 with open TCP/465 and TCP/587 is common — many providers now route inbound mail through alternate ports — but a sender on the public internet will almost always try 25 first. If you’re seeing closed 25, confirm that’s a deliberate policy (and document the alternate path for senders) rather than an accidental firewall change.
A SERVFAIL or NXDOMAIN on the MX lookup itself is the worst shape: there is no inbound path at all. That’s a DNS problem, not a mail problem, and the fix is at the registrar or DNS provider.
For environments where inbound mail needs to stay reachable as DNS, firewalls, and mail platforms all change underneath, Stack Harbor handles the mail-path discipline as part of cPanel and WHM management.