Reverse DNS lookup (PTR + FCrDNS)FCrDNS resolves the PTR hostname for an IP, forward-resolves that hostname, and confirms the original IP appears in the answer. This is the reverse-DNS check Gmail, Yahoo, and Outlook expect of sending IPs.
Look up the PTR record for an IP and confirm it forward-resolves back to the same address. Instant, free, plain English.
Quick answer: reverse DNS maps an IP address back to a hostname through a PTR record, the mirror of the forward A/AAAA lookup. This tool reads the PTR for an IPv4 or IPv6 address, then runs forward-confirmed reverse DNS (FCrDNS): it resolves that PTR hostname and checks the original IP appears in the answer. Give it a hostname instead and it resolves the address first, then checks reverse DNS for each IP. FCrDNS matters because Gmail, Yahoo, and Outlook expect sending IPs to pass it before they accept mail.
What this checks
Reverse DNS answers the opposite question to a normal lookup: given an IP, what hostname does its owner publish? The answer lives in a PTR record under a reversed-address zone. For IPv4 the four octets are reversed and suffixed with .in-addr.arpa (RFC 1035 §3.5), so 8.8.4.4 is queried as 4.4.8.8.in-addr.arpa. For IPv6 all 32 hex nibbles are reversed and suffixed with .ip6.arpa (RFC 3596 §2.5). This tool reads the PTR record(s) for the address you enter, then performs forward-confirmed reverse DNS (FCrDNS, defined in RFC 8499): it forward-resolves each PTR hostname and confirms the original IP is in the result. Enter a hostname and it resolves the A and AAAA records first, then checks reverse DNS for every address behind that name.
How to read the result
The verdict is one of three states. A pass means a PTR record exists and its hostname forward-resolves back to the same IP — the round trip closes. A fail means a PTR exists but the forward lookup of that hostname does not include the original IP, so the two halves disagree. "No PTR" means the address owner publishes nothing in the reverse zone. The PTR record(s) row shows the raw hostname(s) returned; an IP can have more than one PTR, though one is the norm for mail-sending hosts. Reverse DNS is delegated by the party that controls the IP block, usually your hosting or cloud provider, not by whoever runs the forward zone. So a failing or missing PTR is fixed at the IP owner, not in your normal DNS panel.
Common failures
No PTR on a cloud IP: many providers leave reverse DNS blank by default, and some only let you set it through a support request or a specific control-panel field. A mail-sending host with no PTR is the most common deliverability blocker here. PTR points at a generic provider hostname: ranges often ship with a default like 203-0-113-7.example-isp.net. That technically passes FCrDNS if it forward-resolves, but it does not match your sending hostname, and some receivers treat generic reverse DNS as a weak signal. FCrDNS fail: the PTR hostname resolves to a different IP, or to nothing at all, often because the forward A/AAAA record was changed or removed after the PTR was set. IPv6 without a PTR: providers frequently configure reverse DNS for the IPv4 address but skip the IPv6 one, which breaks sending to receivers that check the address the connection actually came from. Forward and reverse maintained by different teams: the PTR and the A record live in separate zones controlled by separate parties, so they drift apart when only one side is updated.
What this does not prove
A passing PTR is not proof of identity or authority. Per RFC 1912 §2.1, a PTR record is not authoritative for the forward name it points at — anyone who controls a reverse zone can publish a hostname they do not own, and the forward owner can point that name anywhere. FCrDNS only confirms the two records agree; it says nothing about whether the host is authorized to send mail for a given domain. That authorization comes from SPF, DKIM, and DMARC. A clean reverse DNS result also does not guarantee inbox placement: receivers weigh reputation, content, and authentication alongside it.
Common questions
What is a PTR record?
A PTR (pointer) record maps an IP address back to a hostname — the reverse of an A or AAAA record. It lives in a special reverse-lookup zone (in-addr.arpa for IPv4, ip6.arpa for IPv6) under the address rather than under the hostname, and is published by whoever controls the IP block.
What is forward-confirmed reverse DNS (FCrDNS)?FCrDNS resolves the PTR hostname for an IP, forward-resolves that hostname, and confirms the original IP appears in the answer. This is the reverse-DNS check Gmail, Yahoo, and Outlook expect of sending IPs.
FCrDNS is a two-step check defined in RFC 8499: take the IP, read its PTR hostname, then forward-resolve that hostname and confirm the original IP appears in the result. When the round trip closes, the reverse and forward records agree. Major mail receivers use it as a baseline trust signal for sending IPs.
Do I need a PTR record to send email?
It depends on the receiver. Gmail and Yahoo's bulk-sender guidelines expect sending IPs to have valid reverse DNS, and for IPv6 senders both Gmail and Outlook effectively require a PTR — Outlook rejects IPv6 mail from an address with no reverse DNS. For IPv4 a PTR is strongly recommended rather than universally mandated, but missing or generic reverse DNS reliably hurts deliverability.
How do I set up reverse DNS for my mail server?
Reverse DNS is set by whoever owns the IP address, usually your hosting or cloud provider, not in your domain DNS panel. Find the PTR or reverse-DNS field in their control panel (or open a support request) and point the IP at your sending hostname, then publish a matching forward A or AAAA record for that hostname so FCrDNS passes.