Atualmente estou tentando descobrir como configurar meu rDNS para ser compatível com o SpamAssassin.
A documentação do SpamAssassin parece fornecer apenas o seguinte;
https://wiki.apache.org/spamassassin/Rules/CK_HELO_DYNAMIC_SPLIT_IP
"O HELO parecia suspeito. Isso normalmente é o resultado de um servidor de e-mail mal configurado que se anuncia como XXX-XXX-XXX-XXX.hostname.tld (onde XXX é um endereço IP)."
Atualmente, meu rDNS está configurado da seguinte forma no lado do ISP;
XX.XXX.XXX.XX.static.domainname.com
domainname obviamente sendo meu nome de domínio. Originalmente, era isso, mas sem a parte "estática", tentei fazer isso como a documentação sobre o que seria um rDNS "estático" e "não genérico" aceitável. Não pareceu resolver o problema. Também tentei usar o seguinte serviço;https://www.debouncer.com/reverse-dns-check
Atualmente sou Postfix/Dovecot no FreeBSD e uso cloudflare para meu DNS (exclusivamente no modo DNS apenas, pois o próprio cloudflare não suporta tráfego de e-mail), configurei um registro A para apontar meu DNS reverso para o IP do meu servidor para que resolva.
O que devo fazer para mitigar esse problema? Meu palpite atualmente seria remover totalmente o IP do registro rDNS.
Responder1
Para passar na verificação PTR, você terá que ter certeza de que o IP corresponde ao nome de host esperado. Se o seu servidor de e-mail for mail.example.com, ele deverá ficar assim ao fazer hostou dig:
mail.example.com has IP 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer mail.example.com
Se o seu domínio de e-mail não for XX.XXX.XXX.XX.static.domainname.com, você precisará alterá-lo. Se você controlar o DNS do domínio, poderá criar um registro PTR correspondente.
Responder2
Esta reclamação é especificamente sobre o endereço IP que aparece de alguma forma no registro PTR. Isso não é aconselhável por vários motivos, um dos quais, como você descobriu, é que muitos destinos marcarão seu e-mail como spam ou o rejeitarão imediatamente.
Defina o registro PTR para algo apropriado, que não inclua o endereço IP. O FQDN real do servidor geralmente é a melhor aposta.