Ferramentas populares

Tema

DNS Reverso — Consulta de Registro PTR

Encontre o nome de host por trás de qualquer endereço IPv4 ou IPv6 com uma consulta de DNS reverso: cada registro PTR direto dos próprios servidores de nomes da zona reversa, se cada nome aponta de volta para o endereço (FCrDNS), quem opera a zona e se ele passa nas regras do Gmail, do Yahoo e da Microsoft para servidores de e-mail.

Fontes: os servidores de nomes da zona reversa, alcançados a partir de um servidor raiz · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

IPv4 ou IPv6 em qualquer notação, um nome de host (resolvido primeiro) ou um nome in-addr.arpa.

Experimente

O que é DNS reverso (rDNS)?

O DNS reverso transforma um endereço IP de volta num nome de host: o contrário da consulta comum (direta), que transforma um nome num endereço. A resposta é um registro PTR que o detentor do endereço publica numa parte do DNS reservada para endereços.

Os nomes DNS são lidos da direita para a esquerda, então um endereço é escrito de trás para frente para ser consultado: 8.8.8.8 vira 8.8.8.8.in-addr.arpa e 203.0.113.7 vira 7.113.0.203.in-addr.arpa. Com a parte da rede à direita, cada bloco de endereços pode ser entregue a quem o detém (RFC 1035 §3.5).

O IPv6 usa ip6.arpa e todos os 32 dígitos hexadecimais (nibbles) do endereço, começando pelo último dígito: o :: é expandido antes de os dígitos serem invertidos, então 2001:4860:4860::8888 tem um nome de 32 rótulos (RFC 3596 §2.5). Enquanto você digita, a ferramenta mostra embaixo do campo o nome que vai consultar, e escreve os 32 nibbles no caminho reverso ao lado do resultado.

Anatomia de um nome reversoao vivo em 2026-10-23

Endereço IPv4OpenDNS

208.67.222.222222.222.67.208.in-addr.arpa

O nome reverso dele, consultado por PTRresolver1.opendns.com +3

Octetos invertidosO /8 fica por último: 208.in-addr.arpa é a zona do ARIN, 222.67.208.in-addr.arpa a da própria OpenDNS.
in-addr.arpaA árvore reversa do IPv4, administrada pela IANA e servida pelos servidores a até f.in-addr-servers.arpa.
PTRO que o nome contém: resolver1.opendns.com e mais três nomes de host.

Endereço IPv6, escrito por extensoGoogle

2001:4860:4860:0000:0000:0000:0000:8888

32 nibbles, começando pelo último dígito

O 8888 do final vem primeiro, o /32 2001:4860 do Google vem por último, e os 16 zeros que o :: escondia são escritos por extenso.

8.8.8.8.in-addr.arpaIPv4: quatro rótulos, invertidos
8.8.8.8.0.0.0.0…ip6.arpaIPv6: todos os 32 dígitos, invertidos
8.8.8.8.0.6.8.4…ip6.arpa:: deixado comprimido: outro nome, e NXDOMAIN
8.8.8.8 se lê igual nos dois sentidos, então a figura usa 208.67.222.222, cujos octetos trocam de lugar visivelmente. O caminho reverso da ferramenta desenha a mesma troca para cada endereço IPv4 que ela consulta.

Como fazer uma consulta de DNS reverso

Digite um endereço acima e clique em Consultar PTR. A ferramenta desce de um servidor raiz até o próprio servidor de nomes da zona reversa e pergunta diretamente a ele, depois compara as cópias em cache do Google e da Cloudflare. Pelo terminal, dig -x 8.8.8.8 no macOS e no Linux, nslookup 8.8.8.8 no Windows ou host 8.8.8.8 fazem o mesmo.

O dig -x monta o nome in-addr.arpa ou ip6.arpa para você; acrescente @ e o servidor de nomes da zona com +norecurse (dig -x 8.8.8.8 @ns1.google.com +norecurse) para ler a resposta da própria zona e o TTL completo em vez de um cache. No PowerShell, a forma documentada pela Microsoft passa o nome invertido: Resolve-DnsName -Name 8.8.8.8.in-addr.arpa -Type PTR.

dig -x 8.8.8.8 +noall +answer

