What Are PTR (Reverse DNS) Records and When You Need One

This guide explains what a PTR record is, why reverse DNS matters far more for email than for websites, and who is actually able to set one. A PTR (pointer) record maps an IP address back to a hostname, so it is the mirror image of the A record that maps a hostname to an IP. You will see the same idea called reverse DNS, reverse lookup, rDNS or simply "the PTR", and they all describe the same thing: given an IP address, what name does it claim to be? This article is for Noiz clients who have run into a mail-delivery warning that mentions reverse DNS, who are setting up a mail server on a Noiz VPS or dedicated server, or who simply want to understand a record that, unusually, they cannot edit themselves. The short version is that on Noiz shared and managed hosting the PTR for your outbound mail is already handled for you, and you only need to act when you send mail directly from your own server's IP address.

Last reviewed: 27 July 2026. Reverse DNS is defined by long-standing internet standards that change very rarely, so the mechanics described here are stable. The mail-deliverability behaviour, however, reflects how receiving mail servers currently treat a sending IP address, and providers tend to tighten these checks over time rather than loosen them. This guide is written for Noiz hosting and complements, and does not replace, the standards and provider documentation linked below.

Official Documentation Reference

• RFC 1035 (Domain Names, Implementation and Specification): the core DNS standard that defines the PTR record type and the A record it reverses.
• RFC 1912 (Common DNS Operational and Configuration Errors): explains why every IP that sends mail should have a matching reverse record, and the classic mistakes to avoid.
• RFC 8499 (DNS Terminology): the authoritative glossary, including the definitions of forward and reverse lookups and forward-confirmed reverse DNS.
• IANA .ARPA Zone Management: the registry for the in-addr.arpa and ip6.arpa zones where all reverse records ultimately live.

Prerequisites

• A basic idea of what an A record does, that is, that it points a name at an IP address. Reverse DNS makes most sense once you picture it as that arrow turned around.
• The IP address you are asking about. To look up or confirm a PTR you need the exact IP, so if you are not sure of it, first find the IP address of your domain or server.
• Access to a command line or an online reverse-lookup tool if you want to check a record yourself. This is optional, and the checks are shown further down.

Forward DNS and Reverse DNS: Two Directions of the Same Question

Ordinary DNS answers the question "what is the IP address for this name?". You type yourdomain.com, DNS returns an IP address using an A record (or an AAAA record for IPv6), and your browser connects to it. This is called forward DNS because it runs from name to number.

Reverse DNS answers the opposite question: "what name belongs to this IP address?". Something is given an IP address such as 192.0.2.25 and wants to know which hostname that address claims to be. The answer is stored in a PTR record. A useful mental picture is a phone directory: the A record is the ordinary listing that turns a name into a number, and the PTR record is a reverse directory that turns a number back into a name.

Because they are separate records held in separate places, the two directions can disagree. An IP can have a perfectly good A record pointing to it while having no PTR at all, or a PTR that names some completely unrelated host. That mismatch is exactly what many mail servers are looking for, as explained below.

Where PTR Records Live, and Why You Cannot Set Your Own

This is the single most important thing to understand about reverse DNS, and the point that catches most people out. A PTR record does not live in your domain's DNS zone. It is not something you add alongside your A, MX and TXT records. There is no field for it in a domain's DNS editor, whether that is your hosting control panel, the Noiz nameservers at ns1.noiz.co.za and ns2.noiz.co.za, or any third-party DNS host. You can have complete control of your domain's DNS and still be unable to touch your PTR.

The reason is that reverse records are organised by IP address, not by domain name, and they sit in a special reverse zone. IPv4 addresses map into the in-addr.arpa zone, with the octets written in reverse order, so the PTR for 192.0.2.25 is a record at 25.2.0.192.in-addr.arpa. IPv6 addresses map into the ip6.arpa zone in a similar back-to-front fashion. Authority over these reverse zones follows the chain of ownership of the IP address itself, not the domain:

• IANA delegates each large block of the in-addr.arpa space to a Regional Internet Registry. Africa's registry is AFRINIC, and the other regions are served by ARIN, RIPE NCC, APNIC and LACNIC.
• The registry delegates the reverse zone for a block of addresses to the network that holds that block, typically a hosting provider or an internet service provider.
• That provider, as the holder of the IP block, is the only party that can create or change the PTR records for those addresses.

