Forward DNS — name to IP — is the part most operators think about. Reverse DNS — IP back to name — is the part that quietly decides whether a brand-new mail server gets into the inbox or sits in a quarantine queue for a week. Gmail, Outlook, and most serious inbound mail platforms reject SMTP sessions from IPs whose reverse DNS does not forward-confirm. PortJar’s Reverse DNS Lookup is the one check that tells you, in one screen, whether you have set this up correctly.
What the tool does
You give it an IPv4 or IPv6 address. It queries the PTR record under in-addr.arpa (or ip6.arpa), reads the hostname returned, then forward-resolves that hostname back to an A or AAAA record. If the forward and reverse answers match, the mapping is forward-confirmed. If the PTR points to a name that doesn’t resolve, or resolves to a different IP, the tool flags it.
That last step — forward-confirm — is what separates a useful reverse DNS check from a half-answer. A registrar or hosting control panel can show you the PTR they set, but only the public DNS system can tell you whether your forward zone agrees. The mail receiver runs the same check from the open internet.
How to use it
Open portjar.com/tools/reverse-dns and paste the IP. Works for IPv4 and IPv6 — both matter for mail, because if you advertise an AAAA on the mail hostname and the v6 PTR is wrong, Gmail will fail you on v6 even when v4 is clean.
For a new IP you’ve just brought up for outbound mail, run this check the moment your provider says the PTR has been set. It is faster than tailing reject logs at the receiver, and it confirms what the receiver will actually see.
When you’d reach for it
- Bringing up a new outbound mail relay on a freshly allocated IP — confirming PTR is set and forward-confirms before pointing any real traffic at it. PortJar’s “email going to spam” troubleshooting guide walks through this as one of the first checks.
- A client complains that mail to Gmail or Outlook started bouncing with
does not meet IPv6 sending guidelinesormessages from your IP have been blocked. Reverse DNS is usually the first thing to verify. - After a server migration where the IP changed, confirming the PTR was updated on the new IP and the old PTR was cleaned up.
- During a log review, when an unfamiliar IP appears in access logs — a reverse lookup tells you whether the host is genuinely what it claims (forward-confirm) or whether it’s a spoofed claim.
- After PortJar’s MX Diagnostics flagged a PTR problem on one of the resolved MX hosts and you want to confirm the gap is in reverse DNS rather than forward.
What to make of the output
A forward-confirmed result with a sensible hostname (something like mail.example.com for an IP that belongs to your mail server) is the only answer you want to see. Anything else needs attention.
A PTR pointing to the hosting provider’s generic name — static.123.45.67.89.providerdomain.com — is technically forward-confirmed if the provider’s zone is set up right, but no inbound mail receiver will trust mail from provider-generic.example.net as much as mail from mail.yourdomain.com. Ask the provider to set a custom PTR matching the hostname you announce in HELO/EHLO.
A PTR that returns a name which doesn’t forward-resolve at all means the forward zone is missing the record. The fix is in the forward zone, not the PTR. Add the A (and AAAA if applicable) record so it matches.
A PTR that forward-resolves to a different IP than the one you queried is the classic misconfiguration after an IP shuffle. Fix the side that’s stale — usually the forward zone — and re-check.
No PTR set at all is the most common shape for IPs that have never sent mail. The hosting provider sets the PTR on most platforms, so this lives in their control panel or a support ticket, not your DNS console.
Stack Harbor verifies forward-confirmed reverse DNS as part of mail-server onboarding under Deployment Management.