Reverse DNS and PTR Records: The Return Address Your VPS Cannot Ignore

A normal DNS lookup starts with a name and asks for an address.

You type:

mail.example.com

DNS answers:

203.0.113.25

Reverse DNS walks the road in the opposite direction.

It starts with:

203.0.113.25

and asks:

What hostname says it belongs here?

That answer is usually stored in a PTR record.

At first, reverse DNS sounds like a technical mirror trick. For many websites, you can ignore it for years and never notice. Then you put a mail server on a VPS, send your first message, and discover that the receiving side cares very much about the identity of the IP address knocking on its door.

This is where PTR records stop being trivia.

A properly configured reverse DNS record helps connect an IP address to a meaningful hostname. Mail systems use that information as one signal when deciding whether a sending server looks legitimate. Monitoring platforms, security teams, log analysts, and network administrators also use reverse lookups to turn bare IP addresses into names humans can understand.

The unusual part is that you often cannot create this record in the same DNS panel where you manage your website.

To understand why, we need to turn the map around.

Chapter 1: Forward DNS is the map most people know

When you create a normal DNS record, you are usually mapping a hostname to something else.

For example:

mail.example.com.    A    203.0.113.25

That means:

If someone asks for the IPv4 address of mail.example.com, answer with 203.0.113.25.

The owner of example.com controls the authoritative DNS zone for that domain, either directly or through a DNS provider.

That is why you can create records such as A, AAAA, MX, TXT, CNAME, CAA, and other common types from your domain's DNS control panel.

Our guide DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS and More covers those forward-facing records in detail.

A reverse lookup asks a different question.

Instead of:

Where is mail.example.com?

it asks:

What name is associated with 203.0.113.25?

The answer lives in a different part of DNS.

Chapter 2: Meet the PTR record

PTR stands for pointer.

RFC 1035 defines the PTR record as a domain name pointing to another location in the DNS namespace. In reverse DNS, it is used to associate an IP address with a hostname.

For an IPv4 address such as:

203.0.113.25

the reverse DNS system represents the address under the special in-addr.arpa domain.

The octets are reversed, so the lookup is conceptually made against:

25.113.0.203.in-addr.arpa

A PTR record there might return:

mail.example.com

That reversal looks strange the first time you see it, but it lets DNS delegate reverse address space in an organized hierarchy.

IPv6 uses a related reverse structure under ip6.arpa.

You do not normally need to build those names by hand. Tools such as dig -x generate the correct reverse query for you.

Use our DNS lookup to inspect the forward A, AAAA, MX and TXT records. The PTR must be configured with the organization controlling your sending IP; use dig -x to check that reverse mapping. If you are considering our VPS or dedicated servers for mail, confirm PTR support and outbound SMTP policy with us before placing the service in production.

Chapter 3: Why your domain DNS panel may not control PTR

This is the part that surprises many VPS owners.

You own example.com, so you control the forward zone.

But do you own the IP block containing 203.0.113.25?

Usually not.

The VPS or cloud provider controls the address space or receives it through its upstream network. Reverse DNS follows ownership and delegation of the IP space, not ownership of your domain.

That means the provider normally controls the reverse zone.

So this:

mail.example.com.    A    203.0.113.25

is created in your normal DNS.

But the matching reverse entry:

203.0.113.25 -> mail.example.com

is usually configured in your VPS, dedicated server, or cloud provider's networking panel.

Some providers call the feature:

• Reverse DNS
• rDNS
• PTR
• PTR record
• IP hostname
• Reverse hostname

If you do not see it, support may need to create it for you.

This division of control is not a bug. It reflects the fact that a domain owner controls the domain namespace while the address provider controls the reverse mapping for its IP range.

Chapter 4: Why email servers care

When your mail server connects to another provider, the receiving system can see your public sending IP address.

It can ask DNS:

Does this IP have a reverse name?

Then it can ask a second question:

Does that name point back to the same IP?

Google's published sender guidelines require sending IP addresses to have valid forward and reverse DNS records. Google explains that the public sending IP should have a PTR record resolving to a hostname and that the same hostname should have an A or AAAA record resolving back to the sending IP.

That two-way consistency is often called forward-confirmed reverse DNS, or FCrDNS.

The simple pattern looks like this:

203.0.113.25
    PTR -> mail.example.com

mail.example.com
    A   -> 203.0.113.25

The road works in both directions.

This does not guarantee inbox delivery. Mail reputation is much broader than one DNS record. SPF, DKIM, DMARC, TLS, complaint rates, message quality, list hygiene, sending behavior, IP reputation, domain reputation, and other signals all matter.

But missing or broken reverse DNS gives receiving systems one more reason to distrust a server.

If you operate your own outbound mail from a VPS, PTR should be part of the initial build, not an afterthought after messages start landing in spam.

Follow our SPF, DKIM and DMARC guide for the domain-authentication layer. Our Email Security service addresses email protection needs; it does not replace configuring PTR or complying with a recipient provider’s sending requirements.

Chapter 5: PTR is not SPF, DKIM, or DMARC

These technologies are often discussed together because they all affect email operations, but they do different jobs.

PTR and reverse DNS

Connect an IP address back to a hostname.

SPF

Publishes which systems are allowed to send mail for a domain.

DKIM

Adds a cryptographic signature to a message so receivers can verify that signed content has not been changed and that the signature is associated with the signing domain.

DMARC

Adds policy and alignment rules around SPF and DKIM and can provide reports about authentication activity.

A mail server can have a perfect PTR record and still fail DMARC.

It can also have correct SPF, DKIM, and DMARC while its sending IP has poor reverse DNS.

Treat email authentication as a stack of related controls, not as a single magic record.

Chapter 6: Choosing the right PTR hostname

Suppose your server sends mail for example.com.

