Verificar a integridade do seu servidor de e-mail e encontrar um erro “DNS reverso não corresponde ao banner smtp” não é uma visão agradável, pois parece suspeito para os servidores receptores, mesmo que você tenha boas intenções.
Esse erro significa essencialmente que o nome de host que o seu servidor transmite quando se apresenta (o banner SMTP) não corresponde ao registro de ponteiro de endereço IP (PTR) do seu servidor de e-mail. Essa verificação existe porque os remetentes de spam raramente controlam a infraestrutura que usam para enviar lixo eletrônico, portanto, os provedores de e-mail usam esse aperto de mão como um “atestado” primário da legitimidade do seu servidor.
Naturalmente, isso levanta uma questão importante: qual é a importância de corrigir esse erro e quanto julgamento acontece antes mesmo de um e-mail ser aceito para entrega?
A seguir, explicaremos quando esse aviso afeta a capacidade de entrega, quando é seguro ignorá-lo e como decidir se a correção afetará o posicionamento na caixa de entrada ou se será apenas uma ferramenta de diagnóstico silenciosa.
Principais conclusões
- “Reverse DNS does not match SMTP banner” significa que o nome do host que o seu servidor de e-mail apresenta durante o handshake SMTP é diferente do nome do host retornado pelo registro de DNS reverso (PTR) do IP de envio.
- Quando isso é importante: uma incompatibilidade de DNS reverso / banner SMTP pode ser ignorada por si só, mas afeta a capacidade de entrega quando combinada com fatores como autenticação deficiente e baixo envolvimento.
- Como abordar as correções: somente corresponda o banner e o DNS se você controlar o IP e o nome do host; caso contrário, você corre o risco de interromper fluxos de e-mail legítimos apenas para limpar uma mensagem de erro.
Para que são usados o banner SMTP e o DNS reverso
Quando um servidor de e-mail se conecta a outro servidor, a primeira coisa que ele faz é anunciar um nome de host usando HELO ou EHLO. Esse valor se torna o banner SMTP. Ele é registrado imediatamente e vinculado à conexão antes mesmo que a autenticação, o conteúdo ou a reputação entrem em cena.
Então, por que isso é importante? Porque os receptores não avaliam o e-mail em um vácuo. Eles observam padrões. Com o tempo, eles aprendem que um nome de host específico vem de um IP específico, em uma cadência específica, comportando-se de maneiras previsíveis. É isso que lhes permite classificar o tráfego adequadamente, em vez de tratar cada conexão como um risco totalmente novo.
O DNS reverso analisa a mesma situação do outro lado. Em vez de confiar no que o servidor de envio afirma, o servidor de recebimento executa uma pesquisa de PTR no IP para ver qual nome de host a rede associa a ele.
Mas, se nem o banner nem o RTP provam nada, por que compará-los?
Porque as incompatibilidades raramente são aleatórias. Quando o banner SMTP tem uma identidade e o IP é resolvido para outra, os receptores começam a se perguntar se o remetente realmente controla sua infraestrutura ou se a está herdando indiretamente, seja por meio de hospedagem compartilhada, espaço IP revendido ou configuração de servidor mal mantida. Essa questão se torna mais importante em escala, onde os malfeitores também dependem de uma infraestrutura emprestada ou descartável.
Isso significa que toda incompatibilidade é um problema? Não. Os ambientes compartilhados fazem isso constantemente, e os provedores de caixa de entrada sabem disso. O que causa suspeita não é a incompatibilidade em si, mas a falta de intenção: banners padrão, PTRs genéricos, nomes rotativos ou configurações que parecem montadas em vez de operadas.
O objetivo da verificação é detectar se um servidor de e-mail tem uma identidade coerente ou se está apenas de passagem.
Quando os problemas de configuração colocam as probabilidades contra você, o envolvimento é o que realmente restabelece a confiança. O InboxAlly reforça os sinais de envolvimento aos quais os ISPs prestam atenção, geralmente melhor do que qualquer ajuste de infraestrutura individual. Agende uma demonstração gratuita e veja o que o InboxAlly pode fazer pelo posicionamento de sua caixa de entrada.
Quando esse erro se torna um risco para a capacidade de entrega
IPs dedicados versus ambientes de envio compartilhados
Esse aviso é muito comum na infraestrutura compartilhada. Os SMTPs em nuvem e os pools de hospedagem compartilhada atribuem IPs em escala, nomeiam-nos de acordo com convenções internas e não adaptam os registros PTR a clientes individuais. Seu banner de SMTP pode fazer referência ao seu domínio de envio ou a um nome de host de marca, enquanto o DNS reverso aponta para algo como mail-123.provider.net. Isso é normal.
A parte importante é o controle.
Em IPs compartilhados, os receptores presumem que você não é o proprietário da nomenclatura, portanto esperam alguma incompatibilidade e a descontam de acordo. A tentativa de forçar o alinhamento nessas configurações geralmente sai pela culatra, seja porque você não pode alterar o PTR ou porque acaba anunciando uma identidade que não é realmente sua.
Os IPs dedicados são diferentes. Aqui, as incompatibilidades podem ser um problema porque a suposição agora é oposta. Se você controla o IP, os receptores esperam que você também controle a nomenclatura dele. Portanto, um banner que reivindica uma identidade enquanto o PTR reivindica outra sugere uma configuração inacabada, padrões remanescentes ou uma infraestrutura que foi reutilizada de forma descuidada. Obviamente, nenhuma dessas opções inspira confiança.
Contraintuitivamente, é mais importante que a configuração faça sentido com o nível de controle implícito na sua infraestrutura do que se os nomes combinam perfeitamente.
Correspondência de padrões primeiro
Esse aviso quase nunca vem sozinho. Por si só, geralmente não é motivo de preocupação. Porém, na maioria das vezes, ele vem acompanhado de outras pistas que apontam para a mesma direção.
O envolvimento insuficiente é o acelerador mais comum. Se os usuários não estão abrindo, clicando ou respondendo, os receptores começam a examinar tudo com mais atenção. Um banner incompatível que normalmente não é um problema pode agora criar problemas de entrega de e-mail.
Problemas de autenticação, como inclusões de SPF acumuladas e políticas de DMARC meio criptografadas, vão ainda mais longe. Embora não sejam fatais individualmente, juntos eles revelam desleixo, e a incompatibilidade de banners se encaixa perfeitamente nessa narrativa.
Mas provavelmente o maior indicador de todos eles é a inconsistência de identidade. Em uma semana, o banner usa um nome de host de marca; na semana seguinte, ele volta ao padrão. O IP permanece o mesmo, o volume flutua, os domínios mudam. Tecnicamente válido, praticamente bagunçado.
Por exemplo, um remetente que usa um IP dedicado com SPF e DKIM configurados corretamente, deixa o banner SMTP no nome de host padrão do Postfix, mantém um registro PTR genérico e envia em picos de volume semanais irregulares. Não há nada de errado “no papel”, mas é quase certo que a capacidade de entrega de e-mail será prejudicada.
Quando você corre o risco de ser penalizado?
As penalidades geralmente são aplicadas durante as transições. Os IPs frios não obtêm muito benefício da dúvida, e os novos domínios combinados com uma infraestrutura incoerente são classificados com cautela. Inconsistências como essas retardam a formação da confiança quando ela é de extrema importância.
Causas comuns que você verá
Você raramente vê esse aviso porque alguém fez algo ultrajante. Na maioria das vezes, ele vem de um punhado de configurações muito comuns que deram errado apenas o suficiente para parecerem desleixadas.
- PTRs genéricos definidos pelos provedores de hospedagem. A maioria dos provedores de hospedagem atribui configurações de DNS reverso automaticamente e nunca as revisa. O PTR aponta para um nome de host de propriedade do provedor, enquanto o banner SMTP usa algo personalizado. Isso é bom em infraestrutura compartilhada, mas não tanto em IPs dedicados.
- Banners SMTP padrão não verificados. O Postfix anunciando mail.localdomain ou o Exchange expondo um nome de host interno ainda é surpreendentemente comum, mesmo que o problema tenha sido discutido à exaustão. Isso tem menos a ver com correção e mais com negligência.
- Vários domínios estão enviando de um IP. Um IP, vários domínios, banners rotativos dependendo do aplicativo ou do fluxo de e-mail = esse erro, quase 100% das vezes.
- Mudanças na infraestrutura sem revisão da configuração do DNS. Um IP pode ser reatribuído, um servidor de e-mail reconstruído ou um provedor trocado, mas apenas parte da identidade é atualizada. O banner SMTP é alterado enquanto o PTR é deixado para trás (ou vice-versa), e a incompatibilidade persiste por muito tempo após a alteração original.
Todos esses casos mostram o que acontece quando a infraestrutura de e-mail muda de forma incremental em vez de ser projetada.
O que você deve fazer a seguir
Se você pode tirar uma conclusão, é que o alinhamento é mais importante do que a perfeição. Os sistemas de correio estão tentando entender se a sua infraestrutura se comporta como algo que é de propriedade, mantido e previsível.
Use avisos como esse para fazer perguntas melhores sobre controle, consistência e intenção. Verifique as alterações com base nos resultados reais de entrega, não apenas na saída do scanner. E resista ao impulso de “consertar” qualquer coisa que não afete o posicionamento da caixa de entrada na prática.
Configurações limpas ajudam; sistemas coerentes ajudam ainda mais. Mas a melhor coisa que você pode fazer para a capacidade de entrega é reforçar ativamente o envolvimento positivo para que os provedores de caixa de entrada confiem no seu e-mail desde o início.
Agende uma demonstração gratuita do InboxAlly para ver como o engajamento orientado pode ajudar a mover seus e-mails do spam direto para a caixa de entrada e mantê-los lá enquanto você faz alterações de infraestrutura como essa.