Reverse DNS (PTR) on a VPS: Set It and Check It

What reverse DNS is

Reverse DNS on a VPS answers one question: given your server's IP address, what name does it claim? The answer is stored in a PTR (pointer) record. Your hosting provider controls that record, not your domain registrar, because the provider owns the IP address. Mail servers check it, so a VPS that sends email needs a PTR record that matches its forward DNS.

Normal DNS (domain name system) maps a name to an address. You publish mail.example.com with an A record that says 203.0.113.10. If DNS records are new to you, start with how DNS turns names into addresses and then come back. Reverse DNS goes the other way. A program that has only an IP address, such as a mail server accepting a connection, asks DNS which name belongs to that address.

How a PTR record is stored

DNS can only look up names, so the IP address is turned into a name first. For IPv4, the four parts of the address are written in reverse order, and .in-addr.arpa is added at the end. The address 203.0.113.10 becomes this name:

10.113.0.203.in-addr.arpa

The order is reversed because DNS names get more specific from right to left, while IP addresses get more specific from left to right. Reversing the address puts the network part on the right. Each block of the address space can then be handed to the organisation that owns it.

The PTR record sits at that name and holds a hostname:

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.

Why your host sets the PTR record, not your registrar

The reverse zone follows who owns the address, not who owns the domain. Regional internet registries (RIRs) give blocks of addresses to hosting companies. They also delegate the matching in-addr.arpa and ip6.arpa zones to those companies' name servers. Your registrar only controls the zone for example.com. It holds no data for 10.113.0.203.in-addr.arpa, so nothing you add there changes reverse DNS.

You can see this delegation yourself. The +trace option follows the lookup from the root servers down:

dig -x 203.0.113.10 +trace

Near the end, the output lists the NS (name server) records for the reverse zone, and the final answer comes from one of them. Those name servers belong to the company that runs the network, which is your host or its upstream provider. That company is who you ask. Most hosts take PTR requests through the control panel or through a support ticket. The steps differ by provider, so read your host's own documentation. Some hosts delegate the reverse zone of a large block to the customer, but on a single-IP VPS you should expect to make a request.

Before you ask, create the forward record. Add an A record, and an AAAA record for IPv6, for the name you want, pointing at the VPS. Some providers check that the forward record exists before they accept a PTR change. You need it anyway for the check in the next section.

Forward-confirmed reverse DNS, and why mail servers check it

Anyone who controls a reverse zone can put any name in a PTR record. A PTR record that says mail.google.com proves nothing on its own. So receiving mail servers do a second lookup. They take the name from the PTR record and resolve it forward. If that forward lookup returns the same IP address, the result is called forward-confirmed reverse DNS (FCrDNS). The match means something because the forward record lives in a zone that only the domain owner controls. When both lookups agree, the network owner and the domain owner agree.

Check both halves yourself:

dig -x 203.0.113.10 +short
dig mail.example.com A +short

The first command should print one name with a trailing dot, such as mail.example.com.. The second should print 203.0.113.10. If the second command prints a different address, or nothing, the PTR record exists but it is not forward-confirmed.

Check reverse DNS with dig and host

Both tools come from the BIND utilities, and most Ubuntu images already include them. If yours does not, install them:

sudo apt update && sudo apt install -y bind9-dnsutils bind9-host

Run the checks from your laptop or from the VPS. They need outbound DNS on port 53, so on a network that blocks DNS they will time out.

dig -x 203.0.113.10
host 203.0.113.10

dig -x builds the in-addr.arpa name for you. In its output, look at the header line and the answer section. A healthy result shows status: NOERROR and an answer line that ends in PTR mail.example.com.. host prints the same answer on one line:

10.113.0.203.in-addr.arpa domain name pointer mail.example.com.

If there is no PTR record, dig shows status: NXDOMAIN and an empty answer section, and host prints a line ending in not found: 3(NXDOMAIN). A SERVFAIL status means something else. The name servers for the reverse zone did not answer properly, which is a problem on the host's side, not a missing record.