O dig monta 8.8.8.8.in-addr.arpa sozinho. O número antes de IN é o TTL que ainda resta no seu resolvedor.

Como ler a resposta do digGoogle Public DNS, depois o próprio servidor do Google · obtida em 2026-10-23
bash · zsh
$ dig -x 8.8.8.8 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.        IN   PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  14003  IN   PTR   dns.google.

;; SERVER: 8.8.8.8#53(8.8.8.8)

$ dig -x 8.8.8.8 @ns1.google.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
8.8.8.8.in-addr.arpa.  86400  IN   PTR   dns.google.
;; SERVER: 216.239.32.10#53(216.239.32.10)
  1. Status. NOERROR com uma resposta. NXDOMAIN significaria que nenhum PTR está definido; SERVFAIL, uma zona reversa quebrada.
  2. A pergunta. O dig montou 8.8.8.8.in-addr.arpa a partir do endereço e pediu o PTR dele.
  3. TTL. 14.003 segundos restantes no cache do Google. O próprio servidor da zona dá o valor completo, 86.400, um dia.
  4. O nome de host. O valor do PTR. O ponto final encerra o nome.
  5. Quem respondeu. 8.8.8.8, um cache. Na segunda resposta, a flag aa marca o próprio servidor da zona.
Um PTR, consultado duas vezes: o Google Public DNS responde do cache, em contagem regressiva; ns1.google.com, consultado com +norecurse, responde pela zona com o TTL completo.

Como ler o resultado

O topo diz numa frase qual nome o DNS reverso do endereço retorna e se esse nome aponta de volta, com o TTL da zona e o servidor que respondeu. As notas coloridas abaixo dizem quem pode mudar o nome e o que há de incomum nele.

A visualização PTR lista cada nome com o TTL e a verificação direta; E-mail o avalia segundo as regras dos provedores de e-mail; Delegação mostra cada servidor consultado; Cópias compara as respostas em cache do Google e da Cloudflare; Comandos dá a mesma consulta para um terminal. À direita, o caminho reverso desenha todo o percurso.

DNS reverso de 8.8.8.8: o registro PTR dns.google do servidor de nomes do Google, a consulta direta e o caminho da delegaçãoDNS reverso de 8.8.8.8: o registro PTR dns.google do servidor de nomes do Google, a consulta direta e o caminho da delegaçãoO vereditoQual nome o DNS reverso do endereço retorna, se esse nome aponta de volta e quem o definiu, com o TTL e o servidor que respondeu.Os registros PTRCada nome que a zona tem para o endereço, com o TTL e os endereços que a consulta direta dele retorna.As visualizaçõesRegras de e-mail, a delegação salto a salto, as cópias em cache com as contagens regressivas e os comandos.O caminho reversoO endereço invertido no nome DNS dele, depois a raiz, a IANA, o registro regional e a zona que respondeu.
Uma consulta de DNS reverso de 8.8.8.8: o veredito, o registro PTR com o TTL e a verificação direta, e o caminho reverso da raiz até a zona do Google. Selecione um número para ver o que cada parte mostra.

O que é um registro PTR?

Um registro PTR (pointer, ou ponteiro), tipo 12 do DNS, contém um nome de host para o endereço sob o qual está: 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google. São só dados: ao contrário de um CNAME, ele não manda nada para outro lugar (RFC 1035 §3.3.12).

Quem o escreve é o detentor do endereço, não o dono do nome dentro dele: a zona reversa do Google diz que 8.8.8.8 é dns.google, e só o registro A na zona dns.google diz o inverso. Um endereço pode ter vários registros PTR (RFC 2181 §10.2): 208.67.222.222 tem quatro. O nome precisa ser um nome de host real, nunca um apelido.

Um PTR contém um nome e nada mais: nem dono, nem país, nem cidade. Um local exibido ao lado de uma consulta vem de palavras que o operador colocou no nome, ou de um banco de dados separado.

Um nome, duas zonas8.8.8.8 e dns.google, ao vivo em 2026-10-23
Zona diretaa do domínio: dns.google
dns.google. A 8.8.8.8dns.google. A 8.8.4.4dns.google. AAAA 2001:4860:4860::8888dns.google. AAAA 2001:4860:4860::8844

Servida por ns1.zdns.google para o detentor de dns.google

