Reverse DNS Lookup

What is reverse DNS?

Reverse DNS (rDNS) is the reverse direction of normal DNS. Where forward DNS maps a name (kernelhost.com) to an IP address, reverse DNS maps the IP back to a name. The record type for this is PTR (Pointer). Reverse names live in two dedicated namespaces: in-addr.arpa for IPv4 and ip6.arpa for IPv6, each constructed from the IP in reverse octet or nibble order.

Example: the IP 8.8.8.8 becomes 8.8.8.8.in-addr.arpa. A PTR query against this name returns the hostname (dns.google in this case). For IPv6 the address 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, each hex nibble of the address shown separately and reversed.

Who controls a PTR record? The owner of the IP range, which is usually the upstream provider, hosting company or ISP. Domain owners cannot set PTR records themselves unless they get the IP range delegated to them (rare, possible for /24 blocks or larger). For a single VPS the PTR is set in the hosting control panel or via support ticket.

FCrDNS: forward-confirmed reverse DNS

FCrDNS is the most important reason to care about PTR records. The idea is simple: the PTR record gives you a hostname, then you resolve that hostname forward via A or AAAA, and the IP returned must match the original IP. If it does, the PTR is trusted. If not, the PTR is considered spoofed and is ignored by most modern checks.

Mail servers (Postfix, Exim, OpenSMTPD) and spam filters (SpamAssassin, rspamd, Postscreen) verify FCrDNS on every incoming connection. A FCrDNS fail typically adds 1.0 to 3.5 points to the spam score (often enough to land in junk), and many large providers (Google, Microsoft, Yahoo) reject the connection outright with a 550 error. Without a valid FCrDNS your mail server effectively does not exist.

FCrDNS verification by this tool: we read the PTR record, then resolve every returned hostname forward via A (IPv4) or AAAA (IPv6) and compare the returned IPs to the original IP. The badge tells you immediately: green for verified, yellow if there is no forward record at all, red on mismatch with the list of where it actually points.

Common use cases

What you actually need this tool for in daily ops:

• Mail server commissioning: Before you send the first mail from a new IP, the PTR must be set and FCrDNS must be green. Otherwise Gmail, Outlook and others will reject or junk-fold every mail you send. Verify here, fix in your provider control panel, verify again.
• Spam analysis: When you receive spam, look up the PTR of the source IP. A missing or broken PTR is a strong signal for spam. A PTR that points to a generic ISP pool name (dsl-broadband-pool-... etc.) is another classic indicator.
• Log analysis and forensics: An IP shows up in your logs. Who is it? rDNS gives you the hostname (often something like ec2-..., crawler-..., cdn-...) and combined with ASN tells you cloud provider, country and org. Decide in seconds whether it is a legitimate bot, a known cloud customer or something to block.
• Network operations: When debugging a traceroute, intermediate hops are shown by PTR. Routers along the path usually have descriptive PTRs (frankfurt-edge1.isp.net, lhr-core2.example.com etc.) that tell you the geographic and topological path your packet takes.
• Abuse reports: Need to file an abuse report? The PTR plus ASN tell you which provider to contact (abuse@<org>). Without rDNS you would have to look up the IP in RIPE/ARIN whois databases which is slower.

How to set a PTR record

PTR records are not set on your authoritative nameserver for the forward zone. They are set on the reverse zone, which is delegated by the IP owner (ARIN, RIPE, APNIC, LACNIC, AfriNIC) down to the company holding the IP block. For a single VPS or dedicated server, this means: ask the hosting provider to set the PTR, do not try to set it on your own DNS panel.

Most hosting providers offer self-service PTR management in the customer portal. For KernelHost VPS and dedicated servers, the rDNS field is available directly in the server management panel and PTR changes go live within 5 to 10 minutes. For colocated IPs the standard process is a support ticket with the desired hostname per IP.

Best practice for mail: PTR and HELO must match. If your mail server announces itself as mail.example.com (HELO mail.example.com), then PTR for the IP must be mail.example.com, and mail.example.com must A-resolve back to the IP. All three lined up = FCrDNS green = clean reputation.

rDNS at KernelHost

Every KernelHost VPS, dedicated server, mail and Minecraft server comes with self-service PTR management for both IPv4 and IPv6. You set the hostname per IP in the control panel and the change is live within minutes, no support ticket needed. For IP blocks (/29 or larger) the entire reverse zone can be delegated to your own nameservers.

Our DNS plane runs as DNSSEC-signed Anycast in Frankfurt and Vienna so PTR lookups from anywhere in the world resolve in tens of milliseconds. If you are about to commission a mail server on a new IP and want the cleanest possible reputation from day one, the combination of KernelHost rDNS + DKIM/SPF/DMARC in the same panel saves you the typical first-day debugging cycle.

Frequently asked questions