Você manda uma mensagem para um endereço que parece perfeito, sem erro de digitação, e segundos depois recebe de volta um aviso: o domínio não tem registro MX. Ou sobe uma lista de contatos na plataforma de e-mail marketing e dezenas de endereços são recusados antes do disparo. Quase sempre o problema não está no que vem antes da arroba, e sim no que o domínio publica no DNS.
O registro MX é a instrução pública que diz para onde entregar as mensagens de um domínio. Sem ele, o correio não tem para onde ir. Por isso a checagem de MX é o primeiro teste sério de qualquer validador — é o que acontece nos bastidores quando você usa a ferramenta para verificar se um endereço consegue receber mensagens antes de apertar enviar.
O que é um registro MX, na prática
MX é a sigla de Mail Exchanger. É um tipo de registro DNS, publicado por quem controla o domínio, que aponta para o servidor responsável por aceitar e-mails daquele domínio. Cada entrada tem duas partes: um número de prioridade e um nome de host.
Quando um servidor precisa entregar uma mensagem para fulano@exemplo.com.br, ele descarta o que vem antes da arroba e pergunta ao DNS quem recebe correio de exemplo.com.br. A resposta é a lista de MX: o servidor escolhe um host dela, abre uma conexão SMTP e entrega. Se a lista voltar vazia, a entrega para ali.
Um detalhe que confunde muita gente: o MX aponta para um nome, nunca para um endereço IP. Esse nome ainda precisa ser resolvido em A ou AAAA para a conexão acontecer, e é aí que mora boa parte dos erros de configuração.
Prioridade e servidores de backup
O número que aparece antes do host é a prioridade, e ele funciona ao contrário da intuição: quanto menor o número, maior a preferência. Uma configuração comum se parece com isto:
- 10 mx1.provedor.com — servidor principal, recebe tudo em condições normais
- 20 mx2.provedor.com — assume quando o primeiro não responde
- 30 mx3.provedor.com — última tentativa antes de a mensagem ficar na fila do remetente
Se dois registros têm a mesma prioridade, o remetente distribui a carga entre eles. E vale desfazer um mito antigo: um MX de backup apontando para um servidor que não conhece o domínio não protege contra spam, só cria um caminho de entrega que ninguém monitora.
Como consultar o MX de um domínio
Você não precisa de acesso ao domínio para ler o MX dele, porque o DNS é público. No Linux ou no macOS, o caminho mais curto é o terminal:
- dig MX exemplo.com.br +short — devolve prioridade e host, uma linha por registro
- nslookup -type=mx exemplo.com.br — equivalente no Windows, sem instalar nada
- dig MX exemplo.com.br @8.8.8.8 — consulta um resolvedor externo, útil quando você desconfia de cache local
Se a resposta vier vazia, confira se você consultou o domínio certo: muita gente testa mail.exemplo.com.br quando o endereço termina em @exemplo.com.br, e são consultas diferentes. Lembre também do TTL: depois de corrigir um MX, pode levar horas até todo mundo enxergar o valor novo.
Quem não quer abrir o terminal usa uma ferramenta web. Ao checar um endereço no validador, a consulta de MX é feita na hora e o resultado aparece junto com a análise de sintaxe e do tipo de caixa.
Quando o aviso diz que o domínio não tem MX
Esse recado aparece em dois momentos bem diferentes. No retorno de uma mensagem já enviada, ele costuma vir com um código 5.1.2 ou expressões como domínio não encontrado. É falha permanente: o servidor não tenta de novo, porque não existe destino. Se você quer entender por que alguns retornos somem sozinhos e outros são definitivos, vale ler sobre a diferença entre bounce permanente e temporário.
Na validação antes do envio, o mesmo aviso é um sinal para remover o contato da lista ou confirmar o domínio com a pessoa. As causas mais frequentes são:
- o domínio existe, mas é usado só para hospedar site e nunca foi configurado para receber e-mail;
- o domínio foi digitado errado e caiu em algo parecido, do tipo gmial.com, que ninguém configurou;
- o registro expirou e a zona DNS inteira saiu do ar;
- alguém apagou o MX durante uma migração e ninguém percebeu, porque o site continuou funcionando normalmente.
Registro A como reserva e os erros que mais aparecem
Se um domínio não tem MX, a maioria dos servidores ainda tenta uma reserva: procura um registro A (ou AAAA) com o nome do domínio e entrega direto naquele IP. É o velho fallback previsto nas regras de SMTP, e hoje quase nunca funciona, porque esse IP costuma ser o do servidor web, que não escuta na porta 25. O resultado é conexão recusada e mensagem devolvida, só que com atraso.
Os erros de configuração que mais aparecem no dia a dia:
- MX apontando para um CNAME. O host indicado precisa ter registro A ou AAAA próprio. Apontar para um apelido contraria a especificação e alguns servidores simplesmente recusam a entrega.
- MX apontando para um IP. Também não vale: o campo espera um nome de host, não um número.
- Registro esquecido depois de trocar de provedor. Criaram os MX novos e deixaram os antigos. Parte das mensagens continua caindo na caixa velha, que ninguém abre.
- Ponto final ausente. Em alguns painéis, escrever mx.provedor.com sem o ponto faz o sistema concatenar o próprio domínio e virar mx.provedor.com.exemplo.com.br.
- Subdomínio sem MX. Endereços em @news.exemplo.com.br precisam de MX no subdomínio, porque o MX do domínio raiz não é herdado.
Um teste vale mais que qualquer painel: depois de ajustar o MX, mande uma mensagem real para o domínio a partir de uma caixa de entrada temporária e veja se ela chega. O DNS pode dizer que está tudo certo enquanto o servidor de destino recusa a conexão.
MX cuida da entrega, SPF, DKIM e DMARC cuidam da confiança
É fácil confundir os papéis. O MX trata de receber: diz por onde a mensagem entra no domínio. SPF, DKIM e DMARC tratam de enviar: dizem quem pode mandar mensagem em nome do domínio e o que fazer quando alguém falsifica o remetente. Todos moram no DNS, mas resolvem problemas opostos.
Um domínio bem configurado tem os dois lados em ordem. Se você está montando isso agora, o passo seguinte é entender como SPF, DKIM e DMARC funcionam juntos, porque é o que separa uma mensagem entregue na caixa de entrada de outra que some no filtro.
Perguntas frequentes
Todo domínio precisa de registro MX?
Só os que recebem e-mail. Um domínio usado apenas para hospedar site funciona perfeitamente sem MX, e é justamente por isso que endereços criados nele não recebem nada.
Quantos registros MX eu devo publicar?
Exatamente os que o seu provedor indicar, nem mais nem menos. Costumam ser de um a cinco, com prioridades diferentes. Criar entradas extras por conta própria não melhora a entrega.
Um domínio com MX válido garante que o endereço existe?
Não. O MX prova que o domínio aceita correio, não que aquela caixa exista. Por isso a validação continua depois dele, com testes de sintaxe, de domínio descartável e de resposta do servidor.
Quanto tempo demora até um MX novo valer?
Depende do TTL do registro anterior. Com TTL de uma hora, boa parte da internet enxerga a mudança nesse prazo; 24 horas atrasam bem mais. Abaixe o TTL antes da migração, não depois.
Dá para consultar o MX de um domínio que não é meu?
Dá. O DNS é público: qualquer pessoa pode ler MX, A, TXT e os demais registros de qualquer domínio, sem pedir permissão.
Antes de disparar a próxima campanha ou cadastrar um contato importante, gaste dez segundos e confira o endereço no validador, porque o MX é a primeira coisa que ele olha.