duas zonas, dois conjuntos de servidores
Zona reversaa do bloco de endereços: 8.8.8.0/24
8.8.8.8.in-addr.arpa. PTR dns.google.

Delegada pelo ARIN ao Google, servida por ns1.google.com

8.8.8.8.in-addr.arpa.Nome reverso86400TTL · 1 diaINClassePTRTipodns.google.Nome de host
1 endereço, 4 nomes208.67.222.222: resolver1.opendns.com e mais três
1 endereço, 48 nomes17.253.144.10, o endereço de apple.com, cada um com TTL de 5 minutos
1 nome, 4 endereçosdns.google: 8.8.8.8, 8.8.4.4 e dois IPv6
O PTR diz como 8.8.8.8 se chama; os registros A dizem para onde dns.google aponta. Por acaso, o Google opera as duas zonas, em servidores diferentes.

O que é DNS reverso com confirmação direta (FCrDNS)?

DNS reverso com confirmação direta significa que o nome do PTR resolve de volta para o mesmo endereço: 8.8.8.8 → dns.google → 8.8.8.8. Os servidores de e-mail chamam essa verificação de iprev (RFC 8601 §3): consultar os nomes PTR do endereço, consultar os registros A ou AAAA de cada nome e aprovar quando o endereço está entre eles.

O segundo passo importa porque quem detém um endereço pode escrever qualquer nome no PTR dele, até google.com. O nome só prova algo quando o dono do domínio aponta de volta. A ferramenta verifica cada nome PTR, até dez, e desenha o ciclo à direita: verde quando ele se fecha, âmbar quando o nome aponta para outro lugar.

Com vários registros PTR, basta um que aponte de volta. Um nome cujo registro A também lista outros endereços ainda passa, desde que este endereço seja um deles.

Três endereços, três ciclosao vivo em 2026-10-23
Com confirmação diretaGoogle
8.8.8.8dns.google8.8.8.8: mesmo endereço
Aponta de voltadns.google também retorna 8.8.4.4
Aponta para outro lugarAdGuard
94.140.14.14dns.adguard-dns.com185.113.30.30: outro endereço
Não confirmadoo registro A dele é 185.113.30.30
Sem PTRCloudflare
104.18.0.1NXDOMAIN: sem nome
Nada a confirmarNXDOMAIN da zona da Cloudflare
O mesmo ciclo sobe pela borda direita de cada resultado: verde quando o nome leva de volta, âmbar quando leva a outro lugar.

Verificação de DNS reverso para servidores de e-mail: o que Gmail, Yahoo e Outlook.com exigem

Os três querem um registro PTR em cada IP de envio. O Gmail também exige que o nome resolva de volta para o mesmo IP, e o Yahoo exige "um registro DNS direto e reverso válido", ambos para todos os remetentes desde fevereiro de 2024. A política do Outlook.com pede DNS reverso válido e não diz nada sobre o passo direto.

Um nome genérico como ec2-3-80-0-1.compute-1.amazonaws.com não reprova em nenhuma regra: o Yahoo só recomenda um nome significativo, não genérico, que reflita o seu domínio. O Outlook.com avisa que conexões vindas de espaço de IP dinâmico podem não ser aceitas, o que atinge os nomes de pool de um provedor de internet, não o nome padrão estático de um servidor em nuvem. A visualização E-mail mostra esses casos como alertas e os requisitos como aprovado ou reprovado; uma verificação que não terminou não é nenhum dos dois.

Duas coisas nunca são reprovações: vários registros PTR, que a RFC 2181 permite, e um PTR diferente do nome HELO do servidor: a RFC 5321 §4.1.4 diz que um servidor não pode recusar e-mails por isso. O Gmail limita a taxa com 421 4.7.0 ou 451 4.7.23 e bloqueia com 550 5.7.25 quando o PTR falta ou não aponta de volta.

