Reverse DNS Lookup

What it does

Reverse DNS looks up the PTR record for an IP address — the hostname the address claims to be — and then performs a forward A or AAAA lookup on that hostname to confirm it points back to the same IP. This forward-confirmed reverse DNS (FCrDNS) check is the standard mail servers and security products use to decide whether an IP is presenting an honest identity. Pair this with IP Lookup for ASN/owner data, MX Lookup for the domain's mail config, and IP Blacklist Check for sending reputation.

When to use it

• Confirming that a mail server you operate has matching PTR and A records, since most major mailbox providers reject or aggressively filter outbound mail without FCrDNS. Cross-check the receiving end with MX Lookup.
• Investigating connection logs to identify whether a remote IP belongs to the hostname it presents in HELO/EHLO or TLS SNI.
• Checking whether a load-balanced cluster has consistent reverse DNS across every member, which is required for some compliance frameworks.
• Diagnosing why mail from a freshly provisioned cloud instance is being rejected — most cloud providers leave the default rDNS pointing at their own domain, not yours.
• Verifying that a CDN or proxy advertises a hostname under your control rather than the provider's default.

How to read the results

A successful PTR lookup returns a hostname; a successful forward lookup of that hostname returns an A or AAAA record matching the original IP. When both match, the IP passes FCrDNS and is treated as honestly identified. Use DNS Lookup on the returned hostname to see all of its other records. A missing PTR is a red flag for outbound mail and triggers immediate rejection at large providers. A PTR that resolves but whose forward record points elsewhere is worse than no PTR at all — it suggests spoofing or stale configuration. Only the network operator (your ISP or cloud provider) can publish PTR records, not you directly.

Common mistakes

• Setting an A record from your hostname back to the IP and assuming that's enough — the PTR also has to exist on the network operator's side. Verify with DNS Lookup.
• Leaving the cloud provider's default PTR (e.g., ec2-x-x-x-x.compute.amazonaws.com) and wondering why mail is being filtered as suspicious.
• Configuring forward DNS but forgetting that IPv6 mail traffic requires its own ip6.arpa PTR — the IPv4 PTR doesn't cover IPv6 sends.
• Pointing PTR at a generic shared hostname when sending mail; receivers expect the PTR to plausibly belong to the sending organization, not the hosting provider.
• Skipping a parallel IP Blacklist Check — even a perfect PTR won't save you if the IP is on Spamhaus.

# curl — JSON response (default)
curl https://internettimes.com:80/api/v1/reverse-dns/example.com \
  -H "Authorization: Bearer YOUR_API_KEY"

# Markdown response — ingest-friendly for agents
curl "https://internettimes.com:80/api/v1/reverse-dns/example.com?format=md" \
  -H "Authorization: Bearer YOUR_API_KEY"