Técnica · 7 de novembro de 2026 · 6 min de leitura
Verificar o reverse DNS: consultar e configurar o registo PTR
Como verificar o registo de reverse DNS de um endereço IP com dig, host e nslookup, mandá-lo definir no fornecedor e cumprir as regras dos servidores de correio.
Quem opera um servidor de correio depara-se mais cedo ou mais tarde com a mensagem de erro „no reverse DNS“ ou „PTR missing“. Refere-se à entrada de reverse DNS do endereço do seu servidor. Este artigo mostra como a consultar, o que ela tem de cumprir em servidores de correio e como a mandar configurar. Como deduzir uma empresa a partir de um nome de anfitrião está, em contrapartida, em Registo PTR: como um nome de anfitrião se torna uma empresa.
O que é o reverse DNS
O DNS normal traduz um nome num endereço. O reverse DNS faz o contrário: para um endereço IP devolve um nome. Para isso existe o registo PTR. A consulta decorre através de um domínio especial. No IPv4 é in-addr.arpa, no IPv6 ip6.arpa. O endereço é aí invertido. De 192.0.2.10 resulta 10.2.0.192.in-addr.arpa. No IPv6, os dígitos hexadecimais individuais são invertidos, como descreve a RFC 3596.
Consultar o registo PTR
Todos os comandos consultam no exemplo 193.0.6.139, o endereço do RIPE NCC. Substitua-o pelo seu próprio.
| Ferramenta | Comando | Bom saber |
|---|---|---|
| dig (macOS, Linux) | dig -x 193.0.6.139 +short | Inverte ele próprio o endereço. Sem +short vê também o estado. |
| host (macOS, Linux) | host 193.0.6.139 | Resultado mais curto: „domain name pointer …“ |
| nslookup (todos os sistemas) | nslookup 193.0.6.139 | Existe também no Windows. |
Se não vier resposta, não há entrada (estado NXDOMAIN) ou o servidor de nomes responsável não responde (SERVFAIL, excesso de tempo). Para IPv6 funciona a mesma notação, por exemplo dig -x 2001:db8::25 +short com um endereço da faixa de documentação. Quem não tem consola usa uma consulta online de sites de ferramentas DNS. Entradas alteradas há pouco chegam muitas vezes a todo o lado só passado algum tempo, devido à memória intermédia (TTL).
Porque os servidores de correio precisam dele
Os servidores de correio recetores gostam de verificar se o remetente está bem configurado. Uma parte desta verificação é o reverse DNS. A ideia básica chama-se, na linguagem técnica, forward-confirmed reverse DNS:
- Para o endereço do remetente é consultado o registo PTR. Resultado: um nome de anfitrião.
- Para esse nome de anfitrião é consultado o registo A (no IPv6 AAAA).
- Se o endereço coincidir com o original, a cadeia fecha-se.
A Google exige expressamente dos remetentes entradas diretas e inversas válidas. Nas diretrizes para remetentes consta que o endereço do remetente tem de coincidir com o endereço do nome de anfitrião indicado no registo PTR. Também a RFC 1912 recomenda, na secção 2.1, que os registos PTR e A combinem e que o registo PTR não aponte para um CNAME. Se outro destinatário verifica com rigor, consta da sua própria documentação. Conte com o facto de que uma entrada em falta ou inadequada leva a e-mails rejeitados ou parados na pasta de spam.
Mandar configurar
O registo PTR não o define na sua própria administração de domínios. Está na zona que pertence ao bloco de endereços. Esta é administrada por quem tem o bloco atribuído. Em regra, é o seu fornecedor ou alojador.
- Escolha o nome de anfitrião com que o seu servidor de correio deve apresentar-se, por exemplo
mail.beispiel-firma.example. - Crie na sua própria zona DNS o registo A:
mail.beispiel-firma.exampleaponta para192.0.2.10. - Introduza no portal de clientes do fornecedor a entrada de reverse DNS para
192.0.2.10. Em muitos alojadores é um campo no endereço IP. Caso contrário, basta um pedido ao suporte com o endereço e o nome pretendido. - Verifique com
dig -xe depois comdig mail.beispiel-firma.example +shortse as duas direções combinam. - Certifique-se de que o nome também combina com a saudação (HELO/EHLO) do seu servidor de correio.
Se tiver um bloco de endereços próprio, o registo reencaminha a zona para os seus servidores de nomes. Para blocos menores do que um /24, a RFC 2317 descreve o procedimento. Nesse caso, pergunte primeiro ao seu fornecedor.
Dois obstáculos são frequentes. Se o servidor tiver vários endereços, cada um precisa da sua própria entrada. E com endereços dinâmicos, como têm as ligações particulares, em regra não obtém um nome escolhido livremente. Quem envia correio a partir daí usa melhor um serviço de relay.
Se a verificação falhar
| Observação | Causa possível |
|---|---|
| Nenhuma entrada | O fornecedor não definiu nada, falta a entrada para este endereço |
| A entrada aponta para o nome genérico do fornecedor | O nome próprio nunca foi pedido |
| O nome não resolve para o mesmo endereço | Falta o registo A ou aponta para um endereço antigo |
| Só o IPv4 funciona | Falta a entrada para IPv6, a Google chama a atenção para isso na sua documentação |
| Alteração não visível | Memória intermédia, aguardar ou consultar diretamente o servidor de nomes do fornecedor |
O reverse DNS não substitui a autenticação de correio. SPF, DKIM e DMARC são temas à parte. Mas sem um registo PTR adequado, um servidor de correio fica depressa debaixo do radar dos destinatários.
O que o reverse DNS não prova
A entrada é voluntária e mantida pelo operador de rede. Não diz quem utiliza um endereço. Por isso serve como indício, não como prova, se quiser saber a quem pertence um endereço IP. Para isso, o registo de redes é a fonte mais fiável. A interação dos dois caminhos explica-a Reverse IP lookup explicado de forma simples.
Perguntas frequentes
Todo o endereço IP tem de ter um registo PTR? Não, é voluntário. Para servidores que enviam e-mails, é na prática obrigatório, porque os destinatários o verificam.
Posso alterar eu próprio o registo PTR? Só se administrar a zona inversa do endereço. No caso de endereços do seu fornecedor ou alojador, é este que define a entrada, na maioria das vezes através do portal de clientes ou a pedido.
Qual é a diferença entre reverse DNS e Whois? O reverse DNS devolve um nome de anfitrião e é definido pelo operador de rede. O Whois ou RDAP indica o titular do intervalo de endereços. São bases de dados diferentes com finalidades diferentes.