Exigido, recomendado, não mencionadoa própria página de cada provedor, verificada em 2026-10-23
VerificaçãoGmaildiretrizes para remetentesYahoo Mailboas práticas para remetentesOutlook.compolítica de postmaster
Tem registro PTRexigidoexigidoexigido
O nome aponta de voltaexigidoexigidonão mencionado
Nem genérico nem dinâmiconão mencionadorecomendapode recusar IPs dinâmicos
Quatro remetentes reais, verificados ao vivo
mail-sor-f41.google.com209.85.220.41 · o próprio servidor de saída do Gmailaprovadoaprovadoaprovado
ec2-3-80-0-1.compute-1.amazonaws.com3.80.0.1 · o nome padrão da AWSaprovadoaprovadoalertaaprovadoalerta
dns.adguard-dns.com94.140.14.14 · aponta para 185.113.30.30reprovadoreprovadoaprovado
Sem PTR104.18.0.1 · NXDOMAINreprovadoreprovadoreprovado

As respostas do Gmail

421 4.7.0 · 451 4.7.23Taxa limitada: sem PTR, ou a entrada direta dele não corresponde ao IP de envio
550 5.7.25Bloqueado: sem PTR, ou a entrada direta não faz referência ao IP de envio
550-5.7.1Por IPv6: a mensagem não atende às diretrizes de envio por IPv6 para registros PTR e autenticação
Só os requisitos reprovam. A recomendação do Yahoo e o aviso do Outlook.com sobre IPs dinâmicos aparecem como alertas. Os códigos do Gmail vêm da referência de erros SMTP dele.

Quem controla o DNS reverso e como definir um registro PTR

O detentor do bloco de endereços, nunca o dono de um domínio. A IANA delega a zona reversa de cada bloco ao Registro Regional da Internet dele, e o registro regional à rede que detém os endereços, que opera a zona ou a repassa (RFC 3172). Ser dono de example.com não permite que você dê nome a um endereço: quem faz isso é a sua hospedagem ou o seu provedor de internet.

As nuvens deixam os clientes definir o PTR, cada uma com a sua regra: a AWS quer o registro A direto primeiro, o Azure define só IPv4 e não pelo portal, a DigitalOcean monta o PTR a partir do nome do Droplet, o Google Cloud pede que você prove o domínio. Numa linha residencial, normalmente só um plano empresarial com IP fixo consegue um PTR personalizado: peça ao provedor. Blocos menores que um /24 muitas vezes são repassados com CNAMEs (RFC 2317), que a ferramenta segue aonde quer que apontem.

Uma mudança chega a todos quando os caches descartam a resposta antiga: quem decide é o TTL do registro antigo, ou o tempo do "sem PTR" em cache quando não havia nenhum (RFC 2308), não um prazo fixo de 24 a 48 horas. A Vultr diz que as mudanças dela levam de 6 a 12 horas.

Quem repassa a zonapercursos registrados em 2026-10-23
  1. in-addr.arpaAdministrada pela IANA, servida pelos servidores a até f.in-addr-servers.arpa
  2. 8.in-addr.arpa · 208.in-addr.arpaO registro regional do bloco: o ARIN para 8.0.0.0/8 e 208.0.0.0/8ARINRIPE NCCAPNICLACNICAFRINIC
  3. 8.8.8.in-addr.arpaO detentor de 8.8.8.0/24: o Google escreve o PTR, em ns1 a ns4.google.com
