The Record That Isn't in Your DNS
You control example.com. You can add any record you like — A, MX, TXT, CNAME. You cannot add a PTR record for your server's IP address.
That record lives in a completely different zone, controlled by whoever owns the IP address block. Which is your hosting provider, your ISP, or a cloud platform — not you.
This is the structural fact behind most reverse DNS confusion, and it explains why setting up rDNS involves a support ticket rather than a DNS panel edit.
The Reversed Zone
Reverse DNS works by encoding an IP address as a domain name in a special zone.
For IPv4, the address is reversed octet by octet and appended to in-addr.arpa:
IP: 192.0.2.10
Query: 10.2.0.192.in-addr.arpa
The reversal exists because DNS names get more specific from right to left, while IP addresses get more specific from left to right. Reversing aligns the two hierarchies, so 192.in-addr.arpa can be delegated to whoever holds 192.0.0.0/8, and subdelegated downward.
Delegation follows address allocation. The regional internet registry delegates a block to an ISP, which delegates smaller blocks to customers. Your ability to set a PTR record depends on whether the block containing your IP has been delegated to you — and for a single address inside a provider's block, it almost certainly hasn't.
The Reverse DNS Lookup queries the PTR record:
- Enter the IP address.
- Read the hostname it resolves to, if any.
IPv6 Is the Same Idea, Much Longer
IPv6 uses ip6.arpa and reverses by nibble — a single hex digit — rather than by octet.
Address: 2001:db8::1
Expanded: 2001:0db8:0000:0000:0000:0000:0000:0001
Query: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
Thirty-two labels, one per hex digit, reversed.
Two practical consequences:
Delegation boundaries fall on nibble boundaries. A /48 delegation is clean — it lands on a multiple of four bits. A /49 or /51 doesn't, which makes delegation awkward.
Populating the zone is impractical by hand. A /64 contains 2⁶⁴ addresses. Providers typically generate PTR records dynamically or provide an API rather than maintaining a static zone.
Many IPv6 addresses simply have no PTR record, which is worth knowing when a lookup returns nothing — absence is common rather than exceptional.
Why Mail Servers Care
PTR records matter for one application above all others: outbound email.
Receiving mail servers commonly check whether the connecting IP has a PTR record, and many reject or heavily penalise connections from IPs that don't. The reasoning is that legitimate mail infrastructure is deliberately configured, while compromised residential machines sending spam generally aren't.
Several checks are applied:
Does a PTR record exist at all? Missing rDNS is a strong negative signal for a mail-sending IP.
Is it a generic ISP-assigned name? Hostnames matching patterns like host-203-0-113-45.dynamic.isp.example signal a dynamic or residential assignment. Many receivers treat these as unsuitable for direct mail submission regardless of what the sender is doing.
Does FCrDNS pass? This is the important one.
Forward-Confirmed Reverse DNS
A PTR record is an assertion made by the IP block owner. Anyone controlling a block can claim any hostname they like:
203.0.113.45 → mail.some-bank.example
Nothing stops that. The PTR record alone proves nothing.
FCrDNS closes the loop by checking both directions:
- Look up the PTR for the IP → get a hostname
- Look up the A/AAAA record for that hostname → get an IP
- Confirm it matches the original IP
Both halves must agree, and the two records are controlled by different parties — the reverse zone by the address block owner, the forward zone by the domain owner. Agreement means both parties concur, which is meaningfully stronger than either alone.
This is what mail servers actually check. A PTR record pointing at a hostname that doesn't resolve back is worse than no PTR record, because it looks like a misconfiguration or an attempt to appear legitimate.
Setting It Up Correctly
The sequence for a mail-sending server:
1. Choose a hostname you control. mail.example.com, not a name belonging to someone else.
2. Create the forward record first. An A record (and AAAA if you have IPv6) for that hostname pointing at your server's IP.
3. Request the PTR record from your provider. Cloud platforms usually expose this in their console; traditional hosts and ISPs often require a support request. You're asking them to set a record in their reverse zone.
4. Verify both directions. Query the PTR, then query the forward record for the returned hostname, and confirm the IP matches.
5. Match your SMTP banner. Your mail server's HELO/EHLO hostname should be the same name. A mismatch between the EHLO name and the PTR is another common check.
6. Do it for IPv6 too if your server has an IPv6 address and sends mail over it. Receiving servers check whichever address family the connection arrives on, and an IPv6 connection with no PTR is a frequent cause of "it works over IPv4 and not IPv6" delivery problems.
What rDNS Doesn't Prove
Reverse DNS gets over-read in security contexts, and the limits are worth being precise about.
It doesn't identify who is using the address. A PTR record reflects allocation, not activity. Cloud provider IPs get reassigned constantly, and today's occupant has nothing to do with the hostname pattern the provider set.
It's not evidence of ownership. The block owner sets it. That may be a hosting provider with thousands of customers, and the PTR tells you about the provider rather than the customer.
Generic patterns carry limited information. A residential ISP naming convention tells you the address is in a residential pool. It doesn't tell you whether the traffic is legitimate — plenty of legitimate traffic originates from residential connections, and plenty of malicious traffic originates from datacentre addresses with perfectly clean rDNS.
Records go stale. Reverse zones are updated less diligently than forward zones. A PTR record can reflect an allocation that ended years ago.
Residential proxy services deliberately route traffic through residential addresses, which means datacentre-versus-residential classification tells you less than it used to.
Absence isn't suspicious by itself. Many legitimate hosts have no PTR record, particularly on IPv6. It matters for mail servers specifically, not as a general trust signal.
The practical position: rDNS is one input among several. Useful for confirming what a mail server claims to be, weak as standalone evidence about anything else.
Reading a PTR for Investigation
When a PTR record does return something, the naming pattern often indicates the allocation type:
Structured, meaningful names — mail.example.com, smtp-out-3.example.net — suggest deliberate configuration by someone who controls both zones. Worth verifying with FCrDNS.
Names embedding the IP — 203-0-113-45.provider.example — indicate an automatically generated record. Common for hosting and residential pools.
Names containing allocation hints — words like dynamic, dsl, cable, pool, dhcp — suggest dynamically assigned residential addresses.
Cloud provider patterns — regional identifiers and instance references — indicate the address belongs to a cloud platform, and the actual user could be anyone.
No record — common, especially for IPv6, and not informative on its own.
In every case, verify with FCrDNS before drawing a conclusion, and treat the result as a starting point for investigation rather than an answer.
Practical Tips
Set up the forward record before requesting the PTR. An FCrDNS check fails otherwise.
Match your PTR, your forward record and your SMTP EHLO hostname. All three should be the same name.
Configure IPv6 rDNS if you send mail over IPv6. Missing IPv6 PTR is a common and easily-missed delivery problem.
Use a hostname in a domain you control, not the provider's generic name.
Don't send bulk mail from a residential connection. The rDNS pattern alone is enough for many receivers to reject it.
Verify after any IP change. A server migration means a new address and a new PTR request.
Treat absent rDNS on IPv6 as normal, not as a red flag.
FAQ
Why can't I set my own PTR record? Because it lives in the reverse zone for the IP block, which is controlled by whoever owns that block — your provider, not you.
What is FCrDNS? Forward-confirmed reverse DNS. The PTR gives a hostname, the hostname's A record gives an IP, and the two must match. It requires agreement from two separately-controlled zones.
Does missing rDNS block email delivery? It's a significant negative signal for mail-sending IPs and causes rejections at many receivers. For non-mail servers it generally doesn't matter.
Why does my IPv6 address have no PTR record?
Because a /64 contains too many addresses to enumerate. Providers generate them dynamically or not at all.
Can a PTR record prove who owns an IP? No. It's an assertion by the block owner, which is often a provider rather than the actual user, and it can be stale.
Should I match my SMTP banner to my PTR? Yes. A mismatch between the EHLO hostname and the PTR is a check many receivers apply.
The Takeaway
Reverse DNS is a claim made by whoever owns the IP block, which is why it's set through your provider and why the claim alone proves nothing. FCrDNS is what turns it into evidence, and getting both directions to agree — along with your SMTP banner — is what makes a mail server look configured rather than compromised.
Look up the PTR record for any IP address free with the Reverse DNS Lookup at sadiqbd.com — no sign-up, instant results.
