Estou pensando que não há absolutamente nenhuma razão ou justificativa para isso, mas antes de abrir minha boca e conseguir algum admin em kimchi profundo, eu pensei que deveria perguntar.
Existe alguma qualquer circunstância em que um registro MX deve apontar para um endereço de loopback? Para mim, isso diz que qualquer servidor de e-mail que tentar enviar para esse domínio, em vez disso, enviará para si mesmo e falhará, mas eu não sou um guru de e-mail, então talvez eu esteja perdendo alguma coisa.
Eu me deparei com o problema abaixo ao solucionar um problema por que não estou recebendo um e-mail para um cliente, e estou tendo problemas para resolver isso. Talvez eu esteja pensando demais sobre isso.
Resposta curta: Não deveria.
Resposta longa: Se o domínio em questão (DIQ) não receber email, colocar um endereço de loopback no registro MX faz com que o servidor de envio tente se conectar a ele mesmo. Isso economiza o DIQ em alguns bytes e possivelmente limpa os logs do firewall (se alguém estiver assistindo) quando outros servidores de e-mail tentam se conectar. No entanto, na minha opinião, a economia de largura de banda não é suficiente para justificar a violação da RFC 3330.
Definitivamente um NO, não com um IP 127.0.0.0. O intervalo 127.0.0.0 inteiro no IPv4 funciona como endereços de loopback, assim, quando qualquer máquina se conecta a IPs nesse intervalo, ele tentará se conectar a ele mesmo.
O endereço IP do seu registro MX deve estar acessível no mundo externo e o resultado é dizer a qualquer servidor que esteja fazendo uma consulta MX para tentar se conectar sozinho.
Se meu servidor estivesse tentando enviar um e-mail para você, ele procuraria o registro MX e, em seguida, conectaria seu próprio endereço IP, enviaria o e-mail e falharia.
Os RFCs relevantes dizem:
O registro de recurso MX DEVE apontar para um nome de domínio totalmente qualificado (não um endereço IP) de um servidor na Internet pública que aceita correio para o domínio. Observe que esse servidor não precisa necessariamente estar no mesmo domínio que o registro MX. RFC 1035 seção 3.3.9
Os endereços na faixa 127.0.0.0/8 NÃO DEVEM aparecer na Internet pública. RFC 5735 seção 3
Observe que alguns servidores de e-mail rejeitam o e-mail de remetentes que não estão em conformidade com os RFCs relevantes .
Bem, tenho uma situação em que definir o MX de um domínio para localhost parece ser necessário.
Em março de 2012, registrei um domínio fofo que fiquei surpreso ao encontrar disponível. Era para um site de colaboração artística que minha filha queria criar. Eu configurei o MX para um dos meus outros servidores smtp. Isso funcionou bem, mas depois comecei a receber muitos e-mails de "usuário desconhecido" para [email protected] (não o nome de domínio real). Então eu usei o MailScanner para bloquear todas as mensagens recebidas para esse domínio, exceto por um endereço legítimo. Parece que o domínio era um serviço de e-mail gratuito a partir de 2001, mas aparentemente havia ficado escuro e desistiu de seu nome de domínio fofo.
Isso funcionou bem até alguns dias atrás (11/20/12) quando o servidor SMTP começou a rejeitar mensagens recebidas devido a conexões abertas excessivas. Estes foram processos smtp à espera de "recibo para" respostas, eu acho. Eu olhei para o tráfego e eu estava sendo bombardeado por milhares de mensagens recebidas para [email protected] de tantos relés smtp em todo o mundo. (17.000 mensagens em um período de 24 horas)
Então eu mudei o MX para apontar para outro servidor não rodando o smtp com a porta 25 bloqueada. Com certeza, milhares de sessões perdidas começaram a aparecer. Como esse comportamento se parece com algum tipo de torrente de spam, talvez de uma botnet, imaginei que a configuração do MX para localhost pudesse ser solicitada.
Vou deixar assim por um tempo. Nós não precisamos de e-mails para o site cute.domain.com, então nada é perdido, exceto os ciclos para o botnet.
Quando um host deve ser capaz de enviar e-mail para si mesmo em diferentes domínios hospedados, mas não aceita correio externo, "MX 0 localhost". é aceitável. Para indicar que um host não possui nenhum servidor de e-mail, use "MX 0".
O "MX 0". está detalhado em RFC7505 .
Por que não usar um alvo MX que não resolve nada? Por exemplo:
example.com. NO MX 10 something.invalid.
Os spammers verão o erro de resolução e não se incomodarão com o próximo registro MX, achando que o alvo está mal configurado. Servidores reais tentarão o próximo registro. Isso não incomodará a porta TCP 25 de qualquer pessoa, ou seja, nenhum tráfego smtp, somente DNS.