17.in-addr.arpaUm /8 legado, delegado pela in-addr.arpa diretamente aos servidores da própria Apple
129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpaO próprio exemplo da RFC 2317: para um bloco com menos de 256 endereços, a zona pai contém um CNAME para uma zona que o detentor do bloco opera. O nome da zona filha é só uma convenção.
Cada salto é uma referência registrada em 2026-10-23, exceto o da RFC 2317, que é o próprio exemplo da RFC num bloco de documentação.
Onde cada provedor define o PTRa própria documentação de cada provedor, verificada em 2026-10-23
ProvedorComo definirLimites
AWSDocumentaçãoSó Elastic IPs. Publique um registro A para o seu nome apontando para o Elastic IP e depois vá em EC2 console › Elastic IPs › o endereço › Actions › Update reverse DNS, ou use aws ec2 modify-address-attribute --allocation-id … --domain-name mail.example.com.O registro A direto precisa existir antes. Enquanto tiver um registro reverso, o Elastic IP fica preso à sua conta. No GovCloud (US), só o AWS Support pode definir um. Os limites da porta 25 são liberados com uma solicitação separada.
Microsoft AzureDocumentaçãoDefina o ReverseFqdn do IP público: az network public-ip update --resource-group RG --name PublicIp --reverse-fqdn mail.example.com. (o nome termina com ponto), ou Set-AzPublicIpAddress no PowerShell.Só IPv4: endereços IPv6 do próprio Azure não recebem PTR. Não pelo portal do Azure. O nome precisa resolver para esse IP ou pertencer à sua assinatura. Um PTR por endereço, nenhum por padrão, e nenhum para App Service ou Application Gateway.
Google CloudDocumentaçãoVerifique o domínio primeiro (Search Console, ou um registro A para o IP externo da VM). Depois VM instances › a instância › Edit › a interface de rede principal › Public DNS PTR record, ou gcloud compute instances update-access-config INSTANCE --public-ptr --public-ptr-domain mail.example.com.Só a interface de rede principal; sem PTR para balanceadores de carga nem para o Cloud NAT. PTRs em IPv6 exigem uma sub-rede dual-stack ou só IPv6 com IPv6 externo. O nome padrão é <reversed-ip>.bc.googleusercontent.com.
HetznerDocumentaçãoCloud: Hetzner Console › o servidor (ou Primary IP, Floating IP) › Networking › edite o rDNS ao lado do IP; para IPv6, digite só a parte da interface, como ::1. Dedicated: Robot › o servidor › IPs, o campo ao lado de cada IP.A Hetzner opera a zona reversa. Ela só considera válida uma entrada de rDNS que resolve nos dois sentidos (FCrDNS). O padrão é static.<reversed-ip>.clients.your-server.de.
DigitalOceanDocumentaçãoNão há editor de PTR: dê ao Droplet o nome completo que você quer, como mail.example.com, ou renomeie-o com ele, e a DigitalOcean cria o PTR a partir desse nome.O nome precisa ser um FQDN válido (my-droplet não gera PTR). Só o primeiro endereço IPv6 do Droplet recebe PTR. PTRs não podem ser criados manualmente.
OVHcloudDocumentaçãoAponte um registro A ou AAAA para o IP primeiro. Depois Control Panel › Network › Public IP Addresses › o botão de ações na linha do IP › Configure the reverse DNS (Public Cloud: seu projeto › Public IPs).A OVHcloud verifica na hora que o nome aponta de volta para o mesmo IP, então o registro já precisa estar ativo. O nome precisa estar em minúsculas e terminar com ponto.
VultrDocumentaçãoProducts › Compute › a instância › Settings › IPv4 ou IPv6 › Public Network: clique no nome na coluna Reverse DNS, digite o nome completo e salve.A Vultr pede que o nome resolva de volta para o mesmo IP e diz que as mudanças levam de 6 a 12 horas para aparecer. O padrão é <ip>.vultrusercontent.com.
Akamai Cloud (Linode)DocumentaçãoAdicione o registro A (e o AAAA) primeiro. Depois Cloud Manager › Linodes › o Linode › Network › o menu de reticências do IP › Edit RDNS, e digite o nome completo; deixar o campo vazio restaura o padrão.Dá erro até o registro A corresponder ao IP. Faixas IPv6: Edit rDNS na faixa, depois em cada endereço. Padrões: <ip-with-dashes>.ip.linodeusercontent.com, ou o mais antigo li<n>-<n>.members.linode.com.
Oracle CloudDocumentaçãoCrie o registro A ou AAAA primeiro e depois abra uma solicitação de serviço com o IP, o nome que você quer no PTR e o nome do registro direto; a Oracle confere e cria o PTR.Um PTR por IP, só por solicitação ao suporte; o registro direto precisa resolver para esse IP.
Seu provedor de internetRFC 8501Peça ao seu provedor de internet: só o provedor, que detém o endereço, pode definir o PTR dele. Na prática, isso exige um IP fixo num plano empresarial.Linhas residenciais ficam com o nome de pool do provedor, e servidores de destino como os da Comcast tratam esses nomes como dinâmicos e recusam e-mails enviados diretamente deles.
Quanto tempo uma mudança leva: até os caches descartarem o PTR antigo (o TTL dele) ou a resposta “sem PTR” em cache (RFC 2308). TTLs ao vivo: 1 dia para 8.8.8.8, 7 dias para resolver1.opendns.com, 5 minutos para um nome padrão do EC2.

Por que a maioria dos endereços IPv6 não tem registro PTR

