How a reverse lookup actually works
Forward DNS answers "what address does this name have?". Reverse DNS answers the opposite question, and it does it with an ordinary DNS query against a special namespace. To look up 8.8.8.8, a resolver reverses the octets and queries 8.8.8.8.in-addr.arpa for a PTR record. IPv6 works the same way but nibble by nibble: 2001:4860:4860::8888 becomes 32 reversed hex digits under ip6.arpa.
The crucial consequence is that PTR records do not live in your domain's zone. They live in the zone for the IP block, and that zone is controlled by whoever holds the allocation — your hosting provider, your cloud vendor, or your ISP. You can own example.com outright and still have no ability to publish a PTR for the address it points at. That is why the fix for a missing PTR is almost always a support ticket or a control-panel field at your provider, not an edit in your DNS editor.
Forward-confirmed reverse DNS (FCrDNS)
A PTR record on its own proves very little, because the IP block holder can point it at any name they like — including a name they do not control. Receivers therefore check both directions. FCrDNS means: the PTR for the IP returns a hostname, and an A or AAAA lookup of that hostname returns the original IP. Only a party that controls both the address block and the domain can produce that pair, which is what makes it a meaningful signal.
Read the full explanation of reverse dns (ptr) lookup results ↓Show less ↑
This tool performs both queries. The "Forward-confirmed" badge appears only when a returned hostname genuinely resolves back to the address you entered. If the PTR resolves but the forward record is missing or points elsewhere, you get a "PTR only — not confirmed" result, which most large receivers treat exactly like having no PTR at all.
# 1. Reverse: what hostname does the IP claim?
dig +short -x 8.8.8.8
# dns.google.
# 2. Forward: does that hostname point back?
dig +short dns.google A
# 8.8.8.8
# 8.8.4.4
# IPv6 works identically:
dig +short -x 2001:4860:4860::8888If step 1 prints nothing, no PTR is published. If step 2 does not contain the address from step 1, the pair is not forward-confirmed. Note that the forward record may legitimately list several addresses, as dns.google does above — one of them matching is enough.
The Yahoo and Microsoft requirements for senders
Reverse DNS moved from "good hygiene" to "hard requirement" when the large mailbox providers published explicit sender rules.
- Yahoo, in the sender requirements it announced jointly with Google and began enforcing in February 2024, requires that sending IP addresses have valid forward and reverse DNS (PTR) records. The rule was aimed first at bulk senders — those sending roughly 5,000 or more messages a day to their users — but Yahoo has been explicit that valid rDNS is expected of all senders, and low-volume senders without it are filtered more aggressively.
- Microsoft (Outlook.com, Hotmail, Live) has required a valid PTR record on sending IPs for years; its published Outlook.com policies state that mail from an address with no reverse DNS entry may be rejected outright, and a missing PTR is one of the standard reasons a delisting request through Microsoft's support process is refused. In 2025 Microsoft additionally began enforcing SPF, DKIM, and DMARC for high-volume senders to Outlook.com, on top of the existing rDNS expectation.
- Google applies the same forward-and-reverse DNS requirement to bulk senders under the rules that took effect in February 2024.
What a good PTR looks like
Receivers read the hostname, not just its existence. Aim for a name that identifies the machine and matches the domain it sends as:
| PTR value | Verdict | Why |
|---|---|---|
mail.example.com | Good | Identifies the service and the responsible domain; easy to forward-confirm. |
mta01.example.com | Good | Specific per-host name, still clearly yours. |
203-0-113-42.dsl.example-isp.net | Poor | Generic ISP template. Many receivers pattern-match names like this as dynamic residential space and reject or heavily filter mail from them. |
static.203.0.113.42.clients.example-host.com | Weak | Better than a dynamic-looking name, but it identifies the host, not you. Replace it with your own hostname. |
| No PTR at all | Fail | Treated as an unidentified sender by Yahoo, Microsoft, and Google. |
The PTR hostname should also match — or at least be consistent with — the name your MTA presents in its SMTP HELO/EHLO greeting. A mismatch between HELO name, PTR, and the forward record is a classic pattern in spam scoring rules. You can see the greeting your server actually sends with the SMTP connection test.
Common failures and how to fix them
- No PTR published. Open a ticket with whoever allocated the IP, or set it yourself in the provider console — most VPS panels have a "reverse DNS" or "rDNS" field on the IP. See Set a PTR record on your VPS.
- PTR exists, forward lookup missing. You set the PTR to
mail.example.combut never created the A record. Addmail.example.com. IN A <your IP>in your own zone — this half is yours to fix, and you can verify it with the A record lookup. - PTR points at a hostname whose A record moved. The server was migrated, the A record was repointed, and the PTR still names it. Update both together.
- IPv6 has no PTR while IPv4 does. If your MTA has a AAAA record it will send over IPv6, and receivers will check the IPv6 PTR. Google in particular is strict about this. Either publish a PTR for the v6 address or stop your MTA from using IPv6 for outbound mail.
- Multiple PTRs on one address. Legal, but avoid it: receivers may pick any of them, and only the ones that forward-confirm help you. One PTR per address.
- Change made, nothing visible yet. Reverse zones have TTLs like any other. Give it the zone's TTL — commonly one to four hours — before concluding the change failed.
Beyond email
Reverse DNS also shapes how logs read. Web servers, SSH daemons, and firewalls annotate connections with the PTR name, so a well-named block turns an unreadable list of addresses into a readable audit trail. Some FTP and IRC servers, and a number of enterprise VPN gateways, still refuse connections from addresses with no reverse entry. And when you are investigating an unfamiliar address, the PTR is often the fastest hint of who runs it — followed by an ASN lookup for the definitive answer, and a blacklist check if the address has been sending you mail.