How to Read a PTR Record Like a Network Investigator — Email Forensics, ISP Naming Patterns, and FCrDNS

A PTR record is easy to fake — anyone who controls a server can set their PTR record to say anything — which is why email servers use Forward-Confirmed Reverse DNS (FCrDNS) rather than trusting PTR records alone, and why the difference between the two matters for email deliverability

The previous articles on this site covered reverse DNS basics, PTR records and email deliverability, IP geolocation, IPv4 vs IPv6 reverse DNS delegation, and FCrDNS verification. This article addresses using reverse DNS for network forensics — how reverse DNS lookup fits into network investigation workflows, what it can and cannot confirm, and the specific patterns that reveal infrastructure ownership.

What reverse DNS can and cannot tell you about a host

What reverse DNS reveals:

• The PTR hostname that the IP address's controlling party has configured
• The naming convention that reveals the hosting provider, ISP, or organization's infrastructure patterns
• Sometimes the geographic location embedded in the PTR hostname

What reverse DNS cannot confirm:

• That the IP address is legitimately controlled by the organization whose name appears in the PTR record
• That the PTR record reflects current ownership (stale records persist for months or years after IP reassignment)
• The actual geographic location of the host (network topology doesn't map neatly to geography)

The FCrDNS check (Forward-Confirmed Reverse DNS, also called double-reverse DNS) partially addresses the authenticity concern: it verifies that the PTR record's hostname resolves back to the original IP address. A PTR record claiming mail.example.com must have mail.example.com resolve to the original IP — otherwise the PTR is rejected as unverified. This prevents spoofing by requiring control of both the IP's PTR record and the hostname's forward DNS record.

Reading PTR naming conventions: ISP and datacenter patterns

Different organizations have different conventions for naming their IPs, and these patterns are often informative:

ISP consumer connections: typically include the IP address octets, a geographic indicator, and the ISP name. Examples:

• 1-234-567-890.hsd1.tx.comcast.net (Comcast US, Texas)
• host-92-21-100-45.as13285.net (A2 Networks, UK)
• Dynamic-looking names generally indicate residential or SMB internet connections.

Datacenter/hosting providers:

• ec2-54-12-34-56.eu-west-1.compute.amazonaws.com (AWS EC2, European region)
• 104.21.56.78.cloudflare.net (Cloudflare)
• static.123.234.45.56.clients.your-server.de (Hetzner, a German hosting provider)

Corporate or enterprise connections:

• mail.company.com (deliberate, named PTR for mail servers)
• fw01.dc1.company.internal (firewall in datacenter 1 — probably not a well-configured PTR for public IPs, but these appear)

Missing PTR records (no response or NXDOMAIN): common for newly-allocated IP space, misconfigured infrastructure, or hosting providers that don't automatically configure PTRs. For mail servers, a missing PTR typically causes email delivery failures.

Reverse DNS in email forensics: reading email headers

Email headers contain a chain of Received: headers added by each mail server that handled the message. Each Received: header typically includes the IP address and the PTR record of the connecting server:

Received: from mail.legitimate.com (mail.legitimate.com [203.0.113.42])
    by mx.recipient.com with ESMTP id abc123

What to check in a suspicious email's Received headers:

1. The IP address in brackets [203.0.113.42] — this is the actual connecting IP, which can't be spoofed
2. The hostname in parentheses (mail.legitimate.com) — this is the PTR record, which the sending server's connecting IP resolves to
3. Whether the PTR matches the from domain — mail.legitimate.com should be the PTR for an IP that belongs to legitimate.com's email infrastructure

Phishing and spam indicators:

• PTR record of a residential ISP for a claimed business email server (a comcast.net PTR for a "shipping company" notification)
• PTR belonging to a completely unrelated organization
• IP in a hosting provider known for spam-permissive policies
• No PTR record at all (NXDOMAIN)

Reverse DNS change notifications and security monitoring

PTR record changes can indicate infrastructure changes — intentional (migration to new IP space) or unintentional (IP reassignment after lease expiry, hostile takeover of IP space through BGP hijacking).

BGP hijacking relevance: when an attacker hijacks IP address space via BGP, they announce routes for IP blocks they don't legitimately control. The PTR records for those IPs (which are controlled by the legitimate address space owner, via the regional internet registry delegation) don't immediately change — creating a mismatch between the BGP announcement and the PTR records that can help detect the hijacking.

Reverse DNS monitoring: for IP addresses your organization controls (mail server IPs, web server IPs), periodically verify that PTR records remain correctly configured. A PTR that suddenly returns a different hostname — or stops returning any hostname — warrants investigation.

How to use the Reverse DNS tool on sadiqbd.com

1. For email forensics: look up the IP address from a suspicious email's Received: headers — the PTR record will reveal whether the sender is using a legitimate mail server IP or a residential/datacenter IP inconsistent with their claimed identity
2. For network investigation: reverse DNS is the first step in identifying unknown IPs in logs or network captures — the PTR often immediately identifies the hosting provider or ISP, narrowing down the likely ownership
3. Verify FCrDNS: after getting the PTR hostname, perform a forward DNS lookup on that hostname and confirm it resolves back to the original IP — this is the FCrDNS check that email servers perform

Frequently Asked Questions

Can I use reverse DNS to find out who owns an IP address that attacked my server? Partially — it reveals the controlling organization's infrastructure, not necessarily the attacker. A PTR like ec2-54-12-34-56.eu-west-1.compute.amazonaws.com tells you the attack came from an AWS EC2 instance in the EU-West-1 region — not who rented that instance. To identify the specific account that controls that IP, you'd need to contact AWS with a legal request (abuse report or law enforcement request), since AWS maintains records of which customer controlled which EC2 IP at which time. The PTR gives you the hosting provider to contact; the hosting provider (with appropriate legal process) can identify the customer.

Is the Reverse DNS tool free? Yes — completely free, no sign-up required.

Try the Reverse DNS tool free at sadiqbd.com — look up the PTR hostname for any IPv4 or IPv6 address instantly.