Reverse DNS: Why Your Server’s Identity Matters

Introduction

Every DNS lookup we’ve covered so far works in one direction: you start with a name and get back a number. Type stw.no, get an IP address. That’s forward DNS, and it’s what makes browsing and email delivery work.

Reverse DNS goes the other direction. It starts with an IP address and returns a name. It answers the question: “What name does the server at 203.0.113.50 claim to be?”

When your mail server sends a message, the receiving server often checks reverse DNS to see if the sending IP has a legitimate name associated with it. If it doesn’t, or if the name doesn’t match, the message is more likely to be flagged as spam or rejected outright.

By the end of this article, you’ll understand how reverse DNS works and why it matters for server reputation.

How Reverse DNS Works

PTR records

Reverse DNS uses a record type called PTR (Pointer). A PTR record maps an IP address to a hostname. This is the opposite of an A record.

Direction	Record type	Input	Output
Forward	A	yourdomain.com	203.0.113.50
Reverse	PTR	203.0.113.50	yourdomain.com

The in-addr.arpa zone

PTR records aren’t found in your regular domain zone (where your A, MX, and CNAME records are). They live in a special reverse zone under .in-addr.arpa, with the IP address written backwards.

For the IP address 203.0.113.50, the PTR record is at:

50.113.0.203.in-addr.arpa

The reversed format exists because DNS is hierarchical and reads right to left. By reversing the IP, the DNS hierarchy can delegate responsibility for IP blocks in the same way it delegates responsibility for domain names.

For IPv6 addresses, the equivalent zone is .ip6.arpa, and each hexadecimal digit gets its own label. This makes IPv6 PTR records very long, but the principle is the same.

Who controls the PTR record?

This is where reverse DNS differs from everything else in this series.

PTR records are not in your domain’s DNS zone. You cannot add or edit them in your DNS Manager. They belong to whoever controls the IP address, which is usually your hosting provider.

If your domain is at one provider but your server is hosted elsewhere, set reverse DNS at the server provider. Do not set it at your domain registrar or DNS host.

If your server is hosted elsewhere, check with your provider. Most VPS and dedicated server providers offer a way to set reverse DNS through their dashboard.

Step 1 — Why Reverse DNS Matters

The email reputation check

When your mail server connects to a receiving server (like Gmail, Outlook, or another provider), the receiving server performs several checks before accepting the message. One of those checks is a reverse DNS lookup on your mail server’s IP address.

The check works like this:

1. Your server connects from IP 203.0.113.50.
2. The receiving server looks up the PTR record for 203.0.113.50.
3. It gets back a hostname (e.g., mail.yourdomain.com).
4. It then does a forward lookup on that hostname to confirm it resolves back to 203.0.113.50.
5. If both directions match in both forward and reverse lookups, the identity check passes.

This forward-confirmed reverse DNS (FCrDNS) is like caller ID for mail servers. Spammers often send mail from servers with no reverse DNS (or mismatched reverse DNS), so many mail servers use this check as a basic credibility signal.

What happens when reverse DNS is wrong

Situation	Result
No PTR record exists	Many receiving servers reject the connection or flag the message as spam
PTR exists but doesn’t match the server’s hostname	Increased spam score; some providers reject outright
PTR matches and forward DNS confirms	Clean pass. This removes one common reason to distrust the message.

Reverse DNS isn’t the only factor in email deliverability (SPF, DKIM, and DMARC from Part 6 are equally important), but a missing or broken PTR record is one of the easiest things to check and one of the reasons mail from a self-hosted server ends up in spam.

Beyond email

Reverse DNS is also used for:

• Server logs. Many web servers and firewalls log the reverse DNS name of connecting clients, making logs easier to read than raw IP addresses.
• Access control. Some services restrict access based on reverse DNS (e.g., allowing connections only from hosts with valid PTR records).
• Diagnostics. Tools like traceroute display reverse DNS names for each hop, making network paths easier to understand.

Step 2 — Check Your Reverse DNS

Using dig

To perform a reverse DNS lookup, use dig with the -x flag:

dig -x 203.0.113.50

If a PTR record exists, you’ll see something like:

;; ANSWER SECTION:
50.113.0.203.in-addr.arpa. 3600 IN PTR mail.yourdomain.com.

If no PTR appears in the answer section (or the query returns NXDOMAIN), reverse DNS is not configured for that IP.

Verify the forward match

After getting the PTR result, confirm the forward direction matches:

dig A mail.yourdomain.com
dig AAAA mail.yourdomain.com

