MX ou problemas de registro A

Question

Temos um servidor de email (Mailenable) que estamos usando para vender contas de email para nossos clientes. Temos um cliente que não conseguiu enviar e-mails para um domínio específico e eles receberam esse erro do servidor de e-mail do domínio:

Reason: The message could not be delivered because the domain name ourclientcompanyname.com does not have any DNS records.

A empresa que nos usa para e-mail não possui registros de DNS para seu domínio ourclientcompanyname.com

Os registros MX são bons, mas o domínio não possui outros registros DNS. Isso é um erro possível? Quais registros DNS o cliente deve adicionar?

    

Answer 1

MX records are fin but the domain has no dns record at all. Is that a possible error? What dns record the client should add?

Sim, alguns servidores de email, após o recebimento de um email, verificam se o domínio do usuário que está enviando, não apenas o servidor de envio, possui registros DNS. Eu acho que é um pouco bobo, e não é um grande cheque de spam, mas é o que é. Seu cliente provavelmente precisará simplesmente colocar um registro A em seu domínio apex ourclientcompanyname.com. Consiga-lhes uma conta de hospedagem de US $ 5 e um site informativo de uma única página para uma boa medida, apenas para ser bom.

EDIT:

Enterrado dentro da antiga RFC 5321, diz na seção 2.3.5:

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.

Noice! Eu ainda acho que é um bobo pensar nisso como um impedimento de spam e é uma correlação / causalidade de conflação, mas ei, pelo menos, é um padrão documentado e seguindo ele tem alguns efeitos colaterais positivos na pasta de spam! Quem tem dois polegares e acabou de aprender RFC?

    

Answer 2

A seção 2.3.5 do RFC 5321 exige que os nomes de domínio usados no email sejam resolvidos para endereços .

Das partes relevantes:

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:

• The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.

Este não é um requisito novo; RFC 2821 seção 2.3.5 (2001) tinha linguagem semelhante.

The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.

Se o seu servidor de e-mail disser que EHLO company.example e company.example não podem ser resolvidos para um endereço, é perfeitamente válido rejeitar essa conexão. O mesmo vale para os nomes de domínio usados nos endereços de remetente e destinatário (com exceção do postmaster, que não exige nenhum nome de domínio).

(Antes da RFC 2821, os padrões que governavam eram o RFC 821 e o RFC 974, que datam da década de 1980 e tiveram que acomodar muitas redes não-Internet que não existem mais, portanto os padrões eram muito menos restritivos.)

    

Answer 3

Para que o correio funcione corretamente, há três registros DNS necessários.

1. Um registro - nome do host para o mapeamento de endereço IP

2. Registro MX - o registro MX está vinculado ao registro A do servidor de e-mail

3. Pesquisa reversa - O endereço IP precisa estar vinculado ao registro A para pesquisa inversa (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.

Você normalmente precisará entrar em contato com seu ISP e fazer com que eles criem a pesquisa inversa, caso possuam os endereços IP que você está usando no lado público.

Observação: não há RFC referente ao DNS reverso confirmado para frente. É simplesmente uma boa prática.