Defaults.Exposed › Correções › DNS Inverso (PTR)

Como corrigir DNS Inverso (PTR)

O DNS inverso é o crachá de identificação do servidor que envia o e-mail da sua empresa. Quando um fornecedor recetor como o Gmail ou o Microsoft 365 verifica quem está por trás do endereço de envio e obtém um nome que bate certo, o seu correio parece legítimo. Quando não há crachá — ou o nome e o número não coincidem — as suas faturas e orçamentos perfeitamente reais são tratados como suspeitos e mandados em silêncio para o lixo ou rejeitados.

O essencial para o seu negócio: As suas faturas, orçamentos e respostas a clientes caem em silêncio no spam ou nunca chegam — por isso os negócios estagnam, os pagamentos chegam atrasados e os clientes pensam que os ignorou, nada disto aparecendo como um erro que repararia.

Quanto isto lhe pode custar

Envia um orçamento a um potencial cliente quente, ele cai no spam dele, e ele escolhe o concorrente que «de facto respondeu» — e você nunca soube que o e-mail não aterrou.
As faturas para clientes desaparecem no lixo, os pagamentos chegam semanas atrasados, e o seu fluxo de caixa leva o golpe porque ninguém viu o e-mail.
Um cliente queixa-se de que nunca lhe respondeu — mas respondeu; o fornecedor de correio dele deitou a sua resposta no lixo em silêncio porque o seu servidor de envio não conseguiu provar quem era.
O seu domínio passa na revisão de segurança de um novo cliente em tudo o resto, depois é sinalizado porque o seu servidor de correio não tem identidade própria — uma pequena coisa que o faz parecer descuidado.
Mudou para um VPS barato ou uma nova aplicação para enviar as suas newsletters e faturas e, de um dia para o outro, a sua taxa de entrega cai — porque esse novo servidor de envio não tem crachá de DNS inverso e os grandes fornecedores já não confiam nele.

Por que importa. Todos os grandes fornecedores de e-mail verificam a identidade do servidor que envia o seu correio, e verificam-na em cada mensagem. Se esse servidor não conseguir provar quem é — ou se o nome e o número se contradizerem — o seu e-mail empresarial genuíno é tratado como se pudesse ser spam. Perde respostas, pagamentos e confiança, e como nada é devolvido, normalmente nunca descobre porquê.

A versão curta

Quando a sua empresa envia um e-mail, ele parte de um servidor de correio, e todos os servidores na internet têm um endereço numérico — o seu IP. O DNS inverso (um registo «PTR») é o crachá de identificação desse servidor: permite que qualquer pessoa que veja o número consulte o nome próprio por trás dele, como mail.suaempresa.com.

Os grandes fornecedores recetores — Gmail, Microsoft 365, Yahoo — verificam esse crachá em cada mensagem que envia. Um servidor que se sabe nomear, e onde o nome e o número coincidem, parece um servidor de correio legítimo. Um servidor sem crachá, ou com um crachá que não bate certo, parece exatamente uma daquelas máquinas anónimas e descartáveis que os spammers usam. Por isso, as suas faturas e orçamentos genuínos começam cada conversa sob suspeita — e muitos deles perdem.

A parte frustrante é que nada lhe diz que isto está a acontecer. Não há devolução, não há erro. O seu e-mail simplesmente fica em silêncio aquém do esperado.

Quanto isto lhe pode custar

Estas são as formas do dia a dia em que um registo de DNS inverso em falta ou incompatível se traduz em dinheiro e confiança a saírem pela porta. Nunca nomeamos uma empresa real — são padrões que vemos nos dados.

