Temos um servidor de e-mail (Mailenable) que usamos para vender contas de e-mail aos nossos clientes. Temos um cliente que não conseguiu enviar e-mail para um domínio específico e recebeu este erro do servidor de e-mail do domínio:
Motivo: A mensagem não pôde ser entregue porque o nome de domínio ourclientcompanyname.com não possui nenhum registro DNS.
A empresa que nos utiliza para e-mail não possui nenhum registro DNS para seu domínioourclientcompanyname.com
Os registros MX estão corretos, mas o domínio não possui outros registros DNS. Isso é um erro possível? Quais registros DNS o cliente deve adicionar?
Responder1
Os registros MX são bons, mas o domínio não possui nenhum registro DNS. Isso é um erro possível? Qual registro DNS o cliente deve adicionar?
Sim, alguns servidores de e-mail, ao receber um e-mail, verificam se o domínio do usuário remetente, e não apenas o servidor remetente, possui registros DNS. Acho que é um pouco bobo e não é uma boa verificação de spam, mas é o que é. Provavelmente, seu cliente precisará simplesmente inserir um Aregistro para seu domínio apex ourclientcompanyname.com. Obtenha para eles uma conta de hospedagem de US $ 5 e um site informativo de página única, apenas para ser gentil.
EDITAR:
Enterrado no antigo RFC 5321, diz na seção 2.3.5:
Somente nomes de domínio totalmente qualificados (FQDNs) resolúveis são permitidos quando nomes de domínio são usados em SMTP.
Não! Eu ainda acho que é bobagem pensar nisso como um impedimento de spam e é uma fusão de correlação/causa, mas ei, pelo menos é um padrão documentado e segui-lo tem alguns efeitos colaterais positivos na pasta de spam! Quem tem dois polegares e acabou de estudar RFC?
Responder2
Seção 2.3.5 da RFC 5321exige que os nomes de domínio usados no e-mail possam ser resolvidos em endereços.
Das partes relevantes:
Somente nomes de domínio totalmente qualificados (FQDNs) resolúveis são permitidos quando nomes de domínio são usados em SMTP. Em outras palavras, nomes que podem ser resolvidos para RRs MX ou RRs de endereço (ou seja, A ou AAAA) (conforme discutido na Seção 5) são permitidos, assim como RRs CNAME cujos alvos podem ser resolvidos, por sua vez, para MX ou RRs de endereço . Apelidos locais ou nomes não qualificados NÃO DEVEM ser usados. Existem duas exceções à regra que exige FQDNs:
- O nome de domínio fornecido no comando EHLO DEVE ser um nome de host primário (um nome de domínio que resolve um endereço RR) ou, se o host não tiver nome, um endereço literal, conforme descrito na Seção 4.1.3 e discutido mais detalhadamente em a discussão da EHLO na Seção 4.1.4.
Este não é um requisito novo;Seção 2.3.5 da RFC 2821(2001) tiveram linguagem semelhante.
O nome de domínio, conforme descrito neste documento e em [22], é o nome completo e totalmente qualificado (frequentemente referido como "FQDN"). Um nome de domínio que não esteja no formato FQDN não passa de um alias local. Aliases locais NÃO DEVEM aparecer em nenhuma transação SMTP.
Se o seu servidor de e-mail disser EHLO company.exampleque empresa.exemplo não pode ser resolvido para um endereço, é perfeitamente válido rejeitar essa conexão. O mesmo se aplica aos nomes de domínio usados nos endereços do remetente e do destinatário (com exceção do postmaster, que não exige nenhum nome de domínio).
(Antes da RFC 2821, os padrões vigentes eram RFC 821 e RFC 974, que datam da década de 1980 e tinham que acomodar muitas redes não-Internet que não existem mais, portanto, os padrões eram muito menos restritivos.)
Responder3
Para que o correio funcione corretamente, são necessários três registros DNS.
Um registro - mapeamento de nome de host para endereço IP
Registro MX - O registro MX está vinculado ao registro A do servidor de e-mail
Pesquisa reversa - O endereço IP precisa estar vinculado ao registro A para pesquisa reversa (prevenção de SPAM)
Além disso, o endereço PAT no firewall precisa ser definido para o servidor de e-mail para que o IP público (IP de origem) do servidor de e-mail corresponda à pesquisa inversa.
Normalmente, você precisará entrar em contato com seu ISP e solicitar que ele crie a pesquisa inversa se possuir os endereços IP que você está usando no lado público.
Nota: Não há RFC referente ao DNS reverso confirmado por encaminhamento. É simplesmente uma prática recomendada.