For addresses on Noiz infrastructure, Noiz holds the relevant block, so Noiz sets the PTR. Your domain registrar cannot do it, your DNS host cannot do it, and you cannot do it from any control panel, because none of them own the IP address. This is by design: it stops anyone from claiming that an IP they do not control belongs to their brand. It also means the correct route to a PTR change on a Noiz server is a request to Noiz, never a DNS edit on your side.

Why PTR Records Matter for Email Deliverability

For a website, reverse DNS is almost irrelevant. A visitor's browser never checks the PTR of the server it is loading a page from, so a missing or odd PTR will not stop a site from working. Email is a different world entirely, and reverse DNS is one of the oldest and bluntest trust checks a receiving mail server performs.

When your server connects to another mail server to deliver a message, the receiving server sees the connecting IP address and, before it even looks at the message, it can ask reverse DNS what that IP claims to be. Two outcomes count heavily against you:

• No PTR at all. An IP that cannot even name itself looks like a home connection, a compromised machine or a throwaway spam source. Many receivers reject such connections outright, often with a message that mentions "no reverse DNS", "no PTR record" or "cannot resolve".
• A generic or mismatched PTR. A PTR that is plainly an automatically generated placeholder, or one that names a host with no connection to your mail, is treated as a weak signal. It may not cause an outright rejection, but it pushes your mail towards the spam folder or a slow, cautious acceptance.

The stronger test many receivers apply is forward-confirmed reverse DNS, sometimes shortened to FCrDNS. Here the receiver takes the PTR name your IP returns, then looks that name up in the forward direction, and expects it to resolve back to the very same IP. In other words, the reverse and forward records have to agree with each other. If your sending IP is 192.0.2.25, its PTR should name something like mail.yourdomain.com, and mail.yourdomain.com should have an A record pointing back to 192.0.2.25. When both halves line up, the receiver has good reason to believe the sender is a properly run mail server rather than a hijacked device.

It is worth being clear about the limits, because reverse DNS is often over-sold. A correct PTR is necessary for reliable delivery from your own IP, but it is not sufficient on its own. Modern deliverability still depends on the email-authentication records you publish in your own domain, chiefly SPF, DKIM and DMARC, together with a clean sending reputation. Think of the PTR as the doorman confirming your IP is who it says it is, while SPF, DKIM and DMARC prove the individual message is genuinely from your domain. You want all of them.

When You Actually Need a PTR Record

Most Noiz clients never have to think about a PTR, because it is only relevant when mail leaves a machine directly from an IP address you are associated with. Use this as a quick guide.

• Shared or managed Noiz hosting: nothing for you to do. Outbound mail from shared and managed hosting is sent through Noiz mail infrastructure, and the PTR records for those sending addresses are already set correctly and forward-confirmed by Noiz. Your deliverability work is confined to your own domain's SPF, DKIM and DMARC records, not the PTR.
• A Noiz VPS or dedicated server that sends its own mail: this is the case that needs attention. When a message is sent straight from your server, the receiving side sees your server's IP, so that IP needs a PTR that matches the hostname your mail server introduces itself as. This is set by requesting it from Noiz, as described in the next section.
• A server or VPS that only hosts a website and sends no mail from its own IP: you can safely leave the default PTR in place. It is good practice for every live IP to have some valid PTR, and Noiz provides one, but you do not need a custom value if nothing is sending mail from that address.
• Sending over IPv6: if your mail server also connects over IPv6, that IPv6 address needs its own matching PTR in the ip6.arpa zone. Some receivers are stricter about IPv6 reverse DNS than IPv4, so an IPv6 address without a PTR is a common and easily missed cause of rejections.

How PTR Is Handled on Noiz Hosting

Because only the holder of an IP block can edit its reverse zone, PTR on Noiz always works through Noiz rather than through your own panel. How much is automatic depends on your plan.

Shared and Managed Plans

On shared and managed hosting the mail-sending IPs belong to Noiz mail infrastructure and are looked after for you. Their PTR records already point to legitimate Noiz mail hostnames, and those hostnames resolve back to the same IPs, so forward-confirmed reverse DNS passes without any action on your part. If a receiver ever complains about reverse DNS for mail you sent from shared hosting, that points to a different issue, so raise it with Noiz support rather than trying to change a PTR yourself.