O orçamento que nunca aterrou. Envia um orçamento detalhado a um potencial cliente que o pediu nessa manhã. O fornecedor dele não consegue verificar o seu servidor de envio, por isso deita a mensagem no spam. Ele não vasculha o lixo. À tarde já aceitou o orçamento do concorrente — o que «de facto apareceu». Atribui-o a um contacto fraco; na realidade o seu e-mail nunca foi visto.
A fatura no vazio. Fatura um bom cliente. Cai na pasta de lixo dele. Trinta dias depois anda a perseguir um pagamento que está em atraso sem culpa dele — e agora há uma conversa desconfortável, uma relação tensa e uma falha de fluxo de caixa que era inteiramente evitável.
«Nunca respondeu.» Um cliente está aborrecido por ter ignorado a pergunta dele. Não ignorou — respondeu no mesmo dia. O fornecedor de correio dele deitou a sua resposta no lixo em silêncio porque o seu servidor de envio parecia pouco fiável. Fica a parecer pouco profissional por algo que, na verdade, fez bem.
O servidor de envio caseiro que envenenou tudo em silêncio. Para poupar dinheiro, o seu correio (ou só as suas newsletters e faturas automáticas) começou a sair por um VPS barato ou uma nova aplicação de envio. Esse servidor nunca recebeu um crachá de DNS inverso. De um dia para o outro, a sua taxa de entrega afundou em toda a linha — e como não há mensagem de erro, levou meses só a suspeitar da causa.
A bandeira da revisão de segurança. A equipa de TI de um cliente maior faz uma verificação de rotina ao seu domínio durante a integração. Tudo o resto está bem, mas o seu servidor de correio não tem identidade própria. É um pormenor técnico menor, mas lê-se como descuido — e agora está a corrigi-lo sob pressão de prazo, ou a explicá-lo, quando o domínio de um concorrente acabou de passar sem problemas.

O fio comum a tudo isto: o custo recai sobre si, é invisível enquanto acontece, e a correção é gratuita.

O que é na realidade

O DNS normal transforma um nome num número: escreve suaempresa.com e o DNS devolve o endereço IP a que se ligar. O DNS inverso faz o oposto — transforma um número de volta num nome. Dado o IP 203.0.113.10, uma consulta inversa (um «registo PTR») responde mail.suaempresa.com.

Porque é que os recetores se importam: quando o seu servidor de correio se liga ao Gmail para entregar uma mensagem, o Gmail vê o IP de origem. A primeira coisa que um filtro de correio sério faz é perguntar «quem é esta máquina?» — fazendo uma consulta inversa a esse IP. Um servidor de correio empresarial real tem uma resposta (mail.suaempresa.com). Uma máquina de spam descartável normalmente não tem, ou tem um nome genérico atribuído pelo fornecedor, como host-203-0-113-10.algumisp.net. Por isso, a presença e a qualidade do crachá são um dos primeiríssimos sinais de confiança aplicados ao seu correio — antes mesmo de o SPF, o DKIM ou o conteúdo da mensagem serem sequer olhados.

Verifica o servidor de correio, não o seu site. Isto tropeça as pessoas. O endereço do seu site está muitas vezes atrás de uma CDN ou proxy (como a Cloudflare) e nunca terá um crachá coincidente — e tudo bem, porque o DNS inverso para e-mail é sobre o IP do servidor de correio MX, uma máquina completamente separada. Esta verificação consulta corretamente o servidor de correio principal do seu domínio (o registo MX de menor prioridade), resolve-o para o seu IP e verifica o crachá desse IP.

A metade que a maioria das configurações falha: tem de bater certo nos dois sentidos. Ter um nome não basta por si só. O Gmail e os outros grandes filtros fazem algo mais rigoroso, chamado DNS inverso confirmado em sentido direto (FCrDNS):

Consulta o IP → obtém um nome (ex.: mail.suaempresa.com).
Agora consulta esse nome de volta → tem de resolver para o mesmo IP de onde começou.

Se os dois sentidos coincidem, o servidor é confirmado e totalmente confiável. Se há um nome mas aponta para outro lado (ou para lado nenhum), o servidor só é confiável a meias — um crachá que não sobrevive a um segundo olhar é tratado como mais fraco do que esperaria. Um PTR que aponta para um nome de host controlado por um atacante, e que não resolve de volta, é em certos aspetos pior do que não ter PTR nenhum.

É exatamente assim que esta verificação o pontua:

Confirmado em sentido direto (FCrDNS): o IP nomeia um host, e esse host aponta de volta para o mesmo IP. Pontuação máxima — é a configuração correta, e é o que os recetores confiam.
O crachá existe mas não confirma: há um registo PTR, mas o nome não resolve de volta para o IP do servidor de correio. Crédito apenas parcial — parece configurado mas os grandes filtros não vão confiar totalmente.
Sem crachá nenhum: sem registo PTR no IP do servidor de correio. Sem crédito, e o custo de entregabilidade é real.

Uma nota sobre o peso: na metodologia esta é uma verificação pontuada de segurança de e-mail (vale 25 pontos, um item de prioridade P2). Não é a verificação de e-mail mais pesada — essa é o SPF e o DMARC, que travam a imitação direta — mas é uma parte genuína e avaliada da sua reputação de e-mail, e uma das poucas que depende de o seu fornecedor acertar em algo, em vez de você. Se envia só através do Google Workspace ou do Microsoft 365, quase de certeza já passa; as empresas que falham são as que enviam pelo seu próprio servidor ou por um de terceiros.

