Noções básicas sobre verificação de registro MX: null MX, tentativas e cache

O que uma verificação de registro MX informa (e o que não informa)

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.

Resultados comuns de checagem MX (e o que normalmente significam)

O resultado de “falha” importa tanto quanto o fato de que falhou. A maioria dos sistemas acaba vendo um conjunto pequeno de desfechos:

• Sem registros MX: O domínio pode não aceitar e-mail, ou pode depender de fallback A/AAAA (validadores diferentes tratam isso de maneiras distintas).
• Registro MX nulo: O domínio está dizendo explicitamente “não envie e-mail aqui”.
• NXDOMAIN: O domínio não existe.
• Timeout / sem resposta: O DNS pode estar lento, bloqueado, com limitação de taxa, ou falhando temporariamente.
• SERVFAIL: O resolvedor não conseguiu completar a consulta, muitas vezes devido a um problema temporário de DNS.

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.

Noções básicas de DNS que você precisa antes de olhar resultados MX

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:

• MX: quais servidores de e-mail aceitam mensagens para um domínio (frequentemente com prioridades).
• A / AAAA: o endereço IP para um nome de host (A para IPv4, AAAA para IPv6). Alvos MX normalmente precisam desses.
• CNAME: um alias que aponta um nome para outro. Não pode existir no mesmo nome que alguns outros tipos de registro.
• TXT: texto usado para políticas de e-mail e verificação (como SPF, DKIM e DMARC).
• TTL (time to live): por quanto tempo uma resposta DNS pode ser cacheada antes de perguntar de novo.

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.

Passo a passo: como executar uma checagem de registro MX com segurança

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:

• Normalize o domínio (remova espaços, minúsculas, trate IDN).
• Consulte MX e ordene por prioridade.
• Se MX estiver vazio, consulte A/AAAA no domínio base (apenas sinal de fallback).
• Para cada alvo MX, confirme que resolve para A/AAAA.
• Armazene tanto um resultado quanto um motivo com que você possa agir.

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.

Null MX: o sinal explícito “não envie e-mail aqui”

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:

• Sem MX: O domínio não tem registros MX. Alguns sistemas fazem fallback para A/AAAA, então isso pode ser ambíguo.
• Falha temporária: O domínio pode aceitar e-mail, mas sua consulta DNS falhou no momento (timeouts, SERVFAIL, problemas de resolvedor).

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:

• “Este domínio de e-mail não pode receber mensagens. Por favor, use outro endereço.”
• “Não conseguimos enviar e-mail para este endereço. Tente outro domínio (por exemplo, uma conta pessoal ou do trabalho).”

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.

Domínios mal configurados: padrões comuns e como tratá‑los

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.

Falha dura vs falha branda

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.

Falhas temporárias de DNS: por que elas acontecem e o que fazer

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:

• Timeout: Sem resposta a tempo. Muitas vezes perda de pacotes, servidores autoritativos lentos ou um resolvedor sobrecarregado.
• SERVFAIL: O resolvedor não conseguiu completar a consulta (problemas com DNSSEC, outages upstream, servidores autoritativos quebrados).
• REFUSED: Um servidor se recusou a responder (limites de taxa, má configuração, setups restritivos).
• Resposta truncada (TC=1): A resposta foi grande demais para UDP e precisa de nova tentativa via TCP.
• NXDOMAIN (para o próprio domínio): O domínio não existe, e isso costuma ser seguro para tratar como permanente.

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.

Tentativas e cache: reduzindo rejeições falsas sem desacelerar o cadastro

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.

Uma política de tentativas adequada para uma página de cadastro

Mantenha tentativas limitadas e previsíveis para que o usuário não sinta o formulário travado:

• Tente no máximo 2–3 vezes no total.
• Espalhe as tentativas cerca de 200–500 ms entre si, com um pouco de aleatoriedade.
• Mantenha um orçamento total de timeout de cerca de 1–2 segundos para a etapa DNS.
• Refaça tentativas em timeouts e erros “server failed”, mas não continue tentando quando o resultado for claramente “domínio não existe”.
• Se a primeira tentativa estiver lenta, pule tentativas extras e caia para uma decisão mais branda (por exemplo, permitir o cadastro mas marcar o e-mail para verificação posterior).

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.

Regras de cache que evitam problemas repetidos

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.

Erros comuns que times cometem com checagens MX

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:

• Aceitar qualquer registro MX como “entregável” sem checagens adicionais
• Tratar o primeiro timeout ou SERVFAIL como falha permanente
• Ignorar null MX e aceitar o domínio
• Não resolver alvos MX para A/AAAA antes de marcar o domínio como “bom”
• Manter veredictos obsoletos indefinidamente em vez de revalidar

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.

Lista de verificação rápida antes de marcar um domínio como bom ou ruim

Use este checklist após sua checagem de registro MX:

• Normalize o domínio primeiro (minúsculas, remover ponto final e converter domínios internacionais para uma forma ASCII segura). Confirme que a parte do domínio é estruturalmente válida (sem espaços, sem pontos duplos, sem caracteres proibidos).
• Trate o roteamento de e‑mail como “confirmado” somente se houver registros MX utilizáveis e os nomes de host MX resolverem para IPs, ou se o domínio tiver um fallback A/AAAA válido que possa receber e‑mail.
• Se você receber um registro null MX, pare. Esse domínio está explicitamente dizendo “não enviar e‑mail aqui”.
• Fique atento a erros temporários de DNS. Se você vir timeouts ou SERVFAIL, não marque o domínio como permanentemente ruim até ter feito novas tentativas dentro de um pequeno orçamento de tempo.
• Registre o que aconteceu: o resultado, o tipo de resposta e um timestamp para que você possa rechecá‑lo em vez de adivinhar.

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.”

Cenário de exemplo: validação no cadastro durante um período de DNS instável

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”:

• Se o domínio não existe (NXDOMAIN), rejeite.
• Se o domínio publica null MX, rejeite.
• Se você obtiver timeout ou SERVFAIL, faça pequenas tentativas (2–3 tentativas com atraso curto).
• Se ainda falhar, permita o cadastro mas marque o e‑mail como “não verificado” e reavalie em background.
• Se o domínio retornar MX válidos, prossiga normalmente.

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.”

Próximos passos: transformar checagens MX em validação de e‑mail confiável

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:

• Bloquear: null MX, domínio claramente inválido ou provedor descartável conhecido
• Avisar: timeout DNS ou SERVFAIL, suspeito mas não provado ruim
• Permitir mas verificar depois: domínio existe mas MX parece mal configurado ou inconsistente
• Permitir: domínio e MX parecem normais, sem flags de risco

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.