Porque são endereços demais para nomear um por um. Um provedor de internet pode preencher antecipadamente um PTR para cada endereço IPv4 que distribui, mas um único /48 contém 2⁸⁰ endereços, e os dispositivos escolhem os próprios, muitas vezes de curta duração (RFC 8501).

A RFC 8501 lista as opções do provedor: responder NXDOMAIN (sem PTR, a mais precisa), um PTR curinga para o prefixo de cada cliente, DNS dinâmico, delegar a zona ao cliente ou gerar na hora registros PTR e AAAA correspondentes. Só o curinga quebra a verificação direta; para usuários domésticos, um NXDOMAIN limpo está ótimo, um timeout não.

Servidores que enviam e-mail por IPv6 ainda precisam de um PTR com confirmação direta: o Gmail rejeita e-mails por IPv6 sem ele com 550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication. O Azure não dá PTR nenhum aos próprios endereços IPv6.

Um PTR por endereço, na escala do IPv4 e do IPv6RFC 8501
/24um bloco IPv428 = 256
/64uma sub-rede IPv6264 = 18.446.744.073.709.551.616
/48um site IPv6280 = 1.208.925.819.614.629.174.706.176

Comprimento da barra: bits de espaço de endereçamento. Cada bit dobra a quantidade.

A 1.000 registros PTR por segundo, um /48 ainda não estaria completo depois de 38 trilhões de anos (RFC 8501).

As opções da RFC 8501 para um provedor

NXDOMAINsem nomeNenhum PTR: a resposta mais precisa, mas é provável que servidores de e-mail recusem esses remetentes.
Um curinganão correspondeUm nome para um prefixo inteiro: a consulta direta dele não consegue levar de volta a cada endereço.
DNS dinâmicocorrespondeCada host envia as próprias atualizações de AAAA e PTR quando o endereço dele é definido.
Delegar a zonafica a cargo do clienteClientes que operam servidores DNS recebem a zona reversa do seu prefixo; a maioria das casas não consegue.
Na horacorrespondeO servidor cria um PTR quando consultado, com o AAAA correspondente.

Um servidor de e-mail ainda precisa do seu próprio, com confirmação direta:2001:4860:4860::8888 → dns.google → 2001:4860:4860::8888

Como verificar o Googlebot e outros rastreadores

Consulte o endereço do visitante, confira se o nome PTR termina no domínio documentado do rastreador e depois faça a consulta direta desse nome e confirme que ela retorna o mesmo endereço: 66.249.66.1 → crawl-66-249-66-1.googlebot.com → 66.249.66.1. Ou compare o endereço com a lista publicada pelo operador (o método do Google).

Os domínios documentados: googlebot.com e google.com para o Google, search.msn.com para o Bingbot, applebot.apple.com para o Applebot, yandex.ru, yandex.net e yandex.com para o Yandex. O DuckDuckBot publica só uma lista de endereços.

googleusercontent.com sozinho não prova nada: toda VM do Google Compute Engine recebe um nome sob ele por padrão, então a ferramenta só o conta como Google quando o endereço está nas listas publicadas do Google. Um nome com a terminação certa que não aponta de volta é falso, e a ferramenta diz isso.

Duas consultas decidem66.249.66.1, ao vivo em 2026-10-23
  1. Consulta reversaO PTR do endereço visitante.66.249.66.1 → crawl-66-249-66-1.googlebot.com
  2. Domínio do Google?Termina em googlebot.com. Um nome googleusercontent.com também precisaria do endereço nas listas do Google.
  3. Consulta diretacrawl-66-249-66-1.googlebot.com → 66.249.66.1Mesmo endereço: um Googlebot de verdade.
Um falso: “Googlebot” no user agent, vindo de 203.0.113.9A consulta reversa dele responde NXDOMAIN, então a verificação para no passo 1. (Um endereço de documentação, RFC 5737.)
RastreadorO nome PTR termina emLista de IPs publicada
GooglebotPTR e consulta direta, ou a listagooglebot.comcommon-crawlers.json
Rastreadores especiais do GooglePTR e consulta direta, ou a listarate-limited-proxy-….google.comspecial-crawlers.json
Buscadores acionados por usuários do GooglePTR e consulta direta, ou a listagoogle-proxy-….google.com….gae.googleusercontent.comsó com a listauser-triggered-fetchers-google.jsonuser-triggered-fetchers.jsonuser-triggered-agents.json
BingbotPTR e consulta direta, ou a listasearch.msn.combingbot.json
ApplebotPTR e consulta direta, ou a listaapplebot.apple.comapplebot.json
YandexBotPTR e consulta diretayandex.ruyandex.netyandex.comnenhuma
DuckDuckBotSó a lista de IPsnenhumaduckduckbot.json