VPS and Dedicated Servers

On a VPS or dedicated server you are given one or more public IP addresses, and by default each carries a generic Noiz-provided PTR. That default is fine for a web-only server, but if you run a mail server you should request a PTR that matches your mail hostname. The steps are:

1. Decide on the hostname your mail server will announce itself as, for example mail.yourdomain.com. Replace yourdomain.com with your real domain; this is only an example value.
2. In your domain's DNS, create the forward record first: an A record for that hostname pointing to the server's IPv4 address, and, if you send over IPv6, an AAAA record pointing to the server's IPv6 address. You can set these yourself wherever your domain's DNS is hosted, including on the Noiz nameservers.
3. Open a ticket with Noiz support asking for the PTR (reverse DNS) on your server's IP address to be set to that same hostname. Give the exact IP address and the exact hostname, and mention the IPv6 address too if you send over IPv6.
4. Noiz sets the PTR in the reverse zone. Once it has propagated, the reverse and forward records agree, and forward-confirmed reverse DNS passes.

The order matters: set the forward A or AAAA record before or at the same time as requesting the PTR, so that the moment the PTR goes live the forward lookup already confirms it. A PTR pointing at a hostname that does not resolve back to the IP is only marginally better than no PTR at all.

How to Check a PTR Record Yourself

You can inspect any IP's reverse DNS without special access, which is handy for confirming a change or diagnosing a rejection. The lookups below use the documentation address 192.0.2.25; substitute the real IP you are checking.

On Linux or macOS, the dig tool does a reverse lookup with the -x flag:

dig -x 192.0.2.25 +short

A correctly configured address returns a hostname, such as mail.yourdomain.com. An empty result means there is no PTR for that IP.

On Windows, nslookup does the same job:

nslookup 192.0.2.25

If you do not have a command line to hand, any reputable online reverse-DNS or "reverse IP" lookup tool will show the same PTR value.

To confirm forward-confirmed reverse DNS, take the hostname the reverse lookup returned and look it up in the forward direction. It should resolve back to the IP you started with:

dig +short mail.yourdomain.com

When the reverse lookup gives you mail.yourdomain.com and the forward lookup of mail.yourdomain.com gives you back 192.0.2.25, the two agree and your reverse DNS is set up the way mail servers want to see it.

Troubleshooting

• Symptom: mail is bounced with a message mentioning "no PTR record", "no reverse DNS" or "client host does not resolve". The sending IP has no reverse record. If you are on shared or managed hosting this should not happen, so contact Noiz support. If you send from your own VPS or dedicated server, request a PTR for that IP from Noiz as described above, and make sure the matching forward A record exists.
• Symptom: the PTR is set but mail is still treated as suspicious. Check that forward-confirmed reverse DNS passes, that is, that the hostname in the PTR resolves back to the same IP. A PTR that names a hostname with no matching A record, or one pointing to a different IP, fails the check. Also remember that a correct PTR does not replace SPF, DKIM and DMARC; if those are missing or misaligned, mail can still be filtered.
• Symptom: you tried to add a "PTR record" in your control panel or DNS editor and nothing changed. That is expected. PTR records are not held in your domain's DNS zone and cannot be added there. The reverse record must be set by the holder of the IP block, which for a Noiz server means Noiz support.
• Symptom: IPv4 mail is fine but mail sent over IPv6 is rejected. The IPv6 address almost certainly lacks its own PTR in the ip6.arpa zone. Request a reverse record for the IPv6 address as well, and publish an AAAA record for the hostname so the forward and reverse agree.
• Symptom: a reverse lookup still shows the old value after a change. Reverse DNS is cached like any other DNS data, so a recent change can take time to appear everywhere. Allow for propagation, and re-check with a fresh lookup rather than relying on a cached result.

If your mail is being rejected for a reverse DNS reason, or you are standing up a mail server on a Noiz VPS or dedicated server and want the PTR set correctly, open a support ticket with the Noiz support team. Include the exact IP address, the hostname you want it to resolve to, and the text of any bounce message you received. On Noiz managed plans the support team can set the reverse record, confirm that the forward and reverse records agree, and check the wider picture of your mail authentication so that deliverability holds up beyond reverse DNS alone.