Reverse DNS Lookup: Check PTR and FCrDNS

TL;DR To check reverse DNS, look up the PTR record for an IP address, then resolve the returned hostname forward with A or AAAA. The check passes when the forward answer includes the original IP. For mail servers, also make sure the SMTP EHLO/HELO hostname is consistent with that PTR hostname. PTR records are usually controlled by the IP address owner, not your domain registrar.

Last updated: July 5, 2026

Use this guide when you are debugging a mail server, validating a new sending IP, checking a provider migration, or trying to explain why an IP resolves to a weird hostname. If you only need the record-type definition, start with what a PTR record is. If you need to test a list of IPs, use Bulk FCrDNS.

What reverse DNS actually checks

Normal DNS answers "what IP does this hostname use?"

dig mail.example.com A

Reverse DNS answers "what hostname represents this IP?"

dig -x 203.0.113.10

That reverse answer is a PTR record. RFC 1035 defines PTR as a domain-name pointer record and describes the IPv4 reverse namespace under IN-ADDR.ARPA. In practice, an IPv4 reverse lookup reverses the address labels and queries a PTR name like this:

203.0.113.10
10.113.0.203.in-addr.arpa.  PTR  mail.example.com.

IPv6 uses the same idea with reversed hexadecimal nibbles under ip6.arpa.

Reverse DNS by itself only proves that a PTR record exists. It does not prove that the hostname points back to the IP. For that, you need forward-confirmed reverse DNS.

The three checks that matter

For one IP address, use this sequence:

The forward match is the FCrDNS check: IP to PTR hostname, then hostname back to the original IP. Gmail's sender guidelines describe the same requirement: the public sending IP needs a corresponding PTR record, and the PTR hostname needs an A record for IPv4 or AAAA record for IPv6 that resolves back to the same sending IP.

For mail, the SMTP identity check matters because RFC 5321 says the domain name given in the EHLO command must be a primary hostname that resolves to an address record, unless the host has no name and uses an address literal. Receivers can and do use that identity as part of their abuse filtering.

Fast path: check reverse DNS with DNS Buddy

For a single IP, use Reverse DNS Lookup:

1. Paste an IPv4 or IPv6 address.
2. DNS Buddy queries PTR records across Google, Cloudflare, Quad9, and OpenDNS.
3. Compare the returned hostname across resolvers.
4. If a hostname appears, run a forward lookup for that hostname with DNS Lookup.

This catches two common problems quickly:

• One resolver has a stale or missing PTR answer while others agree.
• The PTR exists, but the hostname does not resolve forward to the same IP.

For many IPs, use Bulk FCrDNS. Paste up to 256 IP addresses and check whether each IP has a forward-confirmed reverse DNS result. That is the right workflow before DNS migrations, mail-server moves, IP warmups, and provider audits.

Command-line workflow

Use these commands when you need repeatable evidence for a ticket or incident note.

1. Check the PTR record

dig +short -x 203.0.113.10

Healthy output:

mail.example.com.

No output means there is no visible PTR answer from the resolver you asked. That might be a missing PTR record, a provider-side reverse-zone issue, or a resolver/cache problem. Query a few resolvers before opening a ticket:

dig +short @8.8.8.8 -x 203.0.113.10
dig +short @1.1.1.1 -x 203.0.113.10
dig +short @9.9.9.9 -x 203.0.113.10

2. Resolve the PTR hostname forward

Take the hostname from the PTR result and resolve it:

dig +short mail.example.com A
dig +short mail.example.com AAAA

The original IP should appear in the A answer for IPv4 or the AAAA answer for IPv6.

Healthy IPv4 example:

# PTR
203.0.113.10 -> mail.example.com.
 
# Forward
mail.example.com. -> 203.0.113.10

Broken example:

# PTR
203.0.113.10 -> mail.example.com.
 
# Forward
mail.example.com. -> 198.51.100.20

That is not forward-confirmed. The PTR points to a hostname, but that hostname points somewhere else.

3. Check the SMTP hostname if this is a mail server

If the IP sends mail directly, check what hostname the server announces. For a STARTTLS-capable SMTP server, this is a quick probe:

openssl s_client -starttls smtp -connect 203.0.113.10:25 -quiet

Then send:

EHLO test.example

You are looking for the hostname the server presents in its greeting and capabilities. In Postfix, this is usually controlled by myhostname and smtp_helo_name.