A sensible PTR hostname might be:

mail.example.com

or:

smtp.example.com

The exact label is less important than consistency and operational clarity.

Avoid setting the PTR to something that does not resolve forward.

Avoid using a hostname that points to a different IP.

Avoid generic or disposable-looking names when you can use a stable hostname that clearly represents the server.

If the same VPS hosts several websites, you still normally choose one primary server hostname for the IP's PTR record.

A single IP typically has one operational reverse identity even if the server handles many domains.

That surprises people who expect to create a separate PTR for every website or mail domain. Reverse DNS does not work like a collection of per-domain MX records.

Chapter 7: A clean setup for a VPS mail server

Assume the VPS has this public IPv4 address:

203.0.113.25

and you want to use:

mail.example.com

Step 1: Create the forward A record

In the authoritative DNS for example.com:

mail.example.com.    A    203.0.113.25

If the server uses IPv6, create the correct AAAA record as well.

Step 2: Set the PTR at the IP provider

In the VPS or cloud control panel, set reverse DNS for:

203.0.113.25

to:

mail.example.com

Step 3: Verify both directions

Check forward DNS:

dig A mail.example.com +short

Expected result:

203.0.113.25

Check reverse DNS:

dig -x 203.0.113.25 +short

Expected result:

mail.example.com.

Step 4: Check the server identity

Your mail software should use a coherent server hostname.

Depending on the software, this may be configured in Postfix, Exim, cPanel, Plesk, or another mail platform.

The exact setup varies, but the operational goal is simple: the server should introduce itself using a hostname that makes sense for the IP and DNS configuration.

Step 5: Add the rest of the email authentication

Configure SPF, DKIM, and DMARC for the domains that send mail.

PTR alone is not enough.

Chapter 8: The classic mismatch

Here is a common configuration:

mail.example.com -> 203.0.113.25

But reverse DNS returns:

203.0.113.25 -> vps-48372.hosting-company.example

Technically, the server may still send email.

Operationally, you have less control over the identity presented by the sending IP.

Another mismatch is worse:

203.0.113.25 -> mail.example.com

but:

mail.example.com -> 198.51.100.44

Now reverse DNS points to a hostname whose forward record leads somewhere else.

That inconsistency is easy to detect and unnecessary to keep.

Fix the forward and reverse sides so they agree.

For a business that prefers a hosted email platform to operating its own SMTP server, compare Google Workspace using our professional email comparison. A domain name provides the identity for your mail addresses; SPF, DKIM, DMARC and the provider’s infrastructure still need to be configured correctly.

Chapter 9: Why changing your A record does not change PTR

Suppose you migrate the mail server.

Old IP:

203.0.113.25

New IP:

198.51.100.40

You update:

mail.example.com.    A    198.51.100.40

Your website-style DNS change is complete.

But the PTR for the old and new IP addresses belongs to the corresponding IP providers.

You may need to:

1. Set the new IP's PTR to mail.example.com.
2. Verify the new forward A record.
3. Keep the old server available during the planned cutover if mail is still flowing.
4. Update SPF if the sending IP list changed.
5. Confirm DKIM and DMARC remain correct.
6. Check outbound mail behavior and reputation after the migration.

A DNS migration is not only about pointing names at the new machine. Server identity moves with the service.

Chapter 10: Shared IP addresses change the picture

Many hosting and email platforms use shared public IP addresses.

If you do not control a dedicated sending IP, you may not control the PTR record either.

That is normal.

In a shared environment, the provider manages the reverse identity of the shared infrastructure.

This is one reason you should not assume that moving a website to a VPS automatically improves email deliverability. A self-managed server gives you more control, but it also gives you more responsibilities.

If you are deciding whether you need shared hosting, VPS, dedicated infrastructure, or cloud services, see Shared Hosting, VPS, Dedicated and Cloud Compared.

Chapter 11: PTR records are useful beyond email

Reverse DNS appears in many operational tasks.

Log analysis

A security or web log may contain only IP addresses. Reverse lookups can provide useful hostnames, although names should never be treated as proof of identity by themselves.

Network troubleshooting

Administrators often use reverse DNS to recognize infrastructure while tracing routes or reviewing connections.

Monitoring

A meaningful server hostname makes dashboards and alerts easier to interpret than a wall of numeric addresses.

Incident response

During an investigation, reverse DNS can add context to an IP address. That context is a clue, not a verdict.

An attacker can control DNS for infrastructure they own, so a PTR value should not be treated as trusted evidence on its own.

Chapter 12: How to troubleshoot a missing PTR

Start with:

dig -x 203.0.113.25

If there is no PTR answer, confirm that the IP is really yours to use and identify which provider controls the address.

Then check the provider panel.

If a PTR exists but returns the wrong hostname, update it at the IP provider.

If the PTR is correct but the forward lookup fails:

dig A mail.example.com

repair the A or AAAA record in your normal DNS zone.

If both are correct locally but a remote system still reports a mismatch, consider caching and verify with more than one resolver.

SoxDomains' Domain Tools can help with normal public DNS checks, while command-line tools remain useful for direct reverse queries and troubleshooting.

Chapter 13: A pre-flight checklist before sending mail

Before putting a new VPS mail server into production, check:

• The server has a stable public IP.
• mail.example.com resolves to that IP.
• The IP's PTR resolves to mail.example.com.
• The hostname resolves back to the same IP.
• The server's mail hostname is configured consistently.
• SPF includes the correct sending infrastructure.
• DKIM signing is active.
• DMARC is published and monitored.
• TLS is enabled for mail transport.
• The IP is not unexpectedly listed on common blocklists.
• Test messages pass authentication checks.
• You are sending only wanted mail to legitimate recipients.

Email delivery is reputation plus configuration. DNS gives that reputation a clean technical foundation.