Inteligente. Focado. E-mail.
E-mail rápido e multiplataforma, projetado para filtrar o ruído.
💡 Reverse DNS lookup: O processo de resolver um endereço IP de volta para um nome de domínio, o oposto de como o DNS normalmente funciona. Para e-mail, é como os servidores de recebimento verificam se um endereço IP de envio realmente pertence ao domínio que ele afirma representar. O DNS normal vai do domínio para o IP. O DNS reverso vai do IP de volta para o domínio. Ambas as direções precisam corresponder.
Provavelmente não diretamente, mas vale a pena saber por quê.
Se você envia e-mail pelo Gmail, Google Workspace, Outlook ou Microsoft 365, o DNS reverso é tratado automaticamente pelo Google e pela Microsoft em seus próprios IPs de envio. Você não mexe nisso. O mesmo vale para IPs compartilhados em plataformas como Mailchimp ou Klaviyo. Esses ESPs gerenciam os registros PTR dos endereços IP de onde seus servidores enviam.
O DNS reverso se torna seu problema se você estiver enviando de um endereço IP dedicado (por meio de um serviço como SendGrid ou Mailgun) ou executando seu próprio servidor de e-mail em uma VPS ou instância de nuvem. Nessas situações, o registro PTR do seu IP não é definido automaticamente. Você precisa configurá-lo. E se ele estiver ausente ou configurado incorretamente, sua entregabilidade de e-mail é prejudicada.
O teste prático: se seus e-mails estão caindo no spam e seus registros DKIM, SPF e DMARC estão todos passando, um registro PTR ausente ou quebrado é a próxima coisa lógica para verificar.
O processo é chamado de Forward-Confirmed reverse DNS (FCrDNS). Veja o que acontece quando seu e-mail chega a um servidor de recebimento.
O servidor de recebimento pega seu endereço IP de envio e consulta o DNS pelo registro PTR (Pointer) associado a ele. Essa consulta vai para uma zona DNS especial chamada in-addr.arpa. Se um registro PTR estiver configurado, a consulta retorna um nome de host, algo como mail.yourbusiness.com.
O servidor de recebimento então faz uma consulta DNS direta regular nesse nome de host para confirmar que ele resolve de volta para o IP original. Se o IP corresponder, a verificação passa. Se o nome de host resolver para um IP diferente, ou não houver nenhum registro PTR, o remetente parece não confiável.
Essa verificação bidirecional é o ponto principal. Qualquer um pode afirmar que envia de yourbusiness.com. Muito menos pessoas conseguem manipular tanto o registro PTR quanto o DNS direto para fazê-los corresponder. Desde que o Google e o Yahoo apertaram os requisitos para remetentes em massa em 2024, o Gmail agora retorna um erro específico (421 4.7.23) para IPs sem um registro PTR válido. Não é mais opcional para quem envia volumes significativos.
DNS reverso ausente ou incompatível é um dos problemas de entregabilidade mais traiçoeiros. Nem sempre produz um retorno claro. Seus e-mails podem simplesmente ir silenciosamente para o spam sem explicação.
Antes de tentar consertar qualquer coisa, verifique se existe um registro PTR e se ele está correto.
MXToolbox: Acesse mxtoolbox.com/ReverseLookup.aspx e insira o endereço IP do seu servidor de e-mail. Ele retornará o registro PTR ou sinalizará se nenhum existir.
Linha de comando (Mac/Linux/Windows):
nslookup [your IP address]
Ou no Mac/Linux:
dig -x [your IP address]
A saída deve mostrar um registro PTR apontando para o nome de host do seu servidor de e-mail. Se não mostrar nada, ou apontar para algo genérico como o nome de host padrão de um provedor de nuvem (ec2-203-0-113-25.compute-1.amazonaws.com), isso é um problema que vale a pena corrigir.
Aqui está o detalhe crítico que a maioria das pessoas entende errado: os registros PTR são controlados por quem possui o endereço IP (seu provedor de hospedagem ou VPS, não o seu registrador de domínio).
Você não pode definir um registro PTR no Cloudflare ou GoDaddy. Você o define através da DigitalOcean, Vultr, Hetzner, AWS, Linode ou onde quer que o IP do seu servidor de e-mail resida.
Processo geral (servidor de e-mail auto-hospedado):
Para sua configuração passar no FCrDNS, você também precisa confirmar que o nome de host do seu servidor de e-mail tem um registro A que resolve de volta para o mesmo IP. Ambas as direções devem funcionar.
Se você está em um IP dedicado através de um ESP: SendGrid, Mailgun e serviços similares têm seus próprios fluxos de configuração de DNS reverso dentro de seus painéis. Para o SendGrid, fica em Settings > Sender Authentication > Reverse DNS. Consulte o guia de DNS reverso do SendGrid para o passo a passo completo. Eles geram os registros e te orientam na publicação deles.
Se você está em um IP compartilhado através de um ESP: O provedor cuida dos registros PTR para IPs compartilhados. Você não precisa configurar nada.
Evite nomes de host de nuvem genéricos. Um PTR padrão de um provedor de nuvem sinaliza "instância VPS genérica" em vez de "servidor de e-mail gerenciado". Os servidores de recebimento tratam isso como um sinal de alerta. Substitua-o por um nome de host personalizado que corresponda ao seu domínio.
O PTR é uma camada, não o conjunto todo. Um PTR limpo ajuda a estabelecer a legitimidade básica de envio, mas ele funciona junto com DKIM, SPF e DMARC, não no lugar deles. Um PTR perfeito sem DKIM ainda tem dificuldades. Coloque primeiro as três camadas de autenticação no lugar; depois verifique seu PTR.
Verifique novamente após qualquer mudança de infraestrutura. Se você migrar para um novo servidor, obter um novo IP ou trocar de provedor de hospedagem, seu registro PTR não acompanha automaticamente. Ele precisa ser reconfigurado para o novo IP. Fácil de esquecer. Vale a pena verificar.
Um registro PTR por IP, apontando para o nome de host de envio. Seu registro PTR deve resolver para o mesmo nome de host que seu servidor SMTP anuncia nas conversas SMTP (o comando HELO/EHLO). Incompatibilidades parecem inconsistentes para os filtros de spam.