Um de nossos parceiros recebe nossos e-mails com atrasos visíveis. O mesmo e-mail enviado para dois endereços em seu domínio às vezes é entregue em horas diferentes do servidor (verificado nos logs reais do servidor, não apenas nas caixas de correio do usuário). Eu suspeito que uma incompatibilidade na configuração reversa do DNS esteja causando esse problema, mas não tenho certeza de que isso resultaria nesses erros.
Estamos usando o G Suite (Google Apps for Business), eles estão usando o Exchange em suas próprias instalações (não sabem qual versão). Eles têm duas conexões de internet no escritório, e o servidor do Exchange pode ser acessado em ambos os endereços IP (assim, do lado de fora, posso fazer telnet 1.1.1.1 na porta 25 e 2.2.2.2 na porta 25 e obter as mesmas respostas). >
Digamos que o domínio seja example.com . O registro MX aponta para mail.example.com e mail.example.com resolve para 1.1.1.1 e 2.2.2.2 . 1.1.1.1 está sob seu controle, o registro PTR para 1.1.1.1 resolve para mail.example.com . O endereço 2.2.2.2 é não sob seu controle, o registro PTR aponta para 2-2-2-2.static.their-isp.com . O servidor de correio SMTP tem um banner de mail.example.com .
Estou mencionando esses registros PTR porque ferramentas como MXToolBox mencionam essa incompatibilidade de cabeçalho SMTP, mas depois de ler perguntas semelhantes aqui não está claro se isso se aplica apenas a enviar mensagens desse domínio (e spam filtros no lado de recepção), ou também recebendo mail lá.
Antigamente, a configuração do DNS era diferente: eles tinham dois registros MX, apontando para mail.example.com e mail2.example.com , com mail.example.com resolvendo para 1.1.1.1 e mail2.example.com resolvendo para 2.2.2.2 . O banner do SMTP ainda estava apenas em mail.example.com . Muitos e-mails foram atrasados, mas ainda assim recebidos depois de um tempo. Para um e-mail, recebi o seguinte aviso do Google:
Detalhes técnicos de falha temporária: O servidor do destinatário não aceitou nossos pedidos para se conectar. Saiba mais no link [mail.example.com. 1.1.1.1: esgotado] [mail2.example.com. 2.2.2.2: incapaz de ler o banner]
Eu interpretei isso como significando que a conexão via 1.1.1.1 estava inativa, a conexão via 2.2.2.2 estava em alta, mas o Gmail recusou-se a entregar a mensagem porque o banner SMTP ( mail.example.com ) não correspondia ao registro PTR de 2.2.2.2 ( 2-2-2-2.static.their-isp.com ) ou o registro DNS usado para encontrar 2.2.2.2 ( mail2.celds.com ). Depois de mencionar isso para eles, eles mudaram para a configuração mencionada acima.
Hoje, porém, comparei isso à configuração MX do G Suite e a configuração deles é semelhante:
- registro MX: ASPMX.L.GOOGLE.COM
- que resolve para 209.85.202.27
- que reverte para dg-in-f27.1e100.net
- O banner do SMTP é mx.google.com
O MXToolBox também menciona essa verificação de banner SMTP como possível, mas presumo que o Google saiba como configurar seus servidores: -)
Então, o que eu quero saber: qualquer uma das configurações acima pode causar problemas: o Google só pode enviar algumas mensagens para os servidores depois de um grande atraso? Ou existem outros lugares óbvios onde deveríamos estar procurando?
O padrão é o ptr aponta para um registro A que aponta para o ip do ptr. Os registros mx e seus destinos não estão em jogo.
Portanto, a consulta é do IP, puxe o registro PTR, do registro A, puxe o IP.
Veja como você o testa:
dig A $(dig -x 209.85.202.27 +short) +short
209.85.202.27
66.102.12.27
216.239.32.27
Além disso registros PTR autogerados são sempre marcados como inválidos / ruins.
2-2-2-2.static.their-isp.com = autogenerated/generic1
Tags smtp reverse-dns ptr-record