DNS reverso (PTR) para e-mail: o que é e como verificar

Um registro PTR (ponteiro) é o inverso de um registro A: ele associa um endereço IP a um nome de host. No e-mail, o IP que envia suas mensagens precisa de um registro PTR, e o nome de host indicado deve resolver de volta para esse mesmo IP. Essa ida e volta se chama DNS reverso confirmado (forward-confirmed reverse DNS), e Gmail e Yahoo exigem isso. Sem ele, o e-mail é adiado, recusado ou filtrado.

Registros PTR não são configurados no DNS do seu próprio domínio, e a maioria dos remetentes nunca precisa mexer em um. Este guia mostra como verificar, o que os grandes provedores de e-mail exigem e quem pode mudar o registro quando ele está errado.

Como o DNS reverso funciona

Um registro PTR fica numa zona reversa especial, cujo nome é o endereço IP escrito de trás para frente. No IPv4, os quatro octetos são invertidos e in-addr.arpa é acrescentado. O PTR de 209.85.220.41 fica em 41.220.85.209.in-addr.arpa. O IPv6 usa ip6.arpa e inverte cada dígito hexadecimal.

É por causa desse formato de nome que você não consegue adicionar um PTR no painel de DNS do seu domínio. A zona reversa pertence a quem recebeu a alocação do bloco de IPs, e é essa pessoa ou empresa que a delega ou administra.

Uma única consulta PTR prova pouco, porque qualquer um que controle uma zona reversa pode apontá-la para qualquer nome, inclusive o seu. A checagem que interessa aos destinatários vai nos dois sentidos:

1. Reversa: consulte o PTR do IP que está se conectando. Você recebe um nome de host.
2. Direta: consulte o registro A (ou AAAA) desse nome de host. Ele deve incluir o IP original.

Se os dois baterem, o IP tem DNS reverso confirmado (muitas vezes escrito FCrDNS). Isso é mais antigo que qualquer regra para remetentes em massa. O RFC 1912, um guia informativo de 1996 sobre erros comuns de DNS, já dizia: "Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain." (Garanta que seus registros PTR e A batam. Para cada endereço IP deve haver um registro PTR correspondente no domínio in-addr.arpa.)

Como verificar o seu com dig

Rode dig -x no IP de envio e depois consulte o nome de host retornado. Este foi o resultado em 7 de outubro de 2026 (UTC) para alguns IPs de envio conhecidos:

$ dig -x 209.85.220.41 +short
mail-sor-f41.google.com.
$ dig +short A mail-sor-f41.google.com
209.85.220.41

IP de envio	PTR	Registro A desse nome	Confirmado?
209.85.220.41 (Google)	mail-sor-f41.google.com	209.85.220.41	Sim
54.240.8.1 (Amazon SES)	a8-1.smtp-out.amazonses.com	54.240.8.1	Sim
198.2.128.1 (Mandrill)	mail128-1.atl41.mandrillapp.com	198.2.128.1	Sim
O IP de banda larga do nosso escritório	nenhum	n/a	Não

O padrão é constante: todo serviço de envio conhecido publica um par que bate, e a conexão residencial não publica nada.

Para descobrir o IP que realmente enviou uma mensagem, abra os cabeçalhos completos de uma mensagem que você recebeu e leia a linha Received: mais acima, adicionada pelo seu próprio provedor. Nosso guia para ler cabeçalhos de e-mail mostra em qual linha confiar. Se preferir não usar a linha de comando, o Admin Toolbox Dig do Google tem uma consulta PTR.

O que Gmail e Yahoo exigem

Os dois provedores listam DNS direto e reverso válido como requisito para todo remetente, não só para quem envia em massa.

As Email sender guidelines (diretrizes para remetentes) do Google dizem: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." (O endereço IP público de um servidor SMTP de envio deve ter um registro PTR correspondente que resolva para um nome de host.) E continuam: "The same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server." (Esse mesmo nome de host também deve ter um registro A, para IPv4, ou AAAA, para IPv6, que resolva para o mesmo IP público usado pelo servidor de envio.) As perguntas frequentes do Google ligam as falhas a códigos específicos, 4.7.23 e 5.7.25, que a comparação dos requisitos do Gmail e do Yahoo lista junto com os outros códigos de bloqueio.

Os Sender Requirements (requisitos para remetentes) do Yahoo pedem "Have a valid forward and reverse DNS record for your sending IPs" (ter um registro de DNS direto e reverso válido para seus IPs de envio) e vão além sobre como o nome deve ser: "Publish valid, meaningful, non-generic reverse DNS (PTR) records for all of your sending IPs" (publique registros de DNS reverso, PTR, válidos, com significado e não genéricos para todos os seus IPs de envio), "Reverse DNS should reflect your domain name in some way" (o DNS reverso deve refletir seu nome de domínio de alguma forma) e "Do not use a reverse DNS that looks like a dynamically-assigned IP instead of a static mail server" (não use um DNS reverso que pareça um IP atribuído dinamicamente em vez de um servidor de e-mail estático).

Como é uma falha

O Yahoo recusou nossa conexão de teste no primeiro comando do envelope porque o IP não tinha DNS reverso confirmado. Em 7 de outubro de 2026 abrimos uma sessão SMTP com o servidor de entrada do Yahoo a partir de uma conexão de banda larga de escritório sem registro PTR, sem enviar nenhuma mensagem. O servidor nos cumprimentou normalmente e depois respondeu ao MAIL FROM com:

550 5.7.25 Forward-confirmed reverse DNS failed

Ele fechou a conexão antes que pudéssemos indicar um destinatário. A página pública de códigos de erro do Yahoo não lista esse texto, então trate essa linha como o que observamos, não como comportamento documentado. Ela bate com o requisito escrito do Yahoo e usa o mesmo código estendido 5.7.25 que o Google associa a falhas de PTR.

O Spamhaus também trata isso como sinal de reputação. A página da lista de bloqueio CSS pede aos remetentes listados que primeiro "check all technical settings for correctness" (confiram se todas as configurações técnicas estão corretas) e diz "SMTP servers should be configured with correct forward and reverse DNS and HELO/EHLO values" (servidores SMTP devem ser configurados com valores corretos de DNS direto e reverso e de HELO/EHLO). Veja como funciona a remoção de uma lista de bloqueio se você já foi listado.

O PTR precisa bater com o nome do EHLO?

Deveria, mas o padrão não permite que um servidor recuse e-mail só por essa diferença. O RFC 5321, seção 4.1.4, diz que um cliente SMTP deve, se possível, informar seu nome de host principal no EHLO. Depois diz que um servidor "MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis." (PODE verificar se o nome de domínio do comando EHLO corresponde de fato ao endereço IP do cliente. Porém, se a verificação falhar, o servidor NÃO DEVE se recusar a aceitar uma mensagem por esse motivo.)

Na prática, os destinatários usam juntos o nome do EHLO, o PTR e a consulta direta como sinais de reputação, e os requisitos dos provedores acima tratam do PTR em si. A configuração mais simples evita a dúvida: um único nome de host, como mail.example.com, que é o PTR do IP, tem um registro A apontando para o IP e é o nome que o servidor anuncia no EHLO.

Quem pode mudar seu registro PTR

Quem é dono do IP de envio controla o PTR dele, então a correção depende de como você envia.

Como você envia	Quem é dono do IP	O que fazer
Google Workspace, Microsoft 365, Outlook.com, Gmail	O provedor de e-mail	Nada. Os IPs deles já têm FCrDNS
Um ESP em IP compartilhado (Mailchimp, SendGrid, pool compartilhado do SES)	O ESP	Nada. O PTR nomeia o ESP, e isso é o esperado
Um ESP em IP dedicado	O ESP	Alguns ESPs deixam você definir um nome de host com sua marca; siga os passos de configuração deles
Seu próprio servidor num provedor de nuvem ou VPS	O provedor	Configure o DNS reverso no painel de controle do provedor ou peça ao suporte
Seu próprio servidor em banda larga empresarial	O provedor de internet	Peça ao provedor; muitos não fazem isso em faixas dinâmicas ou residenciais

Alguns IPs dedicados do SendGrid, por exemplo, têm registros PTR com o domínio do próprio cliente em vez do domínio do SendGrid, que é como o "reflect your domain name in some way" do Yahoo aparece na prática.

Num VPS, configure primeiro o registro A do nome de host escolhido e depois defina o PTR com esse nome no painel do provedor. Alguns provedores não aceitam um PTR cujo nome ainda não resolva para o IP. Lembre que muitos provedores de nuvem bloqueiam a porta 25 de saída por padrão, então um PTR correto não significa que você pode enviar; veja quais provedores de nuvem bloqueiam a porta 25.

Erros comuns de PTR

A maioria das falhas de DNS reverso vem de uma destas cinco configurações.

• Nenhum PTR. Típico de conexões residenciais e de muitas pequenas empresas. Não envie direto para o MX a partir delas; faça relay pelo seu provedor ou por um ESP.
• Um PTR genérico. Nomes como 203-0-113-25.static.isp.example resolvem, mas parecem exatamente o que o Yahoo chama de "a dynamically-assigned IP" (um IP atribuído dinamicamente). Peça um nome dentro do seu próprio domínio.
• Um PTR que não resolve na direção direta. O PTR diz mail.example.com, mas esse nome não tem registro A, ou aponta para outro lugar depois de uma migração.
• Um PTR apontando para um CNAME. O RFC 1912 diz "PTR records must point back to a valid A record, not a alias defined by a CNAME." (Registros PTR devem apontar para um registro A válido, não para um alias definido por um CNAME.)
• Só o primeiro IP com nome. Se o servidor envia de vários IPs, ou de IPv6 além de IPv4, cada endereço precisa do seu próprio par que bate. O RFC 1912 diz o mesmo para hosts com várias interfaces.

Resumindo

1. Um PTR associa seu IP de envio a um nome de host; esse nome de host deve resolver de volta para o mesmo IP.
2. Gmail e Yahoo exigem isso de todos os remetentes. O Yahoo também quer um nome não genérico que reflita seu domínio.
3. Verifique com dig -x <ip> +short e depois com dig +short A <hostname>.
4. A mudança é feita por quem é dono do IP, não no DNS do seu domínio.
5. Se você envia pelo Google, pela Microsoft ou por um ESP, isso já está resolvido. Use o tempo em SPF, DKIM e DMARC, que você pode checar com a auditoria de entregabilidade.