Resolvers cache answers, so a change your host just made may not show yet. The TTL (time to live) in the answer line is the number of seconds a resolver may keep the old answer. To skip every cache, ask the reverse zone's own name server directly. Take its name from the end of the +trace output, then run:

dig -x 203.0.113.10 @ns1.provider.example +short

IPv6 reverse DNS and the ip6.arpa nibble format

IPv6 uses the same idea in a different zone, ip6.arpa, and it splits the address into smaller pieces. Each hexadecimal digit of the address is called a nibble, which is four bits. To build the name, write out the full address with every zero, reverse the 32 nibbles, and put a dot between each one.

Take 2001:db8::abcd. The full form is 2001:0db8:0000:0000:0000:0000:0000:abcd. Reversed nibble by nibble, it becomes:

d.c.b.a.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

The format works per nibble because IPv6 networks are split on four-bit boundaries, so a provider can delegate a /48 or a /64 as one zone. You never need to type this name. Both tools accept the short address:

dig -x 2001:db8::abcd +short
host 2001:db8::abcd

The question section of the full dig -x output shows the long ip6.arpa name. Read it to confirm you queried the address you meant.

IPv6 is where many mail setups break. Your host may set a PTR record for the IPv4 address and leave the IPv6 address without one. If the VPS has a global IPv6 address and the receiving server accepts IPv6, your mail server may connect over IPv6. The receiver then finds no PTR record for that address. List your global IPv6 addresses with ip -6 addr show scope global, and check each one with dig -x. Then either ask your host for an IPv6 PTR record as well, or make the mail server send over IPv4 only. In Postfix, that is:

sudo postconf -e 'inet_protocols = ipv4'
sudo systemctl restart postfix

Why outbound mail fails without matching reverse DNS

A VPS that sends mail directly is the most common reason to care about reverse DNS. Large mailbox providers publish sender guidelines that ask for a valid PTR record that matches forward DNS. A server that fails this check may see its messages refused or filed as spam. The exact response differs between receivers and changes over time, so read the bounce your own server logs instead of guessing.

You can watch the receiving side of this check on any Postfix server you run. When a client with no PTR record connects, Postfix logs it with the name unknown:

connect from unknown[203.0.113.10]

When the PTR record exists but its name does not resolve back to the address, Postfix logs a warning such as hostname mail.example.com does not resolve to address 203.0.113.10, and it still treats the client as unknown. The Postfix restriction reject_unknown_client_hostname turns that state into a rejection. That is how a receiver enforces FCrDNS.

A sending server passes when it uses one name everywhere:

• The PTR record of the IPv4 address names mail.example.com.
• The PTR record of the IPv6 address names the same host, if the server sends over IPv6.
• mail.example.com has A and AAAA records that point back at those addresses.
• The server greets other servers with that name in its SMTP (simple mail transfer protocol) HELO or EHLO command. In Postfix this is the myhostname setting, which postconf myhostname prints.

The PTR record covers the IP. Domain checks such as SPF (sender policy framework) and DKIM (DomainKeys Identified Mail) cover the domain, and a receiver looks at both. For the whole path from an app to an inbox, read how to send mail from self-hosted apps. If you run a full stack, a Mailcow mail server on a VPS asks for a hostname at install time, and that hostname is the name your PTR record must carry. Once reverse DNS and SPF pass, you can move DMARC from p=none to quarantine and reject. DMARC is domain-based message authentication, reporting and conformance. If you are still deciding whether to run mail at all, whether self-hosting email is still worth it covers the trade.

A stale PTR record from the IP's last tenant

VPS addresses are reused. When you get a new server, its IP may have belonged to another customer last month, and the PTR record may still name their domain. Run dig -x on every new VPS before you point anything at it. A name from a domain you do not own fails FCrDNS for your mail, because its forward record points somewhere else. It also tells anyone who looks up your IP that the box belongs to someone else.

The fix is the same request as before: create your forward record, then ask your host to replace the PTR. A reused IP can also carry a bad reputation from its last tenant, such as a listing on a spam blocklist. That is a separate problem from the PTR record, and how abuse complaints and blocklists work on a VPS explains how to check for it and clear it.

