PTR Record Lookup (Reverse DNS)

Find the pointer (PTR) record associated with an IPv4 or IPv6 address.

About Reverse DNS (PTR)

A Pointer (PTR) record is used in Reverse DNS (rDNS) lookups to resolve an IP address to a domain or hostname. This is the exact opposite of an A record.

Email Security: PTR records are extremely important for mail servers. Almost all major email providers (Google, Microsoft, Yahoo) will immediately flag or reject incoming email if the sending IP address does not have a valid PTR record that matches the sending hostname.

Our PTR Record Lookup performs a reverse DNS query on any IPv4 or IPv6 address, returning the hostname that address is registered to. PTR records are a hard requirement for mail server deliverability — most large receivers reject mail from IPs that have none.

What is a PTR Record?

A PTR (Pointer) record maps an IP address back to a hostname. It is the reverse of an A or AAAA record, which maps a hostname to an address.

PTR records do not live in your normal DNS zone. They are published in special reverse zones under in-addr.arpa for IPv4 and ip6.arpa for IPv6, and they are controlled by whoever owns the IP address block — your hosting provider, cloud vendor or ISP — not by your domain registrar.

That ownership split is why setting a PTR record usually means opening a ticket with your hosting provider or using their control panel, rather than editing your own DNS zone.

Maps an IP address back to a hostname — the reverse of an A record
Published under in-addr.arpa for IPv4 and ip6.arpa for IPv6
Controlled by the owner of the IP block, not the domain owner
Required by most major mail receivers for inbound mail acceptance
An IP address should normally have exactly one PTR record

Why PTR Records Matter for Email

PTR records are the single most common reason self-hosted mail is rejected. Gmail, Microsoft 365, Yahoo and most enterprise mail systems check whether the connecting IP has a PTR record, and many refuse the connection outright when it does not.

Stricter receivers go further and require forward-confirmed reverse DNS: the PTR must resolve to a hostname, and that hostname must resolve back to the same IP. A PTR that points at a name with no matching A record still fails the check.

Beyond email, PTR records make network diagnostics and log analysis dramatically more readable, turning raw addresses into meaningful names in traceroute output and server logs.

Missing PTR is the top cause of rejected mail from self-hosted servers
Forward-confirmed reverse DNS (FCrDNS) is required by strict receivers
Generic ISP PTR names are themselves a spam signal to many filters
Makes traceroute, logs and monitoring output human-readable
Used by security tools to attribute traffic to an organisation

How This PTR Record Lookup Works

The tool converts the address into its reverse DNS name and queries for a PTR record there.

Validates the IP address input against format and SSRF safety checks
Reverses the address into its in-addr.arpa or ip6.arpa form
Queries DNS for a PTR record at that reverse name
Resolves the returned hostname forward to check it matches the original IP
Reports whether forward-confirmed reverse DNS passes

How to Use the PTR Record Lookup

Enter an IPv4 or IPv6 address in the input field
Run the lookup to perform a live reverse DNS query
Review the hostname returned for that address
Check whether the hostname resolves back to the same IP
For mail servers, confirm the PTR matches your HELO hostname

Understanding Your PTR Lookup Results

A reverse lookup returns a hostname, or nothing at all. Here is how to read the outcome:

Field / Value	Meaning
`Hostname`	The name registered for this IP address. For a mail server it should be a real hostname you control, such as mail.example.com, and should match the name the server announces in HELO.
`Forward match`	Whether the returned hostname resolves back to the original IP. This is forward-confirmed reverse DNS, and strict mail receivers require it to pass.
`No PTR record`	The address has no reverse entry. For a web server this is merely untidy. For a mail server it will cause widespread rejection.
`Generic hostname`	Names like 203-0-113-45.dynamic.isp.example are default ISP entries. They signal a dynamic or residential address, and many filters treat mail from them as suspect regardless of authentication.
`Multiple PTRs`	More than one PTR for a single address is permitted but discouraged. Different receivers may pick different answers, producing inconsistent validation results.

Common Problems & How to Fix Them

Your outbound mail will be rejected or heavily filtered by most large receivers.

PTR records are set by whoever owns the IP block, so you cannot add one in your own DNS zone. Open a ticket with your hosting provider or use their control panel — AWS, Azure, Google Cloud, DigitalOcean and Hetzner all expose a reverse DNS field — and set it to the hostname your mail server announces in HELO.

Forward-confirmed reverse DNS is failing. The PTR points at a hostname, but that hostname has no A record pointing back, or it points somewhere else.

Add an A record for the hostname named in the PTR, pointing at the same IP address. Both directions must agree for the check to pass.

Default names containing words like dynamic, pool, dsl or cable mark the address as residential or dynamic. Many mail filters reject or downgrade mail from such addresses regardless of SPF and DKIM.

Request a custom PTR matching your own domain. If your provider will not set one — common on consumer connections — use a relay or a dedicated mail service instead of sending directly.

Your mail server announces one name at connection time but the PTR says another. Receivers treat the inconsistency as a spam signal.

Make all three agree: the HELO hostname, the PTR record, and the A record for that hostname. This trio is what receivers check.

Best Practices

Set a PTR record for every IP address that sends email
Ensure the PTR hostname resolves forward to the same IP address
Match the PTR hostname to the name your mail server uses in HELO
Use a hostname on a domain you control, not a provider default
Keep one PTR record per address to avoid inconsistent validation
Update the PTR whenever a server is rebuilt or an IP is reassigned
Verify reverse DNS immediately after any IP migration, before sending mail

Security Recommendations

Never treat a PTR record as proof of identity — the IP block owner controls it and it can name any hostname they choose
Verify forward-confirmed reverse DNS rather than trusting the PTR alone when using reverse DNS in security logic
Avoid PTR names that leak internal roles or infrastructure layout, such as backup-db-prod.example.com
Remove reverse entries for addresses you have released, since the next tenant inherits the reputation
Monitor for unexpected PTR changes on your address space, which can indicate a compromised provider account
Do not rely on reverse DNS for access control, as an attacker who controls their own IP block controls their own PTR

Frequently Asked Questions

A PTR record maps an IP address back to a hostname, the reverse of an A record. It is published in a special reverse zone under in-addr.arpa or ip6.arpa, and is controlled by the owner of the IP address block rather than the domain owner.

You cannot add one in your normal DNS zone. Reverse DNS is delegated to whoever owns the IP block, so you must set it through your hosting provider control panel or by raising a support ticket. Most cloud providers expose a reverse DNS field on each instance or elastic IP.

Most major mail receivers, including Gmail and Microsoft 365, check whether the connecting IP has reverse DNS. An address with no PTR record looks like a compromised host or botnet node, so many receivers refuse the connection before the message is even offered.

FCrDNS means the PTR record resolves to a hostname, and that hostname resolves forward to the same IP address. Both directions must agree. Strict mail receivers require it because it proves the IP owner and the domain owner cooperated in the setup.

Not for the site to work. Browsers never perform reverse lookups. It is useful for readable logs and diagnostics, but it is only strictly required for servers that send email.

Technically yes, but it is discouraged. Different resolvers may return different answers, producing inconsistent results in mail validation and security checks. Keep one PTR per address.

It should be a hostname on a domain you control, and it should match the name your mail server announces in HELO. It does not need to be your bare domain — mail.example.com is the conventional choice for a mail server.