What Is a PTR Record (Reverse DNS) and Why Your Email Needs It

A PTR record, better known as reverse DNS, is the quiet piece of DNS that decides whether your email reaches the inbox or gets bounced at the door. Ultra Web Hosting sets and manages the PTR for every shared mail IP on our network, so most customers never think about it. But the moment you move to a dedicated IP, a VPS, or start troubleshooting mail that keeps getting rejected for "no reverse DNS", understanding PTR records matters. This guide explains what a PTR record is, who controls it, why receiving mail servers care so much, and exactly when you need to open a ticket so we can set or correct one for you.

01. What a PTR Record Actually Is

Almost all DNS you deal with is forward DNS: you look up a name and get back an IP address. A PTR record is the reverse. You hand it an IP address and it hands back a hostname. That is why "PTR record" and "reverse DNS" mean the same thing.

The reverse lookup is not stored in your domain's zone. It lives in a special zone called in-addr.arpa, built from the IP address written backwards. For an IP like 203.0.113.25, the PTR question is asked against the name 25.113.0.203.in-addr.arpa, and the answer is a hostname such as mail.yourdomain.com. The address is reversed because DNS reads names from most specific on the left to least specific on the right, and IP addresses are the other way around.

The practical takeaway: a PTR record answers one question about one IP address, "what hostname does this IP claim to be?" Every well-run mail server on the internet asks that question about the IP connecting to it.

02. Forward vs Reverse DNS

The cleanest way to keep these straight is to remember which direction each one points.

03. Why Receiving Mail Servers Check the PTR

When your mail server connects to a recipient's mail server to deliver a message, the receiving side does a quick background check before it accepts anything. One of the first things it does is a reverse lookup on the connecting IP. What it finds there weighs heavily on whether your message is accepted, filed as spam, or refused outright.

Three outcomes, from best to worst:

1. A clean, matching PTR. The IP has a PTR that resolves to a real hostname, and that hostname's A record points back to the same IP. This is the signal a legitimate mail server sends.
2. A generic or mismatched PTR. The IP resolves to something like 203-0-113-25.pool.example-isp.net, or to a hostname whose A record does not point back to the IP. Many servers treat this as a spam signal and drop your score.
3. No PTR at all. The reverse lookup returns nothing. A large number of mail servers reject this connection immediately, with an error that mentions "no reverse DNS" or "cannot resolve PTR".

The strict version of this check is called FCrDNS, forward-confirmed reverse DNS. The receiving server takes the PTR hostname, looks up that hostname's A record, and confirms it resolves back to the exact IP that connected. If the round trip matches, the IP passes. If it does not, the mail is treated with suspicion. This is why a PTR that merely exists is not enough on a dedicated IP; it has to point to a hostname that points back.

04. Who Controls the PTR (Not You, and Not cPanel)

This is the single most misunderstood thing about reverse DNS, so it is worth being blunt. The PTR record is not controlled by the domain owner, and it is not set in cPanel Zone Editor. It is controlled by whoever owns the IP block that the address belongs to.

Think about why. Your domain zone is yours, so you can put whatever A and MX records you like in it. But an IP address is not yours; it is assigned to your hosting provider or ISP out of a block they were allocated. Reverse DNS for that block is delegated to them, not to you. If domain owners could set the PTR for any IP, anyone could make any IP claim to be any hostname, and the whole point of the check would collapse.

So on our shared hosting, your outbound mail leaves from a shared mail IP that we own, and we have already set a correct, mail-friendly PTR on it. You do not need to do anything, and there is nothing to configure in Zone Editor even if you wanted to.

05. How to Check Your Sending IP's PTR

Before you can check a PTR, you need to know which IP your mail actually leaves from. That is not always the IP your website resolves to.

1. Find your sending IP. The simplest method: send an email from your domain to an outside account you control, open the received message, and view its headers. Look at the earliest Received: line added by your own mail server. The IP in there is the address your mail is leaving from. On our shared hosting this will be the shared mail IP for your server.
2. Do a reverse lookup on that IP. Run the IP through our DNS Lookup tool and request the PTR or reverse record. It returns the hostname the IP resolves to.
3. Read the result. If it returns a clean mail hostname, you are in good shape. If it returns nothing, the IP has no PTR. If it returns a generic ISP-style name that does not match your mail hostname, the PTR exists but is not ideal for a dedicated setup.

06. Shared IP vs Dedicated IP

Whether you ever need to think about PTR at all depends on which kind of IP you send mail from.

When does the dedicated-IP distinction actually matter? If you send meaningful volume, run mail to strict corporate recipients, or want your reverse DNS to carry your own brand and reputation rather than a shared one, a dedicated IP with a matching PTR is worth it. For a small business sending everyday mail, the shared IP is usually perfectly fine.