The same check belongs in any move between servers. When you migrate a server to a new VPS, the new IP has its own PTR record, often your host's generic default. Set it before you move mail over. Otherwise the first mail from the new box goes out without matching reverse DNS.

Generic names and multiple PTR records

Many hosts give every IP a generic default name built from the address, something like 203-0-113-10.provider.example. That name may even pass FCrDNS, because the host publishes the forward record too. It still names the provider, not your service, and it will not match your HELO name. For a mail server, replace it with your own mail hostname.

Keep one PTR record per address. DNS allows several, but a checking server uses whichever answer it gets first. If one of the names does not match your HELO name or your forward records, the check fails some of the time. An intermittent failure like that is hard to trace.

Why SSH logins pause: sshd and UseDNS

The SSH daemon can also look up reverse DNS. With UseDNS yes, sshd looks up the PTR record of the address you connect from, then checks that the name resolves back. If the name servers for your client's reverse zone are slow or do not answer, sshd waits for the lookup to time out before it continues. The login still works, but it pauses for several seconds every time.

OpenSSH has defaulted to UseDNS no since version 6.8, so a fresh Ubuntu 24.04 server does not do this. Check the value sshd actually uses:

sudo sshd -T | grep -i usedns

A healthy result is usedns no. If it prints usedns yes, find the line in /etc/ssh/sshd_config or in a file under /etc/ssh/sshd_config.d/, and change it to UseDNS no. Then test the config and restart the service:

sudo sshd -t && sudo systemctl restart ssh

sshd -t prints nothing when the config is valid. Keep your current session open until a new login works. There is one side effect: with UseDNS no, from= options in authorized_keys and Match Host blocks only match IP addresses, not hostnames. If you used hostnames there, change them to addresses.

Tor exit relays: a PTR record that says what the box is

Reverse DNS also has a social job. People who handle abuse reports look up the IP of whatever touched their network. A Tor exit relay sends traffic from many strangers out of your address. A PTR record such as tor-exit.example.org tells those people what they are looking at before they write a complaint. The Tor relay community treats a descriptive reverse DNS name as part of running an exit responsibly.

Exits belong on hosts that accept exit traffic in writing, not on a general-purpose VPS. Read how to run a Tor exit node on a VPS first. It covers choosing an exit-friendly host and handling abuse reports. The PTR record is one step in that guide.

FAQ

Can I set a PTR record in my domain registrar's DNS panel?

No. The PTR record lives in the reverse zone for your IP address, under in-addr.arpa for IPv4 or ip6.arpa for IPv6. That zone is delegated to the organisation that owns the address, which is your hosting provider. Your registrar only hosts your domain's zone. Create the A or AAAA record at your registrar, then ask your host to set the PTR record to that name.

How do I check reverse DNS for an IPv6 address?

Run dig -x 2001:db8::1 +short or host 2001:db8::1, using your own address. Both tools build the ip6.arpa name for you: the 32 hexadecimal digits of the full address, reversed, with a dot between each one. Check every global IPv6 address the server can send mail from, not only the IPv4 address.

What is forward-confirmed reverse DNS?

It means the PTR name for an IP address resolves back to that same IP address. Check it in two steps. dig -x <ip> +short gives a name, and dig <name> A +short (or AAAA for IPv6) should return the original address. Receiving mail servers run this check because anyone who controls a reverse zone can write any name into a PTR record, but only the domain owner can make that name point back.

Why do SSH logins to my VPS pause for several seconds?

One common cause is UseDNS yes in the sshd config. It makes sshd look up the reverse DNS of your client address and wait while that lookup is slow. Run sudo sshd -T | grep -i usedns. If it prints usedns yes, set UseDNS no and restart the SSH service. OpenSSH has defaulted to no since version 6.8.

My new VPS IP has a PTR record with someone else's domain. Is that a problem?

Yes, for mail. The name belongs to the IP's previous tenant, so its forward record does not point at your server and FCrDNS fails. Create a forward record for your own hostname, then ask your host to change the PTR record. Also check the address against spam blocklists, because a reused IP can carry its previous owner's reputation.