How To Add PTR Record In Cloudflare 2026 | is it possible - Truth revealed

Every DNS record you normally deal with is a forward lookup: a name in, an address out. A PTR record runs the other way — an IP address in, a hostname out.

The main reason anyone needs one is email. Receiving mail servers check whether the IP that just connected to them resolves back to a sensible hostname, and whether that hostname resolves forward to the same IP.

This pair, called forward-confirmed reverse DNS, is one of the cheapest spam signals in existence, and a mail server without it gets marked down or rejected outright regardless of how good its SPF and DKIM setup is. If you are here because your outbound mail is landing in spam, a missing PTR is a genuinely likely cause.

Reverse DNS does not live in your domain's zone at all. It lives in a separate namespace under in-addr.arpa for IPv4 and ip6.arpa for IPv6, and authority over a chunk of that namespace is delegated to whoever was allocated the IP block — your VPS host, your cloud provider, or your ISP.

Cloudflare is authoritative for example.com; it is not authoritative for the reverse zone covering your server's address, unless you are a Cloudflare enterprise customer who has actually delegated a block to them. So a PTR record sitting in your forward zone is a record nobody ever queries. The resolver asking "who is 203.0.113.45?" goes to the reverse zone's nameservers, which belong to your host, and never touches your Cloudflare zone.

Even knowing that, it is worth seeing the form, because it is what convinces most people the feature works. Log in to Cloudflare and select the domain from your account — the zone overview shows its status, its plan, and a DNS panel on the right with a link straight to DNS Records.

In the left sidebar, DNS expands into Records, Analytics and Settings. Records is the full editor for the zone. Note the DNS Setup line on this page too: Full means Cloudflare is authoritative for the whole zone, which is the setup where people most reasonably assume every record type here is functional.

Click Add record and open the Type dropdown. PTR is there, alongside A, AAAA, CNAME, MX, TXT and the rest.

Select it and the form rewrites itself with a plain-language hint above the fields: [domain name] points to [name] in a reverse lookup. You get three inputs.

Name is the reverse-notation address — the four octets of your IP written backwards with .in-addr.arpa appended, so 203.0.113.45 becomes 45.113.0.203.in-addr.arpa. Domain name is the hostname you want that address to resolve to, such as mail.example.com.

TTL can stay on Auto. There is also a Record Attributes section with a comment field, which Cloudflare notes does not affect resolution and is purely for your own reference.

Save that record and Cloudflare accepts it happily. It will appear in your records list, and you can even query it directly against Cloudflare's nameservers and get an answer back.

What you cannot do is get the rest of the internet to see it, because no resolver on earth asks your domain's nameservers about 45.113.0.203.in-addr.arpa — it asks the nameservers that the ARIN, RIPE or APNIC delegation chain points to for that block. The mail server rejecting your messages will keep rejecting them.

The one legitimate case for a PTR record inside a forward zone is when your provider has delegated the reverse zone to Cloudflare and you are hosting that zone here on purpose, which is rare and something you would know about. Otherwise, delete it to avoid confusing yourself in six months.

The real fix is with whoever assigned your IP. Most VPS and cloud providers expose this as a field in their own panel: Hetzner, DigitalOcean, Linode, Vultr, OVH, AWS and Google Cloud all have a reverse DNS or PTR setting attached to the server or elastic IP, sometimes editable directly and sometimes gated behind a support request.

On AWS you request the removal of outbound mail restrictions and set rDNS through a form; on shared hosting you generally cannot set it at all, which is a real argument for sending mail through a dedicated provider instead. Before you request it, create the matching forward record in Cloudflare: an A record for mail.example.com pointing at the same IP. Reverse and forward must agree, and providers will often refuse a PTR request whose target does not already resolve back to the address.

Once the provider has applied it, check from a machine outside your network with dig -x 203.0.113.45 on macOS or Linux, or nslookup on Windows, and confirm the hostname that comes back matches the one that resolves forward to that IP. Propagation for rDNS is usually quick but can take a few hours.

Then use Cloudflare for everything it genuinely is authoritative over, which is most of your email setup: MX records pointing at your mail host, a TXT record with your SPF policy, the CNAME or TXT records your provider gives you for DKIM, and a DMARC TXT record at _dmarc. Those four plus a working PTR are the full deliverability checklist — and four of the five really do belong in the record editor you just opened.