Como é o «bom»: o IP do seu servidor de correio principal tem um registo PTR a apontar para um nome de host real que possui, e esse nome de host resolve diretamente de volta para o mesmo IP — os dois sentidos coincidem (FCrDNS confirmado).

Como corrigir (gratuito, ~10 minutos do tempo de alguém)

Entregue esta secção a quem é dono do endereço IP do seu servidor de correio — normalmente o seu fornecedor de e-mail ou de alojamento, ou o seu centro de dados se for um servidor auto-alojado — e note que a correção é gratuita. Esta é a única definição de e-mail que quase de certeza não pode alterar sozinho no seu painel de DNS normal, porque o DNS inverso é controlado por quem é dono do IP, não por quem é dono do domínio. Só cobramos para monitorizar que se mantém correto, nunca para fazer a alteração.

Passo 1 — Encontre o IP do servidor de correio de envio. Identifique o host MX principal do domínio (o servidor de correio com o número de prioridade mais baixo) e resolva-o para o seu endereço IP:

dig MX suaempresa.com        # encontra o host MX principal (de menor prioridade)
dig A mail.suaempresa.com    # resolve esse host para o seu IP

Esse IP é o que precisa do crachá. Não use o IP do site — é uma máquina diferente e muitas vezes está atrás de uma CDN que nunca vai bater certo.

Passo 2 — Peça ao dono do IP para definir o registo PTR. O DNS inverso reside com quem controla o bloco de IP, por isso o pedido vai para:

Google Workspace / Gmail: gerido automaticamente para os servidores de correio do próprio Google — se um domínio que envia só através do Google aparecer de algum modo a falhar, levante a questão com o suporte do Google. (Na prática, estes passam.)
Microsoft 365: igualmente gerido automaticamente para os servidores da Microsoft.
Um servidor de correio auto-alojado ou VPS: abra um pedido junto do seu fornecedor de alojamento ou centro de dados pedindo que definam o PTR (DNS inverso) do seu IP para o nome de host do seu correio. A maioria dos fornecedores expõe isto no painel de controlo em «Reverse DNS», «rDNS» ou «PTR». Nas grandes nuvens é uma definição de um campo (ex.: a AWS exige um pequeno formulário de pedido para ativar o rDNS num Elastic IP; a maioria dos VPS deixa-o definir de imediato).
Uma aplicação de envio de terceiros (newsletter / faturação / CRM): se envia dos seus próprios servidores partilhados, o fornecedor trata do DNS inverso — não há nada para definir, e pode ignorar isto para esse tráfego. Se envia de um IP dedicado que lhe comprou, peça-lhe que defina o PTR nele.

Diga-lhes o registo que quer, por exemplo: 203.0.113.10 → mail.suaempresa.com.

Passo 3 — Faça-o confirmar em sentido direto (este é o passo que a maioria falha). O nome de host no PTR também tem de resolver de volta para o mesmo IP através de um registo A normal que controla no seu próprio DNS. Portanto:

O PTR diz 203.0.113.10 → mail.suaempresa.com (o seu fornecedor define isto).
O registo A diz mail.suaempresa.com → 203.0.113.10 (define isto no seu DNS, ex.: Cloudflare → DNS → adicionar um registo A, Nome mail, conteúdo 203.0.113.10).

Os dois sentidos têm de apontar um para o outro. Só então fica confirmado em sentido direto e totalmente confiável.

Passo 4 — Volte a verificar o seu domínio. Confirme que o servidor de correio mostra agora DNS inverso confirmado em sentido direto e que a verificação passa. As alterações de DNS propagam-se em minutos a poucas horas.

Erros comuns