The clean pattern is:

PTR: 203.0.113.10 -> mail.example.com
A:   mail.example.com -> 203.0.113.10
EHLO/HELO: mail.example.com

The EHLO value does not always need to be byte-for-byte identical to the PTR hostname for every receiver, but making them consistent removes one more reason for a strict receiver or spam filter to distrust the connection.

How to interpret the result

Who can fix a PTR record?

Usually, not the person who controls the domain's normal DNS zone.

PTR records live in reverse DNS zones delegated to the owner of the IP block. That owner is usually:

• Your cloud provider
• Your VPS or dedicated hosting provider
• Your ISP
• Your colocation provider
• Your own network team, if you control delegated IP space

If your website DNS is hosted at Cloudflare, Route 53, DNSimple, or another DNS provider, that does not automatically mean you can set PTR there. You set the A/AAAA record for mail.example.com in your domain DNS. You set the PTR record for 203.0.113.10 wherever the IP owner exposes reverse DNS controls.

When opening a provider ticket, include this exact request:

Please set reverse DNS / PTR for 203.0.113.10 to mail.example.com.
 
The forward A record already resolves:
mail.example.com -> 203.0.113.10

If the forward record is not already in place, create it first. Some providers validate the forward match before accepting the PTR change.

Reverse DNS for mail servers

Mail is where reverse DNS stops being a nice diagnostic and starts affecting whether messages are accepted.

Gmail's sender guidelines say sending domains or IPs should have valid forward and reverse DNS records, also called PTR records. The same page says the sending IP must match the IP address of the hostname specified in the PTR record. Microsoft Outlook.com policies also state that connecting email servers must have valid reverse DNS records.

That does not mean PTR replaces SPF, DKIM, or DMARC. It is a different layer:

If PTR or FCrDNS fails, the receiver may reject or rate-limit the connection before the message gets deep enough for the rest of the authentication stack to matter.

Bulk checks before a migration

Reverse DNS is easy to miss during provider moves because it does not live with the normal zone export.

Before a DNS, mail, or infrastructure migration, build this inventory:

Use Bulk FCrDNS for the IP list, then keep the export with your migration notes. If the provider move changes outbound IPs, rerun the check after cutover. Do not assume the old PTR state followed the server.

Common mistakes

Mistake 1: Setting only the A record

Creating mail.example.com A 203.0.113.10 is only the forward side. It does not create reverse DNS. You still need a PTR record for 203.0.113.10.

Mistake 2: Setting PTR to a hostname that does not resolve

203.0.113.10 -> mail.example.com looks fine until mail.example.com returns no A or AAAA record. That is a dead-end PTR, not FCrDNS.

Mistake 3: Forgetting IPv6

If your MTA can send over IPv6, check IPv6 too. Gmail explicitly calls out IPv6 PTR/authentication errors in its sender guidance. A clean IPv4 path does not save a broken IPv6 path if the receiver sees your IPv6 connection.

Mistake 4: Auditing the wrong IP

Mail often leaves through a NAT gateway, relay, load balancer, or provider-controlled pool. Check the IP that recipients actually see, not just the private IP on your VM.

Mistake 5: Treating third-party ESP IPs as your job

If you send through Postmark, SendGrid, Mailgun, Amazon SES, or another ESP, they usually manage PTR and reputation for their sending IPs. Your job is to configure the domain-authentication records they ask for: SPF, DKIM, DMARC, bounce domains, and any tracking domains.

Reverse DNS checklist

Use this when a mail provider, customer, or security scanner says reverse DNS is broken:

[ ] Identify the public sending IP
[ ] Run PTR lookup for the IP
[ ] Confirm PTR returns a stable hostname
[ ] Confirm the hostname is not an unwanted generic provider name
[ ] Resolve the PTR hostname with A/AAAA
[ ] Confirm the original IP appears in the forward answer
[ ] Check IPv6 separately if the service sends over IPv6
[ ] Check SMTP EHLO/HELO hostname for self-hosted mail
[ ] Record who controls PTR for each IP
[ ] Retest from multiple resolvers after changes

FAQ

References

• RFC 1035: Domain Names - Implementation and Specification
• RFC 5321: Simple Mail Transfer Protocol
• Gmail sender guidelines
• Microsoft Outlook.com sender policies

Related: Reverse DNS Lookup · Bulk FCrDNS · PTR Record · DNS Migration Checklist