Reverse DNS Lookup

Find the hostname associated with an IP address (PTR record lookup).

Evidence ASSESSED

Checked against: Reverse DNS in in-addr.arpa / ip6.arpa · RFC 1035

RED TEAM 0 findings BLUE TEAM control did not hold

Our Reverse DNS Lookup resolves any IPv4 or IPv6 address to the hostname registered for it, then checks whether that hostname resolves back to the same address. This forward-confirmed check is exactly what mail receivers and security tools perform before trusting a connection.

What is Reverse DNS?

Reverse DNS is the process of resolving an IP address to a hostname — the opposite direction from the usual lookup. Where a forward lookup asks "what address serves example.com", a reverse lookup asks "what name is registered for 93.184.216.34".

The answer comes from a PTR record published in a special reverse zone: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The address is written backwards in that name, so 93.184.216.34 becomes 34.216.184.93.in-addr.arpa.

Crucially, reverse DNS is controlled by whoever owns the IP address block, not by the owner of the domain the name belongs to. That is why setting it usually means asking your hosting provider.

Resolves an IP address to a hostname using PTR records
Lives in the in-addr.arpa and ip6.arpa reverse zones
Controlled by the IP block owner, not the domain owner
Checked by mail servers before accepting a connection
Makes logs, traceroutes and monitoring output readable

Why Reverse DNS Matters

Reverse DNS is the first thing a receiving mail server learns about a connection, before any message content or authentication. A connecting IP with no reverse entry looks like a compromised home machine, and many large receivers close the connection on that basis alone.

The stricter test is forward-confirmed reverse DNS: the PTR must name a hostname, and that hostname must resolve back to the same IP. Passing it proves that the IP block owner and the domain owner both consented to the setup, which is a meaningful signal that an attacker on borrowed infrastructure cannot easily fake.

Missing reverse DNS is a leading cause of rejected outbound mail
Forward-confirmed reverse DNS is required by strict receivers
Generic ISP-assigned names are themselves treated as a spam signal
Security teams use reverse DNS to attribute traffic to an organisation
Readable hostnames make incident investigation far faster

How This Reverse DNS Lookup Works

The tool builds the reverse DNS name for the address, queries it, then verifies the answer in the forward direction.

Validates the IP address input against format and SSRF safety checks
Converts the address into its in-addr.arpa or ip6.arpa reverse name
Queries DNS for the PTR record at that name
Resolves the returned hostname forward to an A or AAAA record
Reports whether the forward result matches the original address

How to Use the Reverse DNS Lookup

Enter an IPv4 or IPv6 address in the input field
Run the lookup to perform a live reverse query
Review the hostname returned for that address
Check the forward-confirmation result shown alongside it
For mail servers, confirm the name matches your HELO hostname

Understanding Your Reverse DNS Results

The lookup returns a hostname and a verification status. Here is how to read them:

Field / Value	Meaning
`Hostname`	The name registered for this address. For a mail server it should be a hostname on a domain you control and should match your HELO announcement.
`Forward-confirmed`	Whether the hostname resolves back to the same IP. Passing this check is what strict mail receivers require. Failing it is treated much like having no reverse DNS at all.
`No PTR record`	The address has no reverse entry. Harmless for a web server, but it will cause widespread mail rejection for a sending server.
`Generic ISP name`	Names containing dynamic, pool, dsl, cable or the address digits are provider defaults. They mark the address as residential and attract aggressive filtering.
`Cloud provider name`	Defaults such as ec2-203-0-113-45.compute-1.amazonaws.com identify the host as generic cloud infrastructure. Replace them with your own hostname before sending mail.

Common Problems & How to Fix Them

The address has no PTR record. For a mail server this will cause rejections at most large receivers.

You cannot fix this in your own DNS zone — reverse DNS is delegated to the IP block owner. Use your hosting provider control panel, where the field is usually labelled reverse DNS or PTR, or open a support ticket. AWS, Azure, Google Cloud, DigitalOcean, Linode and Hetzner all support this.

The PTR names a hostname, but that hostname does not resolve back to this address.

Add an A record for the hostname named in the PTR, pointing to the same IP. If the hostname points at a different address — common after a server migration — update whichever side is wrong so both directions agree.

Cloud and ISP defaults identify your server as generic infrastructure and attract filtering.

Set a custom PTR matching a hostname on your own domain, then add the matching forward A record. On some consumer connections providers refuse to set custom reverse DNS at all — in that case, relay outbound mail through a dedicated sending service rather than sending directly.

Reverse DNS is only the first check. Confirm the IP is not blacklisted, that SPF authorises it, that DKIM signing is in place and that DMARC is aligned.

A newly allocated address may also carry reputation damage from a previous tenant. Check blacklist status before assuming the configuration is at fault.

Best Practices

Set reverse DNS for every IP address that sends email
Ensure the hostname in the PTR resolves forward to the same address
Match the reverse DNS name to the hostname used in SMTP HELO
Use a hostname on a domain you control rather than a provider default
Verify reverse DNS immediately after any IP change, before sending mail
Keep one PTR record per address to avoid inconsistent validation results
Check reverse DNS for newly allocated addresses as part of provisioning

Security Recommendations

Never treat reverse DNS as proof of identity — the IP block owner can set any hostname they like
Always verify forward-confirmed reverse DNS when using reverse lookups in security logic
Avoid hostnames that leak internal roles, such as db-primary-internal.example.com
Remove reverse entries for addresses you have released so the next tenant does not inherit your name
Be aware that attackers use reverse DNS to map an organisation address space during reconnaissance
Do not use reverse DNS alone for access control decisions

Frequently Asked Questions

A reverse DNS lookup resolves an IP address to a hostname, the opposite of a normal DNS query. It works by querying a PTR record in the in-addr.arpa or ip6.arpa zone, where the address is written in reverse order.

Reverse DNS is controlled by the owner of the IP address block, not by you. Use your hosting provider control panel, where the setting is usually labelled reverse DNS or PTR, or open a support ticket. It cannot be set from your own DNS zone.

Most large mail receivers check reverse DNS as the very first signal about a connecting server. An IP with no reverse entry resembles a compromised consumer machine, so many receivers reject the connection before the message is even offered.

It means the PTR record resolves to a hostname, and that hostname resolves forward to the same IP address. Both directions must agree. It proves that the IP block owner and the domain owner cooperated, which is harder to fake than either record alone.

Effectively yes. Reverse DNS is the process, and the PTR record is the DNS record that makes it work. The terms are used interchangeably in practice.

No. Browsers never perform reverse lookups, so a website works without it. It is useful for readable server logs and network diagnostics, but only mail servers genuinely require it.

Not on its own. Whoever controls the IP block can set the PTR to any hostname, including one they do not own. Always confirm the hostname resolves forward to the same address before relying on it.