For IPv4-sending servers, the hostname should resolve via A back to the sending IPv4. For IPv6-sending servers, it should resolve via AAAA back to the sending IPv6. If it returns a different IP (or no result), there’s a mismatch that needs fixing.

Windows users

On Windows, you can run nslookup 203.0.113.50 for a quick reverse lookup, or use the Google Admin Toolbox with PTR selected as the record type.

Step 3 — Set Up Reverse DNS

On a ServeTheWorld VPS

PTR records are published in the provider-controlled reverse DNS zone. For STW-hosted IPs, treat rDNS as a provider-side change request, not a normal DNS Manager edit.

1. Decide the hostname you want to use (for example, mail.yourdomain.com).
2. Create and verify matching forward DNS first (A for IPv4, AAAA for IPv6).
3. Collect the server IP and target hostname.
4. Log in to my.servetheworld.net and contact STW support to request the PTR/rDNS change for that IP.
5. After confirmation, re-check with dig -x and the forward lookup.

The matching A record

Before setting reverse DNS, make sure you have a matching A record in your domain’s DNS zone. If you set the PTR to mail.yourdomain.com, there must be an A record for mail.yourdomain.com pointing back to the same IP address.

Record	Name	Type	Value
Forward (in your DNS zone)	mail	A	203.0.113.50
Reverse (set at your hosting provider)	50.113.0.203.in-addr.arpa	PTR	mail.yourdomain.com

Both records must point at each other. If either side does not match, the FCrDNS check fails.

Common PTR hostnames

The hostname you use for reverse DNS should be a real, resolvable name. Common choices:

• mail.yourdomain.com if the server primarily handles email.
• server1.yourdomain.com or vps.yourdomain.com for a general-purpose server.
• Your root domain (yourdomain.com) is acceptable if the server hosts your main website and email.

A generic provider hostname (e.g., vps12345.example.net) can still work if forward and reverse DNS match. But using a stable hostname under your own domain is usually clearer for operations, branding, and troubleshooting.

Step 4 — Pinpoint Where the Failure Is

Once you’ve run the checks above, you can quickly determine what’s actually causing the problem:

What you see	What it means	What to do
dig -x <ipaddress> returns no answer	No PTR record set	Request rDNS/PTR from your hosting provider
PTR returns a name, but dig A/AAAA <name> gives a different sending IP	Forward/reverse mismatch	Fix the A/AAAA record or update the PTR to match
PTR and A record both match	rDNS is correct. Look elsewhere.	Check SPF, DKIM, DMARC (see Part 6), or IP reputation
PTR is a generic provider name (e.g. vps12345.provider.net)	Not inherently broken if forward/reverse mapping is correct	Optional: request a custom hostname under your domain via your hosting provider

If rDNS checks out but mail is still being rejected, the problem has shifted from DNS identity to reputation or email authentication. Tools like MXToolbox Mail Server Test and mail-tester.com can help isolate what’s still failing.

Common Mistakes

Setting rDNS to a hostname that doesn’t exist

If you set the PTR to mail.yourdomain.com but never create the corresponding A record, the forward-confirmed check fails. Always create the A record first, verify it with dig, then set the PTR.

Forgetting IPv6

If your server has an IPv6 address and sends mail over IPv6, it needs its own PTR record. Receiving servers check whichever IP address the connection came from. If that is the IPv6 address and it has no PTR, the check fails. Set reverse DNS for both IPv4 and IPv6 if your server uses both.

Assuming your DNS host manages PTR records

PTR records are controlled by whoever owns the IP address block. That is your hosting provider, not your domain’s DNS host. If your domain is registered and DNS-hosted at one company but your server is at another, set reverse DNS at the server provider.

Conclusion

Reverse DNS is a simple concept: look up an IP address and get a name. It has importance for email deliverability. A properly configured PTR record with a matching forward A record gives your mail server a verifiable identity that receiving servers can trust.

If you run a mail server on a ServeTheWorld VPS (or any VPS), setting up reverse DNS is one of the first things to do. Once the provider-side PTR change is in place, it removes one of the most common reasons self-hosted mail gets flagged as spam.

In Part 9, we tackle the question everyone asks after making a DNS change: “Why hasn’t it taken effect yet?” You’ll learn what propagation actually is, how to check whether the change is live, and when flushing your DNS cache helps (and when it doesn’t).

Next steps:

• Part 9: DNS Propagation — Why Changes Aren’t Instant (and How to Check)
• ServeTheWorld VPS plans
• ServeTheWorld DNS support documentation