Definir o crachá no IP do site em vez do servidor de correio. O DNS inverso para e-mail é sobre o servidor MX. Pôr um PTR no endereço do seu site/CDN não faz nada pela entregabilidade — a máquina errada fica com o crachá.
Parar em «o PTR existe». Um nome por si só só merece confiança parcial. Se não resolver de volta para o mesmo IP, os filtros rigorosos (Gmail, M365, Yahoo) não vão confiar totalmente. Complete sempre a confirmação em sentido direto (Passo 3).
Esquecer o registo A depois de o fornecedor definir o PTR. O fornecedor define a metade inversa; tem de definir a metade direta no seu próprio DNS. As pessoas fazem uma e julgam-se prontas.
Pedir à parte errada. Enviar o pedido ao seu registrar de domínios ou fornecedor de DNS em vez do dono do IP dá-lhe um «não conseguimos fazer isso» — porque genuinamente não conseguem. Tem de ir para quem é dono do IP.
Nomes de host genéricos do fornecedor. Um PTR como host-203-0-113-10.algumisp.net existe tecnicamente mas não faz nada pela sua marca ou confiança. Use um nome de host real no seu próprio domínio que confirme em sentido direto.

Onde isto se encaixa

O DNS inverso é a identidade do servidor; o SPF, o DKIM e o DMARC são a camada de autorização e anti-imitação do domínio. Respondem a perguntas diferentes, e os grandes fornecedores verificam-nas todas. O SPF lista que serviços podem enviar por si; o DKIM assina criptograficamente as suas mensagens para que não possam ser adulteradas; o DMARC liga os dois e diz aos recetores o que fazer com o correio que falha — e protege o nome «de» visível que os seus clientes realmente veem. O DNS inverso fica por baixo de tudo isto, garantindo que a máquina que faz o envio é, em primeiro lugar, um servidor de correio real e nomeado. Acerte no SPF, DKIM e DMARC para a defesa mais forte contra imitação; acerte no DNS inverso para que um servidor de envio novo ou auto-alojado não seja silenciosamente desconfiado antes de o resto ter sequer hipótese. Cada uma destas correções é gratuita.

Perguntas frequentes

Não percebo de informática — consigo resolver isto sozinho?

Normalmente não, e tudo bem. Ao contrário da maioria das definições de e-mail, esta não se altera no DNS do seu próprio domínio — é definida por quem é dono do endereço de internet (o IP) do seu servidor de correio, que é o seu fornecedor de e-mail ou de alojamento. O seu papel é simplesmente reencaminhar-lhes a secção «Como corrigir». É uma alteração rápida do lado deles, e é gratuita.

Se uso o Google Workspace ou o Microsoft 365, já estou coberto?

Quase de certeza que sim — ambos gerem o DNS inverso automaticamente para os seus próprios servidores de correio, por isso um domínio que envie só através deles passa isto sem fazer nada. Se a nossa verificação ainda o sinalizar, quase sempre significa que parte do seu correio sai por um servidor diferente (o seu próprio, um VPS barato ou uma aplicação de envio de terceiros), e é esse servidor que está sem crachá. A secção de correção explica a quem contactar.

Corrigir isto pode estragar o meu e-mail?

Não. Isto apenas acrescenta ou corrige o registo de identidade do servidor de envio — não altera para onde vai o seu correio, quem pode enviá-lo, nem nenhuma das definições da sua caixa de entrada. Limita-se a tornar o e-mail que já envia mais provável de ser confiável e entregue.

Qual é a diferença entre isto e o SPF, DKIM e DMARC?

Esses três respondem «este domínio pode enviar esta mensagem?». O DNS inverso responde a uma pergunta diferente e anterior: «a máquina que está a enviar é um servidor de correio real e identificável, ou uma caixa anónima?». Os grandes fornecedores verificam ambas. Quer todas elas certas — mas o DNS inverso é o que apanha um servidor de envio acabado de criar ou auto-alojado antes mesmo de o SPF e o DKIM entrarem em jogo.

Temos um registo de DNS inverso mas a verificação ainda não passa totalmente — porquê?

Porque ter um nome não basta; o nome tem de bater certo nos dois sentidos. O crachá diz que o servidor se chama, digamos, mail.suaempresa.com — mas o Gmail depois consulta esse nome e espera que aponte de volta exatamente para o mesmo IP. Se não apontar (ou apontar para outro lado), os fornecedores tratam-no como não confirmado e só confiam a meias. Esta correspondência nos dois sentidos chama-se DNS inverso confirmado em sentido direto (FCrDNS), e é a parte que a maioria das configurações falha.

A correção é mesmo gratuita, ou é uma venda paga disfarçada?

A correção é sempre gratuita — é uma pequena alteração de configuração feita pelo seu fornecedor, não um produto que se compra. Quem lhe disser que configurar o DNS inverso exige um plano pago está enganado. Só cobramos para monitorizar que se mantém correto ao longo do tempo, nunca para fazer a alteração.