dns registro mx vs dns reverso

Question

Preciso de ajuda para esclarecer a configuração reversa do registro DNS e MX. Não consegui encontrar uma resposta definitiva no google. O caso está seguindo. Digamos que eu tenha domínio "mydomain.com", eu tenho um servidor SMTP chamado "mail.mydomain.com", que é hospedado pelo myprovider.com. Quero enviar / receber e-mails do domínio mydomain.com. Então eu adiciono MX record assim:

mydomain.com MX mail.mydomain.com

Eu também tenho um registro, apontando para o IP do servidor myprovider.com (supondo que seja 1.2.3.4):

mail.mydomain.com A 1.2.3.4

Agora, quero ter certeza de que meus e-mails serão entregues, então eu verifico DNS reverso para isso. Eu tenho os seguintes resultados:

mail.mydomain.com -> DNS check resolves to 1.2.3.4,

1.2.3.4 -> reverse DNS check resolves to s1.myprovider.com

Agora - isso significa que a verificação inversa do DNS anty-spam falha, porque o 1.2.3.4 não resolve o mail.mydomain.com? MAS: é um servidor compartilhado, então ele nunca será resolvido para o meu domínio.com - ele sempre será resolvido para myprovider.com - certo? Isso significa que o correio será potencialmente marcado como extensão? OR: o filtro anti-spam fará mais uma verificação de DNS, verificando o IP de s1.myprovider.com:

s1.myprovider.com -> DNS check resolves to 1.2.3.4

então ele decidirá as correspondências de DNS reverso? Qual é a verdade?

Talvez eu deva fazer isso de maneira diferente, devo apontar meu registro MX diretamente para s1.provider.com, desta maneira:

mydomain.com MX s1.myprovider.com

Então s1.provider.com resolve para 1.2.3.4 e 1.2.3.4 resolve para s1.provider.com, então está tudo bem, certo? (O único problema é que não tenho certeza de quão estável é esse nome de domínio "s1.myprovider.com" - talvez eles mudem de tempos em tempos, e às vezes é "s2.myprovider.com", e essa configuração falhar?)

    

Answer 1

Acho que você está confundindo os trocadores de correspondências de entrada e saída. Tentarei responder à sua pergunta tratando os dois separadamente:

Email de entrada

Quando outro MTA tiver uma mensagem para $localpart@$yourdomain , ele faz uma consulta DNS (digite MX , data $yourdomain ). A resposta é get é mail.$yourdomain (e provavelmente também é IP). Ele usa isso para se conectar à sua máquina na porta 25 e tentar entregar o e-mail. Como a outra máquina está enviando (não aceitando), ela não fará verificações anti-spam com base em sua máquina.

Correio de saída

Você deseja enviar um e-mail de $localpart@$yourdomain para outra pessoa. Sua máquina (isso não precisa ser igual ao registro MX) conecta-se ao servidor de correio remoto e tenta entregar o correio. Agora a máquina remota fará verificações anti-spam. Tem duas informações da sua máquina: o ' nome HELO / EHLO ' e o endereço IP.

Atualmente, a maioria dos servidores exige que o 'nome HELO' seja um nome de domínio totalmente qualificado e que seja resolvido para o seu endereço IP. Alguns exigem que o seu endereço IP tenha DNS reverso que não pareça dinâmico (como dyn-127-0-0-1.example.com ). Eu encontrei alguns servidores que aplicaram a limitação de taxa ou greylisting quando o 'nome HELO' não correspondia ao DNS reverso, mas nunca à rejeição total.

Minhas recomendações

• Mantenha seu registro MX como mail.$yourdomain .
• Se você também usa esta máquina para emails de saída, defina o 'Nome HELO' como mail.$yourdomain .

Uma máquina compartilhada para envio de e-mail está longe de ser ideal, o abuso de outros usuários pode facilmente colocá-lo em listas negras baseadas em DNS.

    

Answer 2

Você tem uma probabilidade maior de receber spam se seu nome de host for um endereço IP (ou contiver uma string semelhante a um endereço IP como 1.2.3.4.yourprovider.net), se o nome do host não apontar para o servidor, ou se você não tiver a configuração de DNS reverso.

Tanto quanto eu sei, desde que o DNS reverso aponte para um nome de host que resolve seu servidor, e desde que seu nome de host seja um nome de host que seja resolvido para seu servidor, você estará bem. Não importa se o DNS reverso e o nome do host são diferentes, desde que apontem para o mesmo lugar.