Reverse DNS (rDNS) answers the question "which hostname belongs to this IP address?", the opposite of a normal DNS lookup. It is stored in PTR records, and mail servers in particular check it: a server that sends email from an address without a matching PTR record is likely to have its messages rejected or marked as spam. In this tutorial you will learn how reverse DNS is delegated, create the forward record it depends on, set the PTR record for your server's IPv4 and IPv6 addresses in the CubePath panel, and verify the result.
Prerequisites
To follow this guide you need:
- A server with a public IP address, for example a CubePath VPS or bare metal server.
- A domain name whose DNS records you can edit.
- The
digcommand on your local machine or server. On Ubuntu 24.04 and Debian 12 it is in thednsutilspackage (sudo apt install dnsutils); on Rocky Linux 9 it is inbind-utils.
Throughout this guide, replace your_domain with your domain, mail.your_domain with the hostname you want the IP to resolve to, and the example addresses 203.0.113.10 and 2001:db8:1234::10 with your server's addresses.
How reverse DNS works
Forward DNS is controlled by whoever manages your domain. Reverse DNS is controlled by whoever owns the IP address, because PTR records live in special zones built from the address itself:
- For IPv4, the octets are reversed and
.in-addr.arpais appended. The PTR record for203.0.113.10is10.113.0.203.in-addr.arpa. - For IPv6, every hexadecimal digit of the fully expanded address is reversed and
.ip6.arpais appended. The PTR record for2001:db8:1234::10is0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.
The regional internet registries delegate these zones to the organization that holds the address block, which is your hosting provider. That is why you cannot create a PTR record in your domain's DNS zone: you set it through your provider, and the provider publishes it in its reverse zone.
Receiving mail servers go one step further and check forward-confirmed reverse DNS (FCrDNS): the IP resolves to a hostname through PTR, and that hostname resolves back to the same IP through an A or AAAA record. Both directions have to match.
Step 1 - Choosing the hostname
Pick one fully qualified hostname per IP address, in a domain you control. For a mail server this should be the name the server announces when it connects to other servers, for example mail.your_domain. Avoid hostnames that look dynamically generated (such as ones containing the IP address), because spam filters treat them as residential connections.
Check the name your server currently uses:
hostname -f
If it does not match the name you chose, set it:
sudo hostnamectl set-hostname mail.your_domain
Step 2 - Creating the forward DNS records
The PTR record must point to a name that resolves back to the same address, so create the forward records first. At your DNS provider, add:
| Type | Name | Value |
|---|---|---|
| A | mail.your_domain | 203.0.113.10 |
| AAAA | mail.your_domain | 2001:db8:1234::10 |
Only add the AAAA record if your server has IPv6 configured and your services listen on it. Verify both records once they have propagated:
dig +short A mail.your_domain
dig +short AAAA mail.your_domain
203.0.113.10
2001:db8:1234::10
Step 3 - Setting the PTR record in CubePath
In CubePath, reverse DNS is configured per IP address from the dashboard:
- Open the Floating IPs page, or the network tab of the VPS or bare metal server the IP is attached to.
- Find the IP address and edit its Reverse DNS field.
- Enter the hostname you chose, for example
mail.your_domain, and save.
Keep these rules in mind:
- The IP must be assigned to a VPS or bare metal server. Reverse DNS cannot be set on an IP that is not attached to a server.
- The value must be a valid hostname: letters, digits and hyphens, with each label starting and ending with a letter or digit. A trailing dot is added automatically, so
mail.your_domainis stored asmail.your_domain.. - Saving an empty value removes the PTR record.
- The change is applied to CubePath's DNS servers in the background, usually within a few minutes.
If the server's IPv6 address is listed in the panel, repeat the process for it. Each IP address has its own PTR record; if your server has several addresses, set one for each address that sends traffic you care about, in particular outgoing email.
If your server is hosted elsewhere, the process is the same in concept: look for a reverse DNS or PTR setting next to the IP address in your provider's panel, or ask their support to set it.
Step 4 - Verifying the PTR record
Query the reverse record with dig -x, which builds the in-addr.arpa or ip6.arpa name for you:
dig +short -x 203.0.113.10
dig +short -x 2001:db8:1234::10
mail.your_domain.
mail.your_domain.
If the answer is still empty or shows the old value, your resolver may be serving a cached response. Follow the delegation from the root to ask the authoritative server directly:
dig +trace -x 203.0.113.10
The last section of the output comes from the provider's name servers and shows the current PTR record.
Now confirm the forward-confirmed match. Resolve the PTR hostname and compare the result with the original IP:
dig +short "$(dig +short -x 203.0.113.10)"
203.0.113.10
When the output is the same address you started from, reverse DNS is correctly configured for that IP. Repeat with AAAA for IPv6:
dig +short AAAA "$(dig +short -x 2001:db8:1234::10)"
2001:db8:1234::10
Step 5 - Matching the mail server hostname
For email, the PTR record, the forward records and the name your mail server announces in its HELO/EHLO greeting should all be the same. With Postfix, that name comes from the myhostname setting. Check it:
postconf myhostname
myhostname = mail.your_domain
If it differs, set it and reload Postfix:
sudo postconf -e 'myhostname = mail.your_domain'
sudo systemctl reload postfix
Reverse DNS is one of several checks receiving servers apply. For reliable delivery, also publish SPF, DKIM and DMARC records for your_domain.
Troubleshooting
dig -x returns nothing: the PTR record has not been created yet, or your resolver cached the empty answer. Wait a few minutes, then check the authoritative answer with dig +trace -x.
The PTR record shows the provider's default hostname: the change has not been applied yet, or it was set on a different IP. Confirm the exact address in the panel, including every IP your mail server sends from (check with curl -4 https://icanhazip.com and curl -6 https://icanhazip.com on the server).
The panel rejects the hostname: it contains invalid characters, such as underscores or spaces, or a label starts or ends with a hyphen. Use a plain hostname like mail.your_domain.
Mail servers report that the reverse and forward DNS do not match: the A or AAAA record for the PTR hostname is missing or points to another address. Fix the forward record in your domain's DNS so it resolves to the same IP.
IPv4 mail is accepted but IPv6 mail is rejected: large providers apply stricter checks over IPv6 and require a valid PTR record for the IPv6 address too. Set it, or configure your mail server to send only over IPv4 (in Postfix, inet_protocols = ipv4).
Conclusion
You created forward DNS records for your server's hostname, set matching PTR records for its IPv4 and IPv6 addresses in the CubePath panel, and verified that both directions resolve consistently. With forward-confirmed reverse DNS in place, your server passes one of the first checks receiving mail servers perform.
As next steps, you can:
- Publish SPF, DKIM and DMARC records for your domain to authenticate outgoing email.
- Test your mail setup by sending a message to a mailbox you control on a major provider and reviewing the authentication results in its headers.
- Add PTR records for every additional IP address you assign to a server.