Entenda o que uma verificação de registro MX confirma, como lidar com null MX, domínios mal configurados e falhas temporárias de DNS, e por que tentativas e cache reduzem rejeições falsas.
Uma verificação de registro MX indica se um domínio publica roteamento de e-mail no DNS, ou seja, que provavelmente é possível rotear mensagens para esse domínio. Ela não confirma que uma caixa postal específica existe nem que o servidor aceitará sua mensagem.
Não. Um domínio pode ter registros MX válidos e ainda assim rejeitar e-mail porque o endereço não existe, o servidor bloqueia remetentes desconhecidos ou são exigidas verificações adicionais. Trate o MX como um sinal a nível de domínio, não como prova de entregabilidade de uma caixa postal específica.
Um null MX é uma política explícita de “não enviar e-mail” definida pelo dono do domínio. Frequentemente aparece como um registro MX apontando para um único ponto (.), o que significa que intencionalmente não há lugar para entregar mensagens.
“Sem MX” pode ser ambíguo porque alguns sistemas de e-mail tentam um fallback A/AAAA quando não há MX, então o domínio ainda pode receber mensagens em certas configurações. Null MX é inequívoco: o domínio está dizendo explicitamente que não aceita e-mail, portanto geralmente é seguro rejeitar no cadastro.
Porque um nome de host MX pode existir no DNS, mas ainda assim ser inutilizável se não resolver para um endereço IP. Verificar que cada alvo MX tem registros A/AAAA captura um modo de falha comum em que o roteamento de e-mail parece configurado, mas não há como alcançá-lo.
Timeouts normalmente significam que seu resolvedor não obteve resposta a tempo devido a perda de pacotes, servidores autoritativos lentos, limites de taxa ou problemas temporários de rede. Geralmente é um problema retryable, não um sinal definitivo de que o domínio não recebe e-mail.
SERVFAIL indica que o resolvedor não conseguiu completar a consulta, frequentemente por problemas temporários de DNS como quedas upstream ou problemas com DNSSEC. Na maioria dos casos você deve tentar novamente brevemente e, se persistir, tratar o resultado como “desconhecido” em vez de inválido permanentemente.
Um padrão prático é 2–3 tentativas dentro de um orçamento de tempo curto (em torno de 1–2 segundos no total para a etapa DNS), repetindo somente erros retryable como timeouts ou SERVFAIL. Se ainda falhar, evite uma rejeição dura quando possível e mova o endereço para um caminho de “verificação posterior”.
Armazene resultados positivos usando o TTL DNS quando disponível, mas imponha um limite (por exemplo, não mais que 24 horas) para não confiar em dados antigos indefinidamente. Para falhas temporárias, cache por pouco tempo (normalmente 1–5 minutos) para evitar bombardear o DNS durante incidentes, e reavalie quando o usuário editar o e-mail ou quando a verificação anterior estiver além do limite.
Guarde um resultado juntamente com um código de motivo (por exemplo: domínio não existe, null MX, falha temporária de DNS, alvo MX sem IP) e um carimbo de data/hora de quando você verificou. Se quiser evitar costurar múltiplas checagens e casos de borda, Verimail (verimail.co) pode retornar um resultado estruturado que combina checagens de sintaxe, verificação de domínio/MX e detecção de provedores descartáveis em uma única chamada de API.
Uma verificação de registro MX responde a uma pergunta prática: este domínio pode receber e-mail em algum lugar? Ela não tenta determinar se uma pessoa é real, e também não confirma que uma caixa postal específica existe. Ela apenas inspeciona a configuração de roteamento de e-mail do domínio no DNS.
Quando a checagem é bem-sucedida, geralmente significa que o domínio publica servidores de e-mail (ou um fallback reconhecido) e, em teoria, mensagens podem ser roteadas para esse domínio. Isso é útil durante cadastros ou captura de leads porque filtra lixo óbvio, como domínios inventados, antes de você armazená-los ou enviar qualquer e-mail.
Mas resultados de MX não são garantia de caixa postal. Um domínio pode ter registros MX válidos e ainda rejeitar e-mail por muitos motivos: o endereço pode não existir, o servidor pode bloquear remetentes desconhecidos ou pode exigir verificações adicionais antes de aceitar mensagens. O MX também não informa se uma caixa está cheia, se um domínio está estacionado ou se o usuário tem acesso à caixa.
Um fluxo típico de validação trata o MX como um portão inicial, não como veredicto final. Você começa pela sintaxe básica, depois confirma que o domínio tem uma rota de e-mail plausível (MX e sinais DNS relacionados) e só então aplica regras de maior sinal, como detecção de provedores descartáveis, regras de risco para armadilhas de spam, e listas de permissão ou bloqueio.
O resultado de “falha” importa tanto quanto o fato de que falhou. A maioria dos sistemas acaba vendo um conjunto pequeno de desfechos:
Trate o MX como um sinal forte a nível de domínio, mas nunca como prova de que uma caixa postal específica é entregável.
O DNS é a lista telefônica da internet. Quando você digita um domínio, o DNS retorna registros que dizem aos computadores para onde conectar e como.
Durante uma checagem de registro MX (e qualquer verificação básica de domínio de e-mail), você vai se deparar repetidamente com alguns tipos de registro:
As respostas DNS podem mudar ao longo do tempo, mesmo para o mesmo domínio. O cache é a razão mais comum: seu dispositivo, roteador, ISP e resolvedores públicos podem armazenar respostas até o TTL expirar. Se o proprietário do domínio acabou de corrigir a configuração de e-mail, alguns usuários verão os novos registros MX rapidamente enquanto outros podem continuar vendo os antigos por minutos ou horas.
Um resolvedor é o serviço DNS que faz buscas em seu nome. A escolha do resolvedor importa porque resolvedores diferentes têm estados de cache, caminhos de rede e comportamentos de timeout distintos. Um resolvedor pode retornar uma resposta limpa instantaneamente enquanto outro retorna um erro temporário porque não consegue alcançar um nameserver autoritativo agora.
É por isso que um domínio pode parecer “bom” na sua rede Wi‑Fi do escritório e “ruim” em uma rede móvel. Por exemplo, o host MX pode resolver bem em um lugar, mas em outro um resolvedor dá timeout ao tentar buscar o registro A/AAAA, então o domínio parece quebrado mesmo que seja apenas um problema momentâneo de DNS.
Esses básicos ajudam você a tratar resultados DNS como sinais em vez de verdades absolutas. Eles também explicam casos de borda como null MX, configurações incorretas e falhas temporárias.
Comece tratando o domínio como entrada do usuário, não como “já limpa”. Remova espaços, pontos finais sobrando e deixe em minúsculas. Se o usuário usar caracteres internacionais (como ü ou 例), converta o domínio para sua forma IDN (frequentemente chamada de punycode) antes de consultar o DNS, para que você verifique o que o DNS realmente armazena.
Em seguida, execute a busca por MX desse domínio normalizado. Se você obtiver vários registros, ordene-os por prioridade (números menores são tentados primeiro). Essa ordenação importa mais tarde se fizer checagens mais profundas, porque um domínio “bom” pode ter um MX quebrado e outro funcionando.
Depois de ter resultados MX, valide os alvos, não apenas o fato de que “algo existe”. Cada registro MX aponta para um nome de host, e esse nome deve resolver para pelo menos um registro A ou AAAA. Se não resolver, servidores de e-mail não conseguem alcançá‑lo mesmo que o registro MX esteja presente.
Quando não há registros MX, verifique se o domínio base tem registros A/AAAA. Muitos sistemas tratam isso como fallback porque alguns servidores de e-mail vão entregar para o A/AAAA do domínio se o MX estiver ausente. As limitações são importantes: ainda não prova que o domínio aceita e-mail e não protege contra domínios que intencionalmente não recebem mensagens.
Um fluxo seguro parece com isto:
Não armazene apenas “passou/falhou”. Mantenha um status, um código de motivo (por exemplo: MX_FOUND, NO_MX_BUT_A, MX_TARGET_NO_IP, DNS_TIMEOUT) e um timestamp checked_at para saber quando revalidar.
Um registro MX nulo é o dono do domínio dizendo claramente: “Este domínio não aceita e-mail.” Não é uma configuração quebrada nem uma queda temporária. É uma política intencional.
No DNS, normalmente aparece como um registro MX com um alvo especial de um único ponto (.). Esse ponto significa “em lugar nenhum”. Então uma busca MX pode ser bem-sucedida e ainda assim dizer para não entregar e-mail para esse domínio.
Null MX difere de dois resultados comuns que podem parecer semelhantes à primeira vista:
Com null MX não há ambiguidade. Se sua checagem retornar null MX, o comportamento mais seguro é tratar o domínio como não emailable e bloqueá‑lo no cadastro (ou exigir outro endereço). Deixar passar gera bounces previsíveis e prejudica a entregabilidade.
Como explicar isso aos usuários é importante. Evite termos DNS e seja prático:
Separe null MX de “não foi possível checar agora”. Null MX deve ser rejeição confiante. Erros temporários devem acionar uma via de retry, não um bloqueio definitivo.
Muitos domínios de e-mail não são um simples “sim” ou “não”. Eles existem, mas o DNS está bagunçado o suficiente para produzir resultados confusos na checagem MX. O objetivo é evitar rejeitar pessoas reais enquanto bloqueia domínios que não recebem e-mail.
Configurações incorretas comuns incluem registros MX que apontam para um host de e-mail que não existe, frequentemente porque o dono trocou de provedor e deixou registros obsoletos. Outro problema frequente é alvo MX inválido: MX deve apontar para um nome de host, não para um endereço IP. Você também pode encontrar cadeias de CNAME que terminam em lugar nenhum, entram em loop ou se comportam de forma inconsistente entre resolvedores.
Alguns domínios não têm caminho de entrega utilizável: sem MX e sem A/AAAA funcional. Outros retornam respostas inconsistentes (registros MX aparecem em uma consulta e desaparecem na seguinte), geralmente devido a propagação ou hospedagem DNS mal configurada.
Classifique com base na confiança.
Trate o resultado como uma falha dura quando o domínio claramente não pode aceitar e-mail, como um alvo MX inválido (por exemplo, apontando para um IP) ou hosts MX que são consistentemente NXDOMAIN após tentativas.
Trate como falha branda quando o resultado pode ser temporário (timeouts, respostas inconsistentes, SERVFAIL). Nesse caso, peça ao usuário para tentar novamente, ou permita o cadastro mas marque o endereço para confirmação posterior.
Use uma categoria desconhecido para domínios estranhos mas não definitivamente quebrados, e combine o resultado MX com outros sinais em vez de tomar uma decisão única e definitiva.
Uma busca MX com falha nem sempre significa que um domínio não pode receber e-mail. Às vezes o resolvedor (ou o provedor DNS do domínio) está tendo um minuto ruim. Se você tratar toda falha como “inválido”, vai rejeitar usuários reais durante incidentes breves.
Esses são resultados comuns de erro DNS e como eles normalmente se mapeiam na prática:
Uma abordagem prática é classificar erros em retryable vs final. Timeouts, SERVFAIL, REFUSED e truncamento são tipicamente “tente novamente”, idealmente com um pequeno backoff e um limite (2–3 tentativas). Só após falhas repetidas você deve cair para uma decisão mais branda como “desconhecido” em vez de “inválido”.
Para depuração, registre informações suficientes para identificar padrões sem armazenar dados pessoais desnecessários. O domínio consultado (não o e-mail completo), o código de erro e o resolvedor usado, contador de tentativas e timestamps, se houve retry por TCP, e se a resposta veio do cache geralmente são suficientes.
DNS normalmente é rápido, mas não é perfeitamente confiável. Se você tratar um timeout como um “não” definitivo, vai rejeitar usuários reais em falhas momentâneas. Uma boa checagem MX equilibra velocidade com uma pequena margem de segurança.
Mantenha tentativas limitadas e previsíveis para que o usuário não sinta o formulário travado:
Backoff e jitter significam apenas esperar um pouco mais a cada tentativa e evitar tentativas perfeitamente sincronizadas entre muitos usuários. Isso evita picos onde muitos cadastros pressionam o DNS ao mesmo tempo.
O cache impede que você pergunte a mesma coisa várias vezes. Faça cache de resultados positivos usando o TTL DNS quando disponível, mas imponha um limite (por exemplo, não mais que 24 horas) para não confiar em dados antigos indefinidamente.
Para resultados negativos ou de erro, faça cache por pouco tempo (geralmente 1–5 minutos). Isso evita bombardear o DNS durante incidentes curtos e mantém seus sistemas mais estáveis.
Force uma nova verificação quando importar: o usuário editar o e-mail, você observar nova atividade após um período de inatividade, ou sua última checagem estiver além do limite máximo de cache.
Uma checagem de registro MX é útil, mas é fácil tratá‑la como veredicto final.
Um erro é assumir que “MX existe” significa que um endereço é entregável. MX só diz que um domínio afirma aceitar e-mail em algum lugar. Não diz se uma caixa existe, se o servidor rejeita usuários desconhecidos, ou se o domínio é seguro para envio.
Outro erro é falhar duro na primeira ocorrência de timeout, SERVFAIL ou resposta instável. O DNS não é perfeitamente confiável. Se você bloquear um cadastro porque uma busca falhou, vai rejeitar usuários reais durante pequenas interrupções.
Null MX também é amplamente mal compreendido. Um registro null MX é um sinal explícito de que o domínio não aceita e-mail. Ignorar isso e aceitar o domínio de qualquer forma gera bounces garantidos depois.
Muitas implementações param cedo demais depois de ler os nomes de host MX. Elas nunca resolvem os alvos MX para A/AAAA, o que perde um modo de falha comum: o domínio publica MX que apontam para hostnames que não resolvem, ou que resolvem apenas para uma família de endereço inacessível.
O cache também pode causar problemas quando feito sem um plano de expiração. Armazenar resultados “para sempre” significa continuar rejeitando domínios que estavam temporariamente quebrados, ou continuar aceitando domínios que removeram serviço de e-mail.
Os padrões que geram mais dor em produção são consistentes:
Se você está validando no cadastro, pense em termos de confiança, não de certeza. Refaça tentativas em erros transitórios, faça cache por tempo limitado e combine checagens MX com outros sinais.
Use este checklist após sua checagem de registro MX:
Um exemplo concreto: um usuário se cadastra com [email protected] durante uma breve queda no seu resolvedor. A primeira busca dá timeout e seu app rejeita o cadastro. Se você tentar uma ou duas vezes ao longo de um segundo ou dois, frequentemente obterá uma resposta limpa sem atrasar muito o formulário. Se ainda falhar, mantenha o cadastro mas marque o e‑mail como “precisa de verificação posterior” e reavalie em background.
Guarde resultados por pouco tempo. Cachear sucessos e falhas recentes reduz buscas repetidas e ajuda a separar “este domínio não recebe e‑mail” de “o DNS esteve instável por um minuto.”
Um usuário tenta se cadastrar com um e‑mail de trabalho real, como [email protected]. Seu app executa uma checagem MX durante o cadastro para ver se o domínio pode receber e‑mail. Ao mesmo tempo, o provedor DNS do domínio tem um problema breve.
Na primeira busca, seu sistema não obtém um sim ou não claro. Em vez disso, a consulta DNS dá timeout ou retorna SERVFAIL. Isso não significa que o domínio seja falso. Significa que o resolvedor não conseguiu obter uma resposta naquele momento.
Se você tratar isso como “domínio inválido” e bloquear o cadastro, cria uma rejeição falsa. O usuário tenta de novo um minuto depois e funciona, o que faz sua validação parecer aleatória.
Um fluxo mais seguro separa “definitivamente ruim” de “temporariamente desconhecido”:
As tentativas ajudam porque muitos problemas DNS são breves. Cache curto ajuda porque múltiplos cadastros da mesma empresa podem acontecer próximos no tempo. Se sua primeira tentativa falhar devido a uma interrupção transitória, cachear essa falha por muito tempo pode bloquear usuários reais.
Quando o suporte perguntar “por que meu e‑mail foi rejeitado?”, evite culpar o usuário. Uma resposta clara é: “Não conseguimos confirmar que seu domínio de e‑mail podia receber mensagens naquele momento devido a um erro temporário de DNS. Por favor, tente novamente ou use outro endereço.”
Uma checagem de registro MX é um sinal forte, mas não deve ser seu único filtro. O próximo passo é transformar resultados DNS brutos em uma política clara que seu produto aplique de forma consistente.
Decida o que fazer com cada resultado. Null MX costuma ser bloqueio duro porque o domínio está dizendo explicitamente que não aceita e‑mail. Uma falha temporária de DNS raramente deve ser rejeição permanente. Configurações incorretas ficam no meio: você pode permitir o cadastro mas exigir que o usuário confirme o endereço antes de permitir ações importantes.
Um framework de política simples que muitas equipes usam fica assim:
Então combine resultados MX com outras checagens para não confiar demais no DNS. Uma cobertura adequada normalmente inclui checagens de sintaxe RFC, verificação básica de domínio, busca MX e detecção de e‑mail descartável.
A consistência importa tanto quanto precisão. Use códigos de motivo estáveis e mapeie‑os ao comportamento do produto. Se o suporte vê “dns_temporary_failure” mas os logs de analytics mostram “invalid_domain”, você não vai conseguir medir o que realmente está acontecendo.
Se preferir não construir e manter cada caso de borda internamente, um validador multi‑estágio pode retornar uma resposta estruturada em vez de você integrar chamadas DNS e listas separadas. Por exemplo, Verimail (verimail.co) combina checagens de sintaxe compatíveis com RFC, verificação de domínio e MX, e compatibilização em tempo real com provedores descartáveis conhecidos em uma única chamada de API.
Por fim, adicione um ciclo de revisão. Acompanhe com que frequência avisos são posteriormente confirmados como válidos, quantas vezes usuários bloqueados entram em contato com suporte, e se picos coincidem com incidentes de resolvedor. Em seguida, ajuste tentativas e cache para que pequenas quedas não se transformem em cadastros perdidos.
