Set up rDNS on an SMTP VPS in 2026

The first thing you notice when a mail server rejects your SMTP VPS traffic is a terse error in the queue: "550 5.7.1 Client host rejected: cannot find your hostname". Nine times out of ten, the cause is a missing or mismatched rDNS record. If you are running your own mail server on a VPS in 2026, setting up rDNS is not an optional polish, it is a prerequisite for getting mail delivered at all. This guide walks you through what rDNS is, why receiving servers check it, and exactly how to configure and verify it on your SMTP VPS.

Prerequisites

• A Linux VPS running Ubuntu 24.04, Debian 12, or AlmaLinux 9 with a static IPv4 address.
• Root or sudo access to the server.
• A domain name where you control the DNS zone (to add the A and PTR records).
• The dnsutils or bind-utils package installed for the dig and host commands.

Why does rDNS matter for email deliverability?

Reverse DNS maps an IP address back to a hostname, the opposite of what a regular DNS lookup does. When a receiving mail server like Gmail or Outlook gets your message, it looks up the sending IP, finds the PTR record, and then checks whether that hostname resolves forward to the same IP. This is the FCrDNS (Forward Confirmed reverse DNS) check. If the PTR record is missing, or the hostname it points to does not resolve back to your IP, the receiving server treats your mail as suspicious. It may mark it as spam, or reject it outright.

For a self-hosted mail server this is the baseline. SPF, DKIM, and DMARC authenticate your domain, but rDNS authenticates your IP. All four work together. Skipping rDNS is like sending a letter with a return address that does not exist. The post office has no proof the sender is who they claim to be. On a fresh SMTP VPS, the PTR record is rarely set up automatically, you have to request it.

How to set up rDNS on an SMTP VPS

Unlike DNS records you manage in your own zone, a PTR record is stored on the DNS server of the IP owner. That means you cannot create it in your domain registrar's panel. Your VPS provider controls the reverse zone for their IP ranges, so you must request the change through them. The process varies by provider, but the steps below cover the common paths.

Check the current rDNS of your VPS IP

Before you change anything, see what your server's current PTR record is. Log into your VPS and run:

dig -x $(hostname -I | awk '{print $1}') +short

If the output is empty, there is no PTR record set. If it returns a hostname, that is the current reverse entry. You also want to know which IP your server actually uses. The hostname -I command prints the local IP, but for a mail server you need the public one. You can confirm it with an external lookup:

curl -4 ifconfig.me

Note the IP, you will give it to your provider.

Pick a hostname for your PTR record

The hostname in the PTR record does not have to be the same as your domain, but it must be one you control and one that resolves forward to the same IP. The common convention is mail.yourdomain.com. Receiving servers are comfortable with this, and it matches the hostname you set on the mail server itself. If you use hostname.yourdomain.com, make sure you add an A record for that exact hostname pointing to the same IP. The forward and reverse lookups must match, or the FCrDNS check fails.

• Use a subdomain you control, like mail.yourdomain.com.
• Keep it stable. Changing the PTR later can hurt your sender reputation.
• Do not use a random hostname from another domain, it will look suspicious.

Request the PTR record from your provider

For most VPS providers, you do this in the control panel under a "Networking" or "Reverse DNS" section. If it is not there, open a support ticket with your IP and the desired hostname. Some providers, especially smaller ones, handle this manually. Budget for a few hours of turnaround time.

If you rent a VPS in Vietnam from a provider like thueVPS, the process usually goes through the ticket system. You provide the IP and the hostname, and they set the PTR record on their reverse zone. It is a quick change, but it is on their DNS infrastructure, not yours.

Set the matching A record in your DNS zone

While you wait for the provider to set the PTR, add the forward record. In your domain's DNS management panel, create an A record for the hostname you chose. If your PTR will be mail.yourdomain.com, add:

Name: mail
Type: A
Value: your-server-ipv4
TTL: 300

This step is easy to forget, and it is the most common reason the FCrDNS check fails after the PTR is set. The reverse lookup points to the hostname, but if that hostname does not resolve to your IP, the check still fails. Both records must exist and match.

Verify your rDNS configuration

Once the provider confirms the PTR record is live, run the reverse lookup from your server. DNS propagation can take a few minutes, but PTR records usually propagate quickly because they live on the authoritative server for the IP block.

dig -x your-server-ipv4 +short

Expected output:

mail.yourdomain.com.

Then check the forward resolution of that hostname:

dig +short mail.yourdomain.com

Expected output:

your-server-ipv4

The two lookups match. That is the FCrDNS check passing. You can also test from an external location with a service like whatsmydns.net, but the commands above give you a definitive answer from your own server.

Test your mail server with a real check

After the DNS records are in place, send a test email and check the headers. The Received header should show the PTR hostname, not just the raw IP. A quick way to verify is to check your domain against a mail-tester service. It runs a series of tests and gives you a score, and it explicitly checks rDNS, SPF, DKIM, and DMARC alignment. This is a useful sanity check before you start real email volume.

openssl s_client -starttls smtp -connect mail.yourdomain.com:587 -servername mail.yourdomain.com

If the connection succeeds and shows the certificate for your hostname, the server side is working. The rDNS part is the DNS check, which you already verified above.

Troubleshooting common rDNS issues

If a receiving server still rejects your mail, work through these in order.

Why does my mail still get rejected after I set rDNS?

Check that the PTR hostname exactly matches the A record. A common mistake is a trailing dot difference or a typo in the hostname. Run the two dig commands from the section above and compare them line by line. If they match and mail is still rejected, the issue is likely the sender reputation of your IP, which rDNS cannot fix on its own. Warm up the IP gradually before sending large volumes.

Can I set rDNS myself without contacting my provider?

No. The reverse zone for an IP block is controlled by the network owner, which is your VPS provider or the upstream datacenter. If you rent a cheap VPS Vietnam, you cannot self-manage the PTR. You must submit a request. The provider sets it on their authoritative DNS nameservers.

Do I need rDNS for outbound SMTP on port 587 as well?

Yes. Receiving servers perform the rDNS check on the connecting IP regardless of the port used to send. Port 25 and 587 are equally affected. If you send automated mail through a SMTP VPS with a clean IP, the PTR record is part of the baseline configuration.

What if my provider does not support rDNS requests?

That is a red flag for running a mail server. Any provider that wants your email business should handle PTR requests. If yours will not, you are fighting an uphill battle on deliverability. Consider a provider that does, many offer it as a standard feature on their Linux VPS plans.

Key takeaways

• rDNS maps your sending IP to a hostname, and receiving servers check it on every connection.
• The FCrDNS check requires the PTR hostname to resolve forward to the same IP. Both records must match.
• You cannot set the PTR yourself; you request it from your VPS provider via their control panel or ticket system.
• Verify with dig -x <ip> +short and dig +short <hostname>, and make sure the outputs match.

FAQ

Related articles

• SPF, DKIM and DMARC on a self-hosted SMTP server
• Warming up a new sending IP: a realistic 30-day schedule
• Why shared SMTP relays hurt deliverability once you scale
• Configure DNS records for your domain: A, CNAME, MX, TXT