---
title: "What is reverse DNS (PTR) and why your server needs it | StreetHosting"
description: "Understand reverse DNS and the PTR record: how the lookup works, why mail servers require it, how to check it with dig and nslookup, and how to request yours."
url: "https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns"
type: "page"
language: "en-US"
---

Infrastructure · 11 min · Intermediate

Published on Sep 28, 2026 · Updated on Sep 28, 2026

# Reverse DNS in practice: how the PTR record identifies your IP

Regular DNS turns a name into an IP; reverse DNS goes the other way, through the PTR record. See who controls that record, why it weighs so heavily on email delivery, how to look it up and how to request the PTR for your server.

By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team

[Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking)

Summarize with:

[](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity")

Share:

[](https://x.com/intent/tweet?text=What%20is%20reverse%20DNS%20%28PTR%29%20and%20why%20your%20server%20needs%20it&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns "Share on LinkedIn") [](https://wa.me/?text=What%20is%20reverse%20DNS%20%28PTR%29%20and%20why%20your%20server%20needs%20it%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-reverse-dns "Share on WhatsApp")

For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns.md)

In this guide 8 sections

* [What reverse DNS is](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#o-que-e)
* [How a reverse lookup works](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#como-funciona)
* [FCrDNS: reverse and forward in agreement](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#fcrdns)
* [Why email depends on the PTR](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#email)
* [PTR in traceroute, logs and bots](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#traceroute-logs)
* [How to look up reverse DNS](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#consultar)
* [How to request the PTR for your server](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#configurar)
* [A server with its own IP for email](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#onde-hospedar)

Quick answer

**Reverse DNS** is the lookup that starts from an IP and returns a name, through the **PTR record**. Its job is to identify the server: mail servers check the PTR of whoever connects, traceroutes show the names of the routers, and logging and bot verification systems rely on the reverse. The PTR is controlled by the owner of the IP block, so the provider is the one who configures it, at the customer's request through support. For email, the PTR has to point to a name you own that resolves back to the same IP.

## What reverse DNS is[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#o-que-e)

In the regular DNS everyone knows, you ask for the IP of a name and get the answer in an A record, for IPv4, or an AAAA record, for IPv6. Reverse DNS asks the question the other way around: given the IP 203.0.113.10, what is its name? The answer comes in a PTR record, short for pointer.

The most important difference is not technical, it is about control. The A record for mail.exemplo.com.br lives in the domain's zone, which is yours. The PTR for 203.0.113.10 lives in a zone that belongs to whoever received that block of addresses, meaning the provider or datacenter. That is why the domain owner and the IP owner have to agree for the whole thing to make sense.

| Record   | Question it answers                      | Example answer      | Who controls it |
| -------- | ---------------------------------------- | ------------------- | --------------- |
| A        | What is the IPv4 of mail.exemplo.com.br? | 203.0.113.10        | Domain owner    |
| AAAA     | What is the IPv6 of mail.exemplo.com.br? | 2001:db8::10        | Domain owner    |
| MX       | Who receives email for exemplo.com.br?   | mail.exemplo.com.br | Domain owner    |
| IPv4 PTR | What is the name of 203.0.113.10?        | mail.exemplo.com.br | IP block owner  |
| IPv6 PTR | What is the name of 2001:db8::10?        | mail.exemplo.com.br | IP block owner  |

Almost every datacenter IP is born with a generic PTR, created in bulk by the provider, in the format `203-0-113-10.provedor.net` or similar. It does the bare minimum of existing, but says nothing about your service, and some spam filters treat names like that as a sign of a residential or dynamic IP.

## How a reverse lookup works[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#como-funciona)

DNS is a tree read from right to left: first br, then com.br, then exemplo.com.br. An IPv4 address grows in the opposite direction, from the most general on the left to the most specific on the right. To fit into the tree, the IP is written backwards, inside a special domain. The reverse of 203.0.113.10 is looked up as `10.113.0.203.in-addr.arpa`.

With IPv6 the rule is the same, except that each hexadecimal digit becomes a level, with the address written out in full and reversed, under ip6.arpa. The result is long, and nobody types it by hand; the tools build it on their own:

`IPv4 203.0.113.10 10.113.0.203.in-addr.arpa IPv6 2001:db8::10 (expanded: 2001:0db8:0000:0000:0000:0000:0000:0010) 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa`

### Who answers at each level[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#delegacao)

The reverse zone follows the distribution of addresses. IANA hands large blocks to the regional registries; in Latin America that is LACNIC, and in Brazil numbering is managed by NIC.br, through Registro.br. They delegate the reverse zone of each block to the organization that received it, usually the provider or the datacenter. It is that provider's DNS server that answers the PTR for your IP.

| Level                            | Who answers                 | What it delegates                                          |
| -------------------------------- | --------------------------- | ---------------------------------------------------------- |
| Root of the reverse zone         | IANA                        | Large blocks to each regional registry                     |
| Regional or national registry    | LACNIC and NIC.br in Brazil | Blocks to providers and companies with their own numbering |
| Provider or datacenter           | The provider's DNS server   | The PTRs of each IP handed to customers                    |
| VPS or dedicated server customer | Usually nobody              | Requests the PTR from the provider through support         |

Blocks smaller than a /24 have their own delegation technique, described in RFC 2317, which some providers use for companies that want to manage their own reverse. For anyone with a VPS or a dedicated server with a few IPs, the path is a request to the provider. With `dig -x 203.0.113.10 +trace` you can see every hop of that delegation down to the server that answers.

## FCrDNS: reverse and forward in agreement[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#fcrdns)

Whoever controls an IP block can put any name in the PTR, including another company's name. That is why the PTR alone proves nothing. The proof comes from FCrDNS, short for forward-confirmed reverse DNS: look up the IP's PTR, take the name returned, look up that name's A or AAAA record and check whether the original IP is in the answer. If it is, the block owner and the domain owner agree.

`dig -x 203.0.113.10 +short # mail.exemplo.com.br. dig mail.exemplo.com.br A +short # 203.0.113.10 <- same IP: valid FCrDNS # typical failure: PTR points to a name that resolves to another IP or does not resolve dig mail.exemplo.com.br A +short # (empty) <- invalid FCrDNS`

If the server has IPv6 enabled, the same check applies to it. A mail server with IPv6 configured may go out over IPv6 when talking to Gmail and other large providers, which publish MX on both protocols, and an IPv6 without a PTR breaks delivery even when the IPv4 is flawless. Either the IPv6 address also gets a PTR and an AAAA record, or the mail server switches to IPv4 only (in Postfix, `inet_protocols = ipv4`). How IPv6 works in hosting is covered in the guide on [IPv6 on servers](https://streethosting.com.br/en/guides/infrastructure/how-ipv6-works).

## Why email depends on the PTR[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#email)

When your server delivers a message, it opens a connection to port 25 on the destination server. The first thing the destination sees is the source IP, before it even reads the sender. That is why the reverse comes into play early: an IP with no PTR, with a generic PTR or with broken FCrDNS starts the conversation at a disadvantage.

Gmail asks, in its sender guidelines, that sending domains and IPs have valid forward and reverse DNS. Postfix servers can refuse clients without a PTR with `reject_unknown_reverse_client_hostname` or require full FCrDNS with `reject_unknown_client_hostname`. Filters like SpamAssassin and Rspamd add points against IPs with no reverse. The PTR is one check among several:

| Check          | What it proves                                           | Where it is configured                  | Who controls it  |
| -------------- | -------------------------------------------------------- | --------------------------------------- | ---------------- |
| PTR and FCrDNS | The IP has an identity consistent with a domain          | Reverse zone and A record               | Provider and you |
| HELO or EHLO   | The name the server announces when it connects           | Mail server configuration               | You              |
| SPF            | This IP may send on behalf of the domain                 | TXT record on the domain                | You              |
| DKIM           | The message was signed by the domain and was not altered | Key on the server and TXT on the domain | You              |
| DMARC          | What to do when SPF and DKIM do not match the sender     | TXT record at \_dmarc                   | You              |

Ideally three names match: the IP's PTR, the name announced in HELO, which in Postfix comes from `myhostname`, and the A record that points back to the IP. With that aligned, the IP starts building reputation tied to a name of yours, instead of being just another anonymous datacenter address. The PTR does not clean an IP that is already on a blocklist, and it does not make up for sending to a purchased list; it only stops the server from being treated as suspect by default.

### A PTR without port 25 open delivers nothing[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#porta-25)

Many providers block outbound port 25 by default, because a compromised VPS turns into a spam sender within minutes and ruins the reputation of the whole block. Some open it on request after a review, others never do. Before building a mail server, test the outbound path:

`nc -vz -w 5 gmail-smtp-in.l.google.com 25 # succeeded / open -> outbound 25 is open # timed out -> outbound blocked along the path`

If 25 is closed, the way out is to send through an authenticated relay on port 587. In that case the relay is what delivers the message to the destination, and the PTR that matters for delivery is the relay's, not yours. The port 25 policy, the relay and server-side antispam are covered in the guide on [MailCow, antispam and port 25](https://streethosting.com.br/en/guides/infrastructure/mailcow-email-server-vps).

## PTR in traceroute, logs and bots[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#traceroute-logs)

Outside email, the reverse shows up whenever a tool swaps IPs for names to make the output easier to read. In a traceroute, the routers along the path usually have PTRs that reveal the carrier, the interface type and the city, often with airport codes: GRU points to São Paulo, MIA points to Miami. That is how you find out, in a [traceroute to diagnose the route](https://streethosting.com.br/en/guides/infrastructure/how-to-use-traceroute), that the traffic of a player in Brazil's Northeast is taking a detour through the United States.

* **Router names are clues, not proof.** Infrastructure PTRs go stale when the carrier swaps equipment, and the city in the name may not be the real one.
* **Slow resolution delays the diagnosis.** With `traceroute -n` or `mtr -n` the tool shows only IPs, which helps when the reverse DNS of the hops is slow to answer. [MTR](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr) combines both with loss per hop.
* **Server logs.** OpenSSH has not looked up the reverse of whoever connects since version 6.8, because the lookup delayed login and the name could be forged; the logs show the IP. Web servers also log the IP by default, and resolving names is left for analysis.
* **Bot verification.** Google recommends confirming that a hit really came from Googlebot with FCrDNS: the PTR has to end in googlebot.com or google.com, and that name has to resolve back to the same IP. A user agent alone can be faked by anyone.

Never use the PTR alone to grant access, as in a firewall rule or an allowlist by name. Whoever controls the source IP block picks whatever name they want. If the name matters, confirm it through the forward lookup; if security matters, use an IP, a key or a certificate.

## How to look up reverse DNS[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#consultar)

On Ubuntu and Debian, dig and host come in the `dnsutils` package (`sudo apt install dnsutils`). nslookup also exists on Windows, and PowerShell has `Resolve-DnsName`.

`# Linux dig -x 203.0.113.10 +short dig -x 2001:db8::10 +short dig PTR 10.113.0.203.in-addr.arpa +short # same lookup, written out in full host 203.0.113.10 # query a specific resolver, to compare caches dig -x 203.0.113.10 @1.1.1.1 +short dig -x 203.0.113.10 @8.8.8.8 +short # Windows (cmd or PowerShell) nslookup 203.0.113.10 Resolve-DnsName 203.0.113.10`

To find out which IP to look up on your own machine, use `ip -brief address`. Reading the result is straightforward:

| Lookup result                              | What it means                   | What to do                                                  |
| ------------------------------------------ | ------------------------------- | ----------------------------------------------------------- |
| Empty or NXDOMAIN                          | The IP has no PTR               | Request the PTR from the provider, if the service needs it  |
| Generic provider name                      | Default PTR created in bulk     | Enough for a website; for email, request a name of your own |
| Your name, and the A points back to the IP | PTR configured and FCrDNS valid | Nothing; keep the result as a reference                     |
| Your name, but the A points to another IP  | Broken FCrDNS                   | Fix the A record in the domain's zone                       |
| Resolvers with different answers           | Cache holding the old answer    | Wait for the TTL to expire and look up again                |

## How to request the PTR for your server[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#configurar)

Since the PTR lives in the provider's zone, the customer's job is to prepare their side and make the right request. The order below avoids the most common round trip, where the provider refuses or FCrDNS fails because the A record did not exist yet.

1. **Pick the name.** One name per IP, inside a domain you own, such as mail.exemplo.com.br. Avoid putting several names on the same PTR: many checks only look at the first one.
2. **Create the A record (and the AAAA, if you use IPv6)**pointing that name to the server's IP. If you have not touched the domain's zone yet, the guide on [domain and DNS for VPS](https://streethosting.com.br/en/guides/vps/point-domain-to-vps) shows the way.
3. **Set the server's hostname.** `sudo hostnamectl set-hostname mail.exemplo.com.br` and, in the mail server, the name announced in HELO equal to the PTR.
4. **Open a ticket with the provider's support** with the IP and the desired name. At StreetHosting the request also goes through a ticket: confirm with support whether the PTR for that IP can be changed and how long it takes, before counting on it in your email plan. Some providers only accept the request after confirming that the A record already points to the IP.
5. **Check after the reply** with dig in both directions and on more than one resolver.

A complete request saves back and forth:

`Subject: Reverse DNS (PTR) configuration IP: 203.0.113.10 Desired PTR name: mail.exemplo.com.br A record already created: mail.exemplo.com.br -> 203.0.113.10 Purpose: transactional email for the domain exemplo.com.br (if there is IPv6) IP: 2001:db8::10 Name: mail.exemplo.com.br`

When you migrate servers, the PTR stays with the old IP, not with you. Request the PTR for the new IP before switching the MX and SPF, and tell the old provider to clear the reverse of the address you returned.

* Name chosen inside a domain you own, one per IP
* A record (and AAAA, if there is IPv6) pointing to the IP
* Server hostname and HELO equal to the PTR name
* Ticket opened with IP, name and purpose
* dig -x and dig A checked, with the same IP in both directions
* Outbound port 25 tested, or relay on 587 configured

## A server with its own IP for email[](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#onde-hospedar)

For email and for any service that depends on IP reputation, what counts is having a fixed, exclusive address with a PTR under your name. The [StreetHosting dedicated servers](https://streethosting.com.br/en/dedicated) sit in São Paulo, with a dedicated 10 Gbps port, 2 TB NVMe, root access and Anti-DDoS included, and delivery within 6 days.

* **AMD Budget SM:** R$ 1,499.00 per month, Ryzen 9 5900XT with 64 GB DDR4 and Anti-DDoS Gamer. Budget LG, with 128 GB, goes for R$ 1,699.00.
* **AMD Extreme SM and LG:** Ryzen 9 9950X with DDR5, from R$ 2,229.00 (128 GB) to R$ 2,599.00 (192 GB).
* **Intel Mid Large:** R$ 3,799.00, two Xeon processors with 384 GB ECC and 5 IPv4 addresses included. With five IPs you can separate the IP that sends email from the website IP, and each one gets its own PTR and its own reputation.

For smaller services, the [StreetHosting VPS plans](https://streethosting.com.br/en/vps) start at R$ 26.00 on the Xeon line (2 vCPU, 2 GB, 20 GB NVMe) and R$ 40.00 on the Ryzen 9 9950X line (1 vCPU, 2 GB DDR5, 20 GB NVMe), with Anti-DDoS included and activation within 60 seconds. If the plan is to run your own email, confirm with support, before ordering, the outbound port 25 policy and the PTR request for the service's IP.

In this guide

* [What reverse DNS is](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#o-que-e)
* [How a reverse lookup works](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#como-funciona)
* [FCrDNS: reverse and forward in agreement](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#fcrdns)
* [Why email depends on the PTR](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#email)
* [PTR in traceroute, logs and bots](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#traceroute-logs)
* [How to look up reverse DNS](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#consultar)
* [How to request the PTR for your server](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#configurar)
* [A server with its own IP for email](https://streethosting.com.br/en/guides/infrastructure/what-is-reverse-dns#onde-hospedar)

## Frequently asked questions

Can I create the PTR record in my domain's DNS panel?

It has no effect. The PTR lives in the reverse zone of the IP block, which belongs to the provider that owns the address, not in your domain's zone. A PTR created at Cloudflare or Registro.br for your domain does not change what the world sees when it looks up the IP. The request goes to the provider's support.

What happens if my mail server has no PTR?

Many destination servers refuse the connection or drop the message into spam. Gmail requires valid forward and reverse DNS from senders, and filters like SpamAssassin and Rspamd add points against IPs without a PTR. If you only host a website, the lack of a PTR makes almost no difference.

Does the PTR have to match my website's domain?

It does not have to be the main domain, but it has to be a name you control that resolves back to the same IP, such as mail.exemplo.com.br. That name should also be the one the mail server announces in HELO. One name per IP is the recommendation.

How long does the PTR take to take effect after it is configured?

On the provider's server, immediately. On resolvers that already had the old answer cached, only after the TTL expires, which usually takes from minutes to a few hours. Query with dig pointed at different resolvers to follow along.

Does having a PTR configured fix email landing in spam?

It fixes only the part that depends on it. Delivery also requires correct SPF, DKIM and DMARC, an IP that is off blocklists, port 25 open or a relay on 587, and a clean recipient list. The PTR is an entry requirement, not a guarantee of the inbox.

Next step

See dedicated servers

Exclusive hardware in São Paulo with NVMe and Anti-DDoS.

[See dedicated servers](https://streethosting.com.br/en/dedicated)

[See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS.](https://streethosting.com.br/en/vps)

## Related guides

[Infrastructure Advanced MailCow email server on a VPS: antispam and why port 25 matters MailCow makes running your own email easier, but the result depends on correct DNS, sending reputation and network security policy. In many hosting environments, outbound port 25 is restricted to reduce abuse, while legitimate sending goes through an authenticated relay. Understanding that difference prevents lost deliveries and needless blocks. 4 min Read guide](https://streethosting.com.br/en/guides/infrastructure/mailcow-email-server-vps) [VPS Beginner How to point a domain to a VPS: A, AAAA and CNAME records Your site is on the VPS, but people can only reach it by IP. DNS fixes that: an A record ties the domain to the server. Learn when to use AAAA and CNAME, how TTL controls propagation, how to test with dig and what the Cloudflare proxy does not do. 9 min Read guide](https://streethosting.com.br/en/guides/vps/point-domain-to-vps) [Infrastructure Intermediate How to use traceroute to find routing problems Traceroute lists every router between you and the server and how long each one takes to answer. Read the right way, it shows whether the delay starts at your home, at your ISP, between networks or at the destination. 8 min Read guide](https://streethosting.com.br/en/guides/infrastructure/how-to-use-traceroute)

[← Back to the Guide Center](https://streethosting.com.br/en/guides)