07. PTR and Home or Dynamic IP Addresses

This is why you cannot reliably run a mail server from your home or office internet connection, even if the software works. Residential and most business broadband connections use IP addresses out of pools that ISPs mark with generic, dynamic-looking PTR records, things like host-203-0-113-25.dynamic.example-isp.net.

Receiving mail servers treat those PTR patterns as a strong signal that the connection is a home computer or a compromised machine sending spam, because that is overwhelmingly what mail from such IPs turns out to be. Many providers block dynamic IP ranges outright, regardless of how correct your SPF and DKIM are. You also normally cannot get the ISP to set a custom PTR on a residential IP.

08. How PTR Fits With SPF, DKIM, and DMARC

Reverse DNS is not a replacement for email authentication, it sits underneath it. Think of PTR as the IP-reputation layer, and SPF, DKIM, and DMARC as the identity-and-authorization layer built on top.

• PTR (reverse DNS) answers "is this IP a legitimate, identifiable mail server?" It is about the connection itself, before a single header is read.
• SPF answers "is this IP allowed to send for this domain?" See our SPF guide for the syntax and setup.
• DKIM answers "was this message signed by the domain and not tampered with?" Covered in our DKIM guide.
• DMARC ties SPF and DKIM together and tells receivers what to do on failure. See our DMARC guide.

A strong sending setup has all of it: a clean PTR on the sending IP, SPF authorizing that IP, DKIM signing the message, and DMARC enforcing alignment. Miss the PTR layer and your mail can be refused before SPF or DKIM ever get a chance to pass. For the full picture of how the three authentication records work together, read our email authentication overview, and if you are chasing deliverability problems, our guide "Why Is My Email Going to Spam and How to Fix It" walks through the whole checklist.

09. When to Contact Us

For the great majority of shared-hosting customers, the answer is never; the shared IP's PTR is already correct. You should open a ticket in these specific cases:

1. You have a dedicated IP and want the PTR set to your own domain. Tell us the IP and the hostname you want it to resolve to, for example mail.yourdomain.com. Make sure that hostname's A record already points to the IP so forward confirmation lines up.
2. You have a VPS and need a PTR set or corrected. New VPS IPs may start with a generic PTR. We set it to your chosen mail hostname on request.
3. Your mail is bouncing for "no reverse DNS" or a mismatched PTR. If a reverse lookup on your sending IP returns nothing or the wrong name, we fix it in the reverse zone.

When you open the ticket, include the exact IP address and the exact hostname you want the PTR to return. That lets us make the change in one pass without back-and-forth.

10. Troubleshooting Reverse DNS Problems

Mail rejected with "no reverse DNS" or "cannot find your reverse DNS". The sending IP has no PTR. Confirm the IP with a message header, run it through our DNS Lookup tool, and if the reverse lookup is empty, open a ticket so we can set the PTR (dedicated IP or VPS). On shared hosting this should not happen; if it does, tell us the IP and we will investigate.

The PTR exists but does not match my mail hostname. This is a mismatch that breaks forward-confirmed reverse DNS. On a dedicated IP, open a ticket to have the PTR corrected to your mail hostname, and make sure that hostname's A record points back to the same IP.

My PTR points to my domain but recipients still flag me. PTR is only one layer. Confirm your SPF, DKIM, and DMARC records are all in place and passing. A clean PTR with broken authentication still lands in spam.

I changed the PTR but a checker still shows the old value. Reverse DNS caches like any other DNS. Give it time to propagate and re-check; the same patience applies as with forward records in our DNS propagation guide.

I cannot find where to add a PTR in cPanel. You will not find one, and that is expected. PTR is not a Zone Editor record. Open a ticket for any PTR change on a dedicated IP or VPS.

Quick Recap: Reverse DNS in Six Points

If you only take a handful of things from this guide, take these:

1. PTR is the reverse of an A record, mapping an IP address back to a hostname, stored in the in-addr.arpa zone.
2. Receiving mail servers check it on every connection; no PTR or a mismatched one is a strong spam signal, and many servers reject outright.
3. You do not control the PTR, and it is not in cPanel Zone Editor. Whoever owns the IP block sets it, which on our hosting is us.
4. Shared IP PTR is already set by us; a dedicated IP lets us point the PTR at your own mail hostname for full forward-confirmed reverse DNS.
5. You cannot reliably send mail from a home connection because residential IPs carry generic dynamic PTRs that recipients block.
6. Open a ticket for any PTR change on a dedicated IP or VPS, and set the matching A record first.

Last updated July 2026 · Browse all DNS articles