What Is Reverse DNS (PTR Record)? A Practical Guide to Fixing Email Spam Issues

What Is Reverse DNS (PTR Record) and Why It Matters for Email

One of the most common reasons I see business emails landing in spam folders is a missing or incorrectly configured reverse DNS, also known as a PTR record. You can have perfectly written messages, a clean IP, and even SPF/DKIM in place, but if your mail server’s IP address does not resolve back to a meaningful hostname, many providers will quietly reduce your reputation or reject your messages outright. In this article, I’ll walk through what reverse DNS actually is, how PTR records work in practice, and how you can fix them to stop spam issues on your own mail server or VPS. Whether you run your own infrastructure, use a managed server at a provider such as DCHost, or simply want to understand what your IT team is talking about, you’ll find practical, step-by-step guidance here.

How Reverse DNS (PTR Record) Works in Simple Terms

DNS is usually used to translate domain names into IP addresses. When someone visits example.com, a DNS query asks, “What IP belongs to this name?” That’s called a forward lookup, typically answered by an A (IPv4) or AAAA (IPv6) record.

Reverse DNS simply flips this question. Given an IP address, it asks, “What hostname belongs to this IP?” The record that answers this question is the PTR (Pointer) record. So:

Forward DNS: mail.example.com → 203.0.113.10 (A record)
Reverse DNS: 203.0.113.10 → mail.example.com (PTR record)

If you’re not fully comfortable with basic DNS concepts like A, MX or TXT records, it’s worth reviewing this detailed guide on managing DNS records such as A, CNAME, MX and TXT before you change anything.

Who Controls Reverse DNS?

This part is critical: you cannot usually set PTR records from your domain’s DNS panel. Forward DNS (A, MX, TXT) is managed at your domain registrar or DNS provider. Reverse DNS, however, belongs to whoever owns the IP address block – typically your hosting or data center provider.

That’s why, in most setups, you must either:

Use the provider’s control panel to set reverse DNS, or
Open a ticket and ask support (for instance, the support team at DCHost) to configure a PTR for your IP.

Forward vs Reverse DNS Alignment

Mail providers don’t just check that a PTR exists; they also compare it with forward DNS. A common best practice is:

Your IP (e.g., 203.0.113.10) should have a PTR pointing to mail.example.com.
mail.example.com should have an A record pointing back to 203.0.113.10.

This is often called forward-confirmed reverse DNS (FCrDNS). It’s not a formal standard, but many spam filters treat this as a strong positive signal that your server is legitimate and correctly configured.

Why Missing or Wrong PTR Records Cause Spam Problems

Every time your server sends an email, the receiving side performs a series of trust checks. Reverse DNS is one of the earliest and simplest filters: it answers the question, “Does this IP look like a real mail server, or a random infected machine?”

Common Reverse DNS Red Flags

Based on real-world mail server audits, these patterns almost always hurt deliverability:

No PTR record at all – the IP doesn’t map to any hostname.
Generic PTR hostnames such as ip-203-0-113-10.provider.net that don’t match your domain.
Mismatch between PTR and A record – PTR points to one hostname, but that hostname’s A record points to a different IP.
Dynamic or residential-looking names like dsl-203-0-113-10.isp.local, which strongly resemble consumer internet connections, not mail servers.

Many major mail providers will either score such IPs lower or flat-out block them for direct SMTP connections. Even if they accept messages, they are much more likely to route them into spam folders.

PTR Is One Piece of a Bigger Puzzle

Reverse DNS doesn’t work alone. Modern spam filters look at a combination of:

PTR records and FCrDNS alignment
SPF (which IPs may send for your domain)
DKIM (cryptographic signatures of messages)
DMARC (your policy on handling SPF/DKIM failures)
IP reputation and blacklist status
Content, user engagement and past behavior

To build a professional email setup, you should combine reverse DNS with these other records. For a step-by-step walkthrough on the rest of the email stack, see this guide on setting up professional email with MX, SPF, DKIM and DMARC.

How to Check Your Current Reverse DNS (Step-by-Step)

Before changing anything, you should see what is already configured on your IP address. You can do this from a Linux, macOS, or even Windows machine with the right tools.

1. Find the IP Address of Your Mail Server

First, identify which IP is actually sending your email. On most self-hosted setups:

Your mail server hostname is something like mail.example.com.
Use a DNS lookup to get the IP: dig mail.example.com A or nslookup mail.example.com.

If you manage DNS yourself, this ties back into your general DNS design. For more context, you can read the domain DNS management guide on pointing your website, email and subdomains correctly.

2. Check the PTR Record with dig, host or nslookup

Once you have the IP, use a reverse lookup:

dig: dig -x 203.0.113.10 +short
host: host 203.0.113.10
nslookup: nslookup 203.0.113.10

The output should be a single, clean hostname, for example:

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

If you see nothing, multiple inconsistent lines, or a generic provider hostname, you’ve likely found a major cause of your spam issues.

3. Verify Forward-Confirmed Reverse DNS

Next, check that the hostname returned by the PTR record points back to the same IP:

dig mail.example.com A +short

If the result is the same IP (203.0.113.10 in our example), you have FCrDNS alignment. If it’s different, update your forward DNS records or request a new PTR to match your desired mail hostname.

4. Check Multiple Sender IPs

In some setups, your emails may leave through:

A main mail server IP
A secondary outbound relay IP
IPv6 addresses, if enabled on your server

Repeat the reverse DNS checks for each IP that can send email. If you’re already using IPv6 on your VPS, remember that IPv6 addresses need their own ip6.arpa PTR records. For help with IPv6 configuration, you can review the IPv6 setup and configuration guide for VPS servers.

Fixing Reverse DNS for Your Email Server

Once you’ve identified what’s wrong, the fix is usually straightforward. The details differ slightly between providers, but the overall logic is always the same.

1. Choose a Proper Mail Hostname

Pick a stable, descriptive hostname for your mail server. Common patterns include:

mail.example.com
smtp.example.com
mx1.example.com

Use a subdomain under the main domain that appears in your email addresses (the part after @). Avoid using raw domain names (like example.com) as the server hostname; dedicated subdomains are cleaner and easier to manage.

2. Create or Correct the A Record

On your domain’s DNS panel (usually at your registrar or DNS provider):

Create an A record for your chosen hostname, for example:
mail.example.com → 203.0.113.10
Make sure your MX record for the domain points to this hostname if it will receive mail as well, for example:
example.com MX 10 mail.example.com

If you need a refresher on how A and MX records interact, the article explaining how to manage A, CNAME, MX, TXT and other DNS records provides plenty of practical examples.

3. Request or Configure the PTR Record

Now that your hostname points to the correct IP, it’s time to align reverse DNS. This step depends on your hosting setup:

With a control panel: Some VPS or dedicated providers (including DCHost on compatible services) allow you to set reverse DNS directly from their management panel. You simply choose the IP and enter the hostname, e.g., mail.example.com.
Via support ticket: If you don’t see an rDNS or PTR option, open a ticket and ask support to set the PTR of 203.0.113.10 to mail.example.com.

Remember: only the owner of the IP block can change reverse DNS, so you must coordinate with your provider.

4. Example of Good vs Bad PTR Configuration

Here are simple patterns I recommend in real deployments:

Good: 203.0.113.10 → mail.example.com and mail.example.com → 203.0.113.10
Acceptable: 203.0.113.10 → smtp.example.com with matching A record
Bad: 203.0.113.10 → 203-0-113-10.hosting.local
Bad: PTR points to mail.example.com, but mail.example.com A record points to a different IP

5. Wait for DNS Propagation and Re‑Test

Once the PTR is changed, it may take some time to propagate, depending on the TTL (Time To Live) set on the reverse zone. In practice, you’ll usually see the new value within a few minutes to a few hours. After that, repeat your checks:

dig -x 203.0.113.10 +short → should return mail.example.com.
dig mail.example.com A +short → should return 203.0.113.10.

Then send test emails to major providers and check whether they still land in spam. Reverse DNS alone won’t fix all reputation problems, but it removes a very basic and visible misconfiguration.

Special Cases: Shared IPs, Multiple Domains and IPv6

Real infrastructures are rarely perfect one-domain-per-IP setups. Here are a few edge cases you’ll likely encounter.

Shared IP Addresses (Typical Shared Hosting)

On classic shared hosting plans, hundreds of domains may send email from the same IP. In such environments, you cannot get a custom PTR just for your domain. The provider sets one PTR for the IP, and everyone shares it.

If you need full control over reverse DNS and outgoing IP reputation, the usual solution is:

Move your email to a VPS or dedicated server where you control an IP, or
Use a service plan (for example at DCHost) that gives you a dedicated outbound IP with configurable rDNS.

Multiple Domains on One IP

It’s common to host several domains on the same mail server IP. In that case:

You can only have one PTR for the IP.
Choose a neutral canonical hostname, such as mail.primarydomain.com.
Configure other domains’ SPF/DKIM/DMARC to authorize that hostname/IP combination.

Spam filters are used to seeing one PTR name serve several domains, as long as the rest of the configuration is consistent and clean.

IPv6 Reverse DNS

As more data centers and providers deploy IPv6, you may run dual-stack mail servers. The principles are exactly the same, but the records live in the ip6.arpa tree and look a bit more complex. Your hosting provider still controls the reverse zone and must configure the IPv6 PTR for you.

If you’re planning to enable IPv6 on your mail server, it’s worth reading the IPv6 setup and configuration guide for your VPS server to avoid subtle pitfalls like missing AAAA records or misaligned rDNS.

Beyond PTR: Building a Clean Email Infrastructure

Fixing reverse DNS is an important step, but for consistent inbox placement, you should think of it as part of a broader email infrastructure checklist.

Combine PTR with SPF, DKIM and DMARC

After aligning your PTR and A records, make sure you:

Publish an SPF record authorizing your mail server IP(s).
Enable DKIM signing on your mail server or control panel.
Set up a basic DMARC policy and monitor reports.

Together with reverse DNS, these signals tell receiving servers that your domain and IPs are aligned, authenticated and under your control. You can follow a complete configuration flow in the article on setting up professional email with MX, SPF, DKIM and DMARC.

Leverage Existing Experience and Resources

If you prefer to read about this topic in Turkish, there is also a dedicated article on the same subject: Reverse DNS (PTR Kaydı) Nedir? E-posta Sunucularında Spam Sorunlarını Çözme Rehberi. Together with the DNS and email guides already published on berkaybulut.com, it forms a solid reference set when you design or audit your mail infrastructure.

Conclusion: Treat Reverse DNS as Basic Email Hygiene

Reverse DNS is not a fancy optimization; it’s a basic identity card for your mail server. When an IP doesn’t have a proper PTR, or when its PTR points to a mismatched or generic hostname, many spam filters immediately assume something is wrong. By choosing a clear mail hostname, aligning A and PTR records, and working with your provider (such as DCHost) to configure rDNS correctly, you eliminate one of the most visible misconfigurations that harms deliverability.

From there, you can focus on higher-level improvements: fine-tuning SPF/DKIM/DMARC, monitoring IP reputation, and optimizing your content and sending patterns. If you systematically review your DNS setup using the techniques in this article—along with resources like the DNS records management guide and the professional email configuration tutorial—you’ll bring your infrastructure much closer to what large providers expect. The result is simple but valuable: more emails in the inbox, fewer in spam, and far fewer mysterious delivery problems.