Reverse DNS (PTR) and ordering an extra IPv4 address on HIP
A PTR record is DNS running backward: instead of "name to IP" it answers "IP to name". Nobody notices it's missing until they stand up their own mail server or SMTP relay, and mail starts vanishing into spam folders with no obvious error anywhere. Here's how the reverse zone works, who actually controls it, how to check your PTR with dig, and how to order a second IPv4 on HIP when one address on the server isn't enough anymore.
A normal DNS record answers "what IP address belongs to this domain". A reverse DNS record, PTR, answers the opposite question: "what hostname belongs to this IP address". You can run a server for years without thinking about it, right up until a mail server or SMTP relay on that IP starts sending mail and outbound messages quietly disappear into spam folders with nothing useful in the logs. This guide covers what a reverse DNS record is, why it matters beyond email, how to check yours with dig -x, and how to order a second IPv4 on HIP once one address stops being enough.
In short. A PTR record lives in the reverse DNS zone (
in-addr.arpa) and maps an IP address back to a hostname. It's controlled by whoever owns that IP, not your domain registrar, so on a HIP server it's set right on the server's page in my.hip.hosting (Information tab, "Reverse DNS (PTR)" block) - self-service, no ticket needed. Without it, mail providers like Gmail and Yahoo are more likely to flag outbound mail as spam, and some SMTP relays and APIs refuse the connection outright. Check the current state withdig -x YOUR_IP. If one IPv4 isn't enough, say you need a clean address dedicated to mail, HIP handles that through a support ticket ("Open support ticket" on the server page) - there's no order form for it in the UI.
What a reverse DNS record actually does
Regular DNS runs one way: the domain example.com has an A record pointing at an IP, say 203.0.113.10. The reverse zone does the same lookup backward, finding a hostname given an IP. It's just another DNS zone with a telling name, in-addr.arpa: the address gets written with its octets flipped, 10.113.0.203.in-addr.arpa, and that's where the PTR record actually lives.
The part that trips people up: example.com is your zone, or your DNS provider's, but in-addr.arpa for a given IP belongs to whoever holds that block of addresses. For a rented server that's the hosting provider, not you. That's why a PTR can't be added next to your domain's A record, it lives in a completely different zone.
Where PTR actually matters
A PTR record isn't a box to tick and forget. Three situations where its absence turns into a real problem:
Scenario | What gets checked | Without a PTR |
|---|---|---|
Self-hosted mail server (Postfix, Exim, etc.) | The receiving server checks the sender's PTR, ideally matching the forward record for that name | Mail is more likely to land in spam or get rejected with something like |
App sending mail through an outbound SMTP relay | Many relays and spam filters check the connecting IP's reverse DNS during the handshake | The connection can be refused at the TCP/SMTP level before the message is sent |
APIs and webhooks weighing IP reputation | Some anti-fraud systems check whether an IP resolves to a meaningful hostname | The request may get flagged for extra checks, behavior varies by service |
Worth knowing the term: forward-confirmed reverse DNS (FCrDNS), where an IP's PTR points to a hostname and that hostname's A record points right back at the same IP. That two-way match, not just having some PTR, is what convinces mail providers a server is legitimate rather than a random address out of a spam botnet's subnet.
Step 1. Check the server's current PTR
dig is the standard tool for DNS queries, usually already installed on Ubuntu/Debian as part of dnsutils; if it's missing, install it with sudo apt install dnsutils. The -x flag means "reverse lookup by IP":
dig -x 203.0.113.10
203.0.113.10- swap in the server's public IPv4, visible on its page in the HIP panel.- look for the
ANSWER SECTIONblock - a line with typePTRand a hostname means a reverse record is set.
An empty answer, or something like your-ip-with-dashes.provider-domain, means what's there is just the provider's automatic default. Fine for a server that doesn't handle its own mail. For one that will, this is what needs to change next.
Step 2. Set the PTR in the HIP panel
Log into my.hip.hosting and open the server - you land on the Information tab by default. Scroll past the SSH connection details to the "Reverse DNS (PTR)" block. A fresh server shows a provider-assigned default there, something like hip.fi-1.ibcs, until you set your own.
Type the hostname you want, for example mail.example.com, into the field below the current value and click Save (it stays disabled until the field has text). Remove PTR next to it reverts to the automatic default. Once saved, check the matching A record for that hostname points back at the same IP, so the result is an FCrDNS match, not a one-way PTR sitting on its own.
How long until the new PTR takes effect
Two different meanings of "applied" apply here. The provider controls the reverse zone directly, so a saved change usually shows up in DNS answers within minutes, not a full day. But anything that already queried your PTR before, including receiving mail servers, may be holding a cached answer for the length of its TTL, a setting that caps how long a resolver can keep an answer before asking again. Verify with dig -x yourself, and give a fresh PTR a couple of hours before judging deliverability off the first few messages.
When you need a second IPv4, and how to order one
There simply isn't more IPv4 space to hand out, the global pool ran dry years ago, and providers allocate to customers out of what they already lease or own. An extra IPv4 on HIP, like on most hosting platforms, is normally a paid add-on with a limited number of addresses per location, not a free button.
The most common reason to order one is exactly the mail scenario above: if the server's existing IP carries someone else's history, say it's a recycled address from a shared pool, it's simpler to put mail on a clean, dedicated IPv4 with its own PTR than to inherit that reputation. Other reasons include keeping services cleanly separated by address, or software that specifically wants a dedicated IP rather than one shared behind NAT.
Unlike PTR, there's no self-service "order another IPv4" form anywhere in my.hip.hosting - not on Information, not on Scale (that tab only covers CPU/RAM/disk upgrades). The flow instead:
- On the server's page, click "Open support ticket" - it pre-fills your server and the Tech category, no need to hunt for the right support section.
- State which server needs the second IPv4 and why - availability and pricing depend on the data center.
- Once support attaches the address, configure it in the OS if that isn't done automatically, on Ubuntu that's a config edit through
netplan. - Set a PTR for the new address the same way as in step 2, it also carries the provider's default placeholder until changed.
Pricing and any per-location cap are deliberately not stated here as fact - the UI doesn't show them, ask support when opening the ticket.
PTR is one piece of a bigger mail setup
Even a perfect PTR doesn't cover everything. Reliable delivery also needs SPF, a record listing which servers may send mail on behalf of your domain, and DKIM, a signature proving a message wasn't tampered with in transit. That's a separate job on the domain and mail server, out of scope here, but if PTR is correct and mail is still getting lost, that's where to look next.
Common questions
What is a reverse DNS record?
A reverse DNS record (PTR) answers "what hostname is this IP address", the opposite of an A record, which answers "what IP address is this hostname". It's controlled by whoever owns the IP block, usually the hosting provider, not the domain.
Why does my mail server need a PTR record?
Major mail providers like Gmail and Yahoo check the sending IP's reverse record and whether it matches the forward record on receipt. Without a matching PTR, mail is far more likely to land in spam or get rejected, even with SPF and DKIM correct.
How do I check a server's PTR record?
Run dig -x YOUR_IP. A line with type PTR in the ANSWER SECTION means it's set. An empty answer, or a name like your-ip-with-dashes.provider-domain, means only the default placeholder is there.
Can I set my own PTR record?
Yes, but not through your domain's DNS panel, the reverse zone is controlled by the IP's owner. For a HIP server that's the network/IP section of my.hip.hosting, not your registrar.
How much does an extra IPv4 cost on HIP?
Price and any per-server limit depend on location and change over time, so this article deliberately skips a figure. Check the current cost in the panel's IP order section or ask support before committing.
Do regular websites need a PTR record?
For a site not sending mail directly from the server, a PTR record barely matters, browsers never check it. It matters once the server sends its own mail or talks to services that weigh reverse DNS in how much they trust a connecting IP.
Does IPv6 need a PTR record too?
Same mechanism, the reverse zone for IPv6 is ip6.arpa instead of in-addr.arpa, checked with the same dig -x. Whether the HIP panel handles IPv6 PTR the same way as IPv4, or only via a ticket, is worth confirming separately if you send mail over IPv6.
Takeaways
- A PTR record is reverse DNS: given an IP it returns a hostname, the opposite of a regular A record.
- The reverse zone is controlled by the IP's owner, the hosting provider, not the domain registrar.
- Without a PTR, mail is more likely to land in spam, and some relays and APIs may refuse the connection.
- Best practice is a forward-confirmed match (FCrDNS), not just any PTR.
- Verify with
dig -x YOUR_IPbefore and after making a change. - An extra IPv4 on HIP is normally a paid, limited-per-location add-on, and needs its own PTR set separately.
- PTR doesn't replace SPF and DKIM, reliable delivery needs all three together.
Next steps
- How to create a server in the HIP panel - if the IP that needs a PTR hasn't been issued yet.
- Secure a fresh VPS - baseline hardening before putting mail or public services on it.