Qualifying a mail server before sending
Major receivers reject or heavily penalise mail from an IP with no PTR, or a PTR that does not match the HELO name. This is the first thing to fix on a new sending IP.
Network & DNS🌐 YAS server-sideAPI availableintermediate
Reverse DNS Lookup
Finds the hostname(s) associated with an IP address via PTR records.
Processed by YAS · not stored
Ready to runInstant execution
Loading tool…
What does this tool do?
Finds the hostname(s) associated with an IP address via PTR records.
Why would I use it?
- You want to know which hostname points at an IP.
- You are debugging mail server rDNS requirements.
- You are mapping infrastructure.
Real-life example
Input
8.8.8.8
Output
dns.google
The PTR record resolves the reverse mapping.
Input → Process → Output → Next
- Input
- Enter an IP.
- Process
- YAS queries the PTR record for the address.
- Output
- Hostname(s), or 'no PTR record'.
- Next action
- For mail servers, ensure rDNS matches the sending hostname.
Common mistakes
- Expecting every IP to have rDNS (many do not).
- Confusing PTR with A records.
- Forgetting that rDNS is controlled by the IP owner.
What the result means
A PTR maps IP → hostname (the reverse of A/AAAA).
Privacy & security
Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.
API
Endpoint
POST https://yas.sh/api/v1/tools/reverse-dns
Request Header
Content-Type: application/json
cURL
curl -X POST "https://yas.sh/api/v1/tools/reverse-dns" \
-H "Content-Type: application/json" \
-d '{"ip":"8.8.8.8"}'JavaScript
const res = await fetch("https://yas.sh/api/v1/tools/reverse-dns", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"ip": "8.8.8.8"
}),
});
const data = await res.json();Python
import requests
r = requests.post("https://yas.sh/api/v1/tools/reverse-dns", json={"ip":"8.8.8.8"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| ip | string | Yes | IPv4 or IPv6 address |
| max | integer | No (default 5) | Max results (1–20) |
Success response
{ "ip": "8.8.8.8", "result": ["dns.google"] }PTR lookup — find hostnames for an IP.
Error responses
400 VALIDATION_ERROR— invalid input or unsupported option.413 PAYLOAD_TOO_LARGE— input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED— rate limit exceeded (60 req/min).
Limits
- Maximum input: 64 KB per request.
- Rate limit: 60 requests/min per IP address.
- Authenticated accounts benefit from higher tier quotas.
Reverse DNS Lookup: technical reference, use cases and FAQ
How Reverse DNS Lookup works
A reverse lookup asks which name is registered for an address by querying a PTR record in a special zone: IPv4 addresses are reversed and suffixed with in-addr.arpa (203.0.113.7 becomes 7.113.0.203.in-addr.arpa), while IPv6 uses nibble-reversed digits under ip6.arpa. Authority over that zone belongs to whoever was allocated the address block — your hosting provider or ISP — not to the owner of the domain the address serves.
Forward and reverse DNS are independent databases. A name resolving to an address implies nothing about that address resolving back, and the two can disagree indefinitely. Forward-confirmed reverse DNS — where the PTR name resolves forward to the original address — is the check that actually establishes a consistent pair, and it is what mail servers and log analysers rely on.
When to use it: real-world scenarios
Identifying who owns an address in your logs
A PTR often reveals the hosting provider or the crawler operator, turning an anonymous address into an actionable one.
Verifying a claimed search-engine crawler
Google and Bing document forward-confirmed reverse DNS as the verification method: the PTR must end in their domain and resolve forward to the same address.
Auditing a block of addresses before launch
Discovering that half your allocated range has no PTR is much better done before deliverability depends on it.
Pro tips
- PTR records are set by your address provider, not in your own DNS zone. Filing a request with them is usually the only path.
- Make the PTR match the HELO/EHLO name your mail server announces and ensure that name resolves back to the same IP — anything less fails FCrDNS.
- IPv6 PTR records are widely absent. If you send mail over IPv6 without one, prefer sending over IPv4 until it is in place.
- One address can legitimately have multiple PTRs, but many receivers only look at the first, so keep it to one meaningful name.
Limitations and edge cases
What this tool deliberately does not do, and where it will disagree with other implementations.
- Absence of a PTR is common and not itself an error — most consumer and cloud addresses have none or a generic provider-assigned name.
- A PTR is set by the address holder and can claim any name, which is why forward confirmation is required before trusting it.
- Results reflect a public resolver's view and may be cached; internal reverse zones are invisible.
- Generic provider PTRs (ec2-….compute.amazonaws.com) identify the platform, not the tenant.
Frequently asked questions
- Why does my IP have no reverse DNS?
- Because nobody created a PTR record for it. That record lives in the address block owner's zone — your hosting provider or ISP — so you must request it from them rather than adding it to your own DNS.
- Does missing reverse DNS affect email delivery?
- Substantially. Many receivers reject or spam-folder mail from IPs without a PTR, and most expect the PTR to match the HELO name and resolve forward to the same address.
- Can reverse DNS be faked?
- The PTR can say anything the address holder wants. That is why verification requires forward-confirmed reverse DNS: resolve the PTR name forward and check it returns the original address.
- Why do forward and reverse disagree?
- They are separate records in separate zones with separate owners. Many addresses legitimately serve a domain whose PTR points at the hosting provider instead.
Related tools