Ao vivo hoje, cada um apontando de volta:crawl-66-249-66-1.googlebot.commsnbot-157-55-39-1.search.msn.com17-58-101-179.applebot.apple.com

Domínios e listas da própria página de cada operador, verificados em 2026-10-23. O Bing pede que a lista dele seja atualizada diariamente.

Erros de DNS reverso explicados

NXDOMAIN significa que o nome reverso não existe: ninguém definiu um PTR para o endereço. NOERROR sem resposta (NODATA) significa que o nome existe, mas não contém PTR. Os resolvedores guardam qualquer uma das respostas pelo tempo de cache negativo do SOA da zona (RFC 2308), então um PTR novo pode levar esse tempo para aparecer.

SERVFAIL significa que a zona está quebrada, na maioria das vezes por uma delegação lame: os servidores indicados para a zona não a servem, e todo resolvedor desiste. REFUSED vem de um servidor que se recusa a responder pela zona. Endereços privados e de documentação nunca recebem um PTR público: a ferramenta responde a eles pelo registro da IANA, sem perguntar a ninguém.

Cada resposta, um exemplo realao vivo em 2026-10-23
NOERROR8.8.8.8Há um nome definido: o PTR volta com o TTL dele.PTR dns.google. · TTL 86400ns1.google.com · aa
NXDOMAIN104.18.0.1Esse nome não existe: a zona da Cloudflare não tem PTR para ele, e diz isso.SOA 18.104.in-addr.arpacruz.ns.cloudflare.com … 3600
NODATANOERROR, 0 answers2001:4860:4860::/48O nome existe, sem PTR: o nome do /48 do Google, que tem nomes abaixo dele.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpaSOA ns1.google.com … 60
SERVFAIL203.0.113.50inventado, endereço de documentaçãoDelegação lame: o registro regional indica dois servidores que não servem a zona, então os resolvedores desistem.APNIC → ns1, ns2.example.net: lameEDE 22: No Reachable Authority
NXDOMAINAS112192.168.1.1Um endereço privado: a árvore pública entrega 168.192.in-addr.arpa aos servidores AS112 da IANA, que respondem NXDOMAIN.blackhole-1.iana.orgSOA prisoner.iana.org … 604800
Um “não” fica em cache pelo tempo negativo do SOA (RFC 2308): 1 hora na Cloudflare, 60 segundos no Google, 7 dias a partir do AS112.

DNS reverso: perguntas frequentes

O que é uma consulta de DNS reverso?

Uma consulta de DNS reverso encontra o nome de host por trás de um endereço IP lendo o registro PTR dele, o contrário de uma consulta comum, que transforma um nome num endereço. O endereço é invertido num nome especial, como 8.8.8.8.in-addr.arpa, e consultado nos servidores de nomes que o contêm. Para 8.8.8.8, a resposta é dns.google. Esta ferramenta também verifica se o nome aponta de volta.

Como verificar um registro PTR com dig ou nslookup?

Rode dig -x 8.8.8.8 no macOS ou no Linux: o dig inverte o endereço sozinho e o PTR aparece na seção de resposta. No Windows, nslookup 8.8.8.8 o mostra na linha Name:. Para pular qualquer cache, pergunte ao próprio servidor de nomes da zona: dig -x 8.8.8.8 @ns1.google.com +norecurse. A visualização Comandos preenche cada comando com o seu endereço e o servidor da zona dele.

Por que meu IP não tem DNS reverso?

Porque ninguém definiu um registro PTR para ele. Só o detentor do bloco de endereços pode fazer isso, então a resposta é NXDOMAIN até a sua hospedagem ou o seu provedor acrescentar um. A maioria das conexões residenciais e dos endereços IPv6 não tem nenhum. Se a consulta mostrar SERVFAIL, a própria zona reversa está quebrada, geralmente por uma delegação lame que o provedor precisa corrigir.

Como configurar ou alterar um registro PTR?

Com quem forneceu o endereço. Na AWS, publique primeiro o registro A direto e depois atualize o DNS reverso do Elastic IP. O Azure define o ReverseFqdn no IP público, a DigitalOcean usa o nome do Droplet, e Hetzner, OVHcloud, Vultr e Linode têm um campo de rDNS ao lado de cada endereço. Numa linha residencial ou de escritório, peça ao seu provedor: normalmente só planos empresariais com IP fixo se qualificam.

Quanto tempo leva uma alteração de registro PTR?

O tempo que os caches guardam a resposta antiga. Cada resolvedor pode entregar o PTR antigo até o TTL dele acabar, muitas vezes de uma hora a um dia, ou a resposta "sem PTR" em cache pelo tempo de cache negativo da zona. Não existe um prazo fixo de 24 a 48 horas. A visualização Cópias mostra quanto tempo resta às cópias do Google e da Cloudflare.

Um endereço IP pode ter mais de um registro PTR?

Sim. O DNS permite vários registros PTR para um endereço, e a RFC 2181 diz que nenhum limite deve ser presumido: 208.67.222.222 tem quatro. As verificações de e-mail passam quando qualquer um deles aponta de volta para o endereço. Algumas ferramentas leem só o primeiro nome, então o que você usa para e-mail deve ter confirmação direta. Um único PTR é a configuração mais simples, não um requisito.

O que é FCrDNS?

DNS reverso com confirmação direta: o nome do PTR, consultado de forma direta, retorna o mesmo endereço. O DNS reverso de 8.8.8.8 retorna dns.google, e dns.google resolve para 8.8.8.8, então passa. Os servidores de e-mail chamam essa verificação de iprev. Ela importa porque quem detém um endereço pode escrever qualquer nome no PTR dele; só a consulta direta mostra que o dono do domínio concorda.

Preciso de DNS reverso para enviar e-mail?

Sim, para qualquer servidor que envie e-mails diretamente. O Gmail exige que cada IP de envio tenha um PTR que resolva de volta para ele, o Yahoo exige DNS direto e reverso válido, e o Outlook.com exige DNS reverso válido. Sem isso, os e-mails têm a taxa limitada ou são rejeitados, por exemplo com o 550 5.7.25 do Gmail. Um nome genérico de provedor passa nas regras, mas gera alertas.

O que significa “reverse DNS is not a valid hostname”?

Testes de servidores de e-mail mostram essa mensagem quando o nome PTR do IP de envio não funciona como nome de host para aquele IP: quase sempre não há PTR nenhum, ou o nome não tem registro A apontando de volta para o mesmo endereço. Consulte o IP de envio aqui: a visualização PTR mostra o nome e a verificação direta, e a visualização E-mail indica a regra que ele infringe.

DNS reverso é o mesmo que consulta de IP reverso?

Não. O DNS reverso lê o nome, ou os nomes, que o detentor do endereço publicou nos registros PTR dele. Uma consulta de IP reverso tenta listar todos os sites hospedados num endereço, o que exige dados de DNS passivo coletados de muitos resolvedores ao longo do tempo. Muitos sites usam os dois termos sem rigor. Nossa página IP para Hostname explica o que cada método consegue encontrar.

O DNS reverso funciona com IPv6?

Sim. Endereços IPv6 são consultados sob ip6.arpa com os 32 dígitos hexadecimais invertidos, então 2001:4860:4860::8888 gera um nome de 32 rótulos que esta ferramenta monta e consulta por você. A maioria dos endereços IPv6 não tem PTR, porque os provedores não conseguem preencher nomes antecipadamente para tantos endereços, mas servidores que enviam e-mail por IPv6 precisam de um.

Por que um IP privado não tem PTR?

Endereços privados como 192.168.1.1 ou 10.0.0.1 são usados dentro de muitas redes ao mesmo tempo, então o DNS público não consegue nomeá-los. As consultas reversas deles cabem ao resolvedor da sua própria rede; as que vazam terminam nos servidores AS112, que respondem que esse nome não existe. A ferramenta explica cada faixa de uso especial com a RFC dela, sem perguntar a ninguém.

Mais ferramentas de DNS, IP e e-mail