DNS Diagnostics
Check PTR records, verify forward-confirmed reverse DNS, and explain whether a mail server or outbound IP has a trustworthy reverse DNS setup.
Fetches reverse DNS hostnames directly from the resolver path.
Confirms whether PTR hostnames resolve back to the same IP.
Helps explain failures that affect mail, abuse desks, and server trust.
Examples
Use this before troubleshooting SMTP reputation, outbound relay issues, or host identity mismatches.
Mail receivers, security tools, and abuse workflows often expect the PTR hostname to round-trip back to the same IP.
A PTR may exist but point at a hostname that resolves to a different IP, usually after renumbering or DNS drift.
One intentional PTR hostname, a matching forward lookup, and a hostname pattern that reflects the server role.
Reverse DNS stores hostnames in PTR records under reverse-mapping zones such as in-addr.arpa for IPv4 and ip6.arpa for IPv6.
Forward-confirmed reverse DNS means:
This check does not prove trust by itself, but it is a widely used hygiene signal in mail systems, abuse processing, and infrastructure operations.
Reverse DNS only asks for PTR records. FCrDNS goes one step further and checks whether the returned hostname resolves back to the same IP address.
Not always, but it often hurts reputation and can trigger stricter filtering. Many receivers expect outbound mail IPs to have sensible reverse DNS.
Yes. It is allowed, but multiple PTRs should be intentional because they can confuse identity-based checks and operational debugging.
The hostname may have been moved, deleted, or updated incorrectly. Reverse and forward DNS often drift apart during migrations or IP reassignments.