Registros MX e TXT explicados

O que são registros MX?

Um registro MX associa um domínio a um ou mais exchangers de e-mail, cada um com um inteiro de prioridade (preferência). Remetentes tentam primeiro o número mais baixo; prioridades iguais podem ser balanceadas. Exemplo: `10 mail.example.com` e `20 mail-backup.example.com`.

Destinos MX devem ser hostnames com registros A ou AAAA — não endereços IP soltos. Após alterar MX, verifique com o DNS Checker e aguarde o TTL expirar em caches antigos. Combine a verificação MX com o Blacklist Checker se e-mail recebido começar a ir para spam.

Domínios de produção devem publicar pelo menos dois hosts MX em redes diferentes. Se o exchanger primário estiver inacessível, RFC 5321 exige que sites remetentes tentem o próximo host de menor prioridade. Documente ambas as prioridades em tickets de alteração e reexecute o DNS Checker após cada edição MX para que threads de suporte mostrem prioridades live, não capturas de painel.

O que são registros TXT?

Registros TXT armazenam strings de texto arbitrárias. Operadores de e-mail publicam SPF no apex (ou subdomínio legacy) como `v=spf1 ...`, DKIM em seletores como `default._domainkey.example.com`, e DMARC em `_dmarc.example.com`. Verificação de site usa tokens curtos (`google-site-verification=...`, `MS=ms...`).

Várias strings em uma mesma resposta TXT são normais. Alguns painéis dividem chaves DKIM longas em fragmentos. Ao diagnosticar, copie o valor concatenado exato do DNS Checker em vez de redigitar a partir de um PDF.

TXT também é usado para BIMI, MTA-STS e TLS-RPT em setups de e-mail avançados — ainda publicado como texto em nomes previsíveis. Se o provedor rota seletores DKIM, seletores antigos e novos podem coexistir brevemente; consulte TXT após cada rotação e anote TTL antes de remover chaves retiradas.

SPF, DKIM e DMARC em TXT

SPF lista quais hosts podem enviar e-mail pelo seu domínio (`v=spf1 include:... ~all`). Só pode existir um TXT SPF por owner name — strings SPF duplicadas invalidam a política por completo. Funda includes em vez de adicionar um segundo registo no apex.

DKIM publica uma chave pública em `selector._domainkey.example.com`. Alinhamento com o domínio do cabeçalho From importa para pass/fail DMARC. Após onboarding de um relay, confirme o TXT do seletor no DNS Checker conforme o painel do provedor antes de campanhas em massa.

DMARC em `_dmarc.example.com` define política (`p=none`, `quarantine`, `reject`) e endereços de relatório (`rua=`, `ruf=`). Comece com `p=none` para relatórios agregados, depois aperte quando SPF e DKIM alinharem de forma fiável. Reveja as três famílias com o DNS Checker após qualquer migração de e-mail — MX sozinho nunca prova SPF correto.

Como verificar MX e TXT online

Passo 1 — Abra o DNS Checker e insira o domínio (apex ou subdomínio). Passo 2 — Execute uma consulta completa ou foque nas seções MX e TXT. Passo 3 — Compare prioridade, destinos e strings TXT com o guia de configuração do seu provedor de e-mail. Passo 4 — Se os valores estiverem obsoletos, anote o TTL e consulte novamente após expirar.

Para uma consulta MX isolada, abra a ferramenta DIG, escolha tipo MX e inspecione a seção de resposta. Use o mesmo domínio no WHOIS para confirmar que os nameservers coincidem com o painel DNS que você editou.

Arquive a saída do checker em tickets: prioridades, hostnames de exchangers, strings SPF/DKIM/DMARC completas e valores TTL. Se Authentication-Results ainda mostrar falhas após correção, aguarde uma janela TTL completa e execute novamente o DNS Checker — caches recursivos frequentemente sobrevivem ao momento em que clica Save no painel.

Verificação e tokens TXT de terceiros

Search Console, Microsoft 365, Stripe e emissores de certificados pedem cada um uma prova TXT única no apex ou labels `_dnsauth`. Estes tokens coexistem com SPF como registros TXT separados no mesmo nome — ao contrário de SPF, várias strings TXT não relacionadas num owner são válidas.

Antes de apagar TXT «antigos» durante limpeza, confirme que nenhum é verificação activa ou chaves DKIM. O DNS Checker lista cada resposta TXT num nome para comparar com docs do provedor em vez de adivinhar de memória.

Após adicionar TXT de verificação, consulte imediatamente com o DNS Checker e novamente após TTL se o fornecedor ainda reportar falha. Alguns registradores publicam zonas em lote a cada poucos minutos — duas execuções idênticas do checker cinco minutos aparte dão confiança mais depressa do que só refrescar a UI do fornecedor.

Problemas comuns

SPF ausente é o caminho mais rápido para pastas de spam. Prioridade MX errada envia e-mail para um host desativado. TXT de verificação com erro quebra Search Console ou configuração Microsoft 365. Respostas em cache após não reduzir TTL antes de um corte parecem «DNS quebrado» quando a propagação ainda está em andamento.

Dois registros SPF no mesmo nome invalidam SPF por completo — mescle em um único TXT. DMARC sem DKIM/SPF alinhados reporta falhas mas não as corrige; trate DMARC como camada de política sobre registros de autenticação funcionais.

Apontar MX para um label só CNAME quebra resolução em resolvers estritos. Publicar MX para hostname sem A/AAAA operacionais cria perda silenciosa de e-mail — confirme alvos de exchangers no DNS Checker após cada mudança de destino MX.

MX e TXT durante migrações

Migrações de e-mail falham silenciosamente quando MX é actualizado antes de SPF/DKIM/DMARC estarem prontos no novo provedor, ou quando registros MX antigos permanecem com números de prioridade mais baixos do que o previsto. Publique baseline com o DNS Checker antes do cutover e compare secções MX e TXT de hora a hora durante a janela de migração.

Reduza TTL em MX e TXT críticos vinte e quatro a quarenta e oito horas antes da mudança se o host DNS permitir. Confirme TTL mais baixo publicamente com o DNS Checker — alguns painéis mostram 300 segundos enquanto a zona live ainda serve 3600 até completar o próximo ciclo de publicação.

Mantenha MX do provedor antigo com prioridade mais alta (número maior) até validar entrega entrante no novo stack, depois remova exchangers retirados. E-mail de saída pode ainda usar includes SPF antigos até actualizar TXT no apex — verifique ambas as direcções com o DNS Checker antes de fechar o ticket.

Documente quem possui cada string TXT (verificação marketing, e-mail IT, relatórios DMARC financeiros) para que futuras limpezas não apaguem registros de autenticação de produção por engano.

Perguntas frequentes

Quanto tempo levam as alterações DNS para aparecer?

A maioria dos resolvedores respeita o TTL (time to live). Se o TTL for 3600 segundos, espere até uma hora antes de as respostas em cache expirarem. Reduza o TTL antes de migrações, aplique a alteração e verifique com o DNS Checker até ver os novos valores.

Posso verificar MX e TXT sem instalar dig?

Sim. Abra o DNS Checker, insira seu domínio e filtre ou role até as seções MX e TXT. Para um único tipo de registro também pode usar a ferramenta DIG com tipo MX ou TXT.

Por que o e-mail funciona mas o SPF ainda falha?

SPF só autoriza IPs de envio ou cadeias include. Um registro MX correto não implica SPF correto. Compare seus IPs SMTP de saída com a cadeia include do SPF e use consultas TXT para confirmar que a string publicada corresponde à documentação do provedor de e-mail.

Devo usar vários registros MX?

Sim em e-mail de produção. Publique pelo menos dois hosts MX com prioridades diferentes (número menor = maior preferência). Se o primário cair, remetentes tentam a próxima prioridade conforme RFC 5321.

Qual RFC define SPF?

SPF está definido em RFC 7208 (antes RFC 4408). DKIM é RFC 6376 e DMARC é RFC 7489. Todos são publicados como registros TXT em nomes previsíveis.

Posso publicar MX e SPF no mesmo label de hostname?

MX e SPF geralmente vivem em nomes diferentes — MX no apex ou subdomínio mail, SPF como TXT no apex. Nunca coloque CNAME num label que também precise de MX ou SPF. Use o DNS Checker para confirmar que tipos conflitantes não partilham o mesmo owner name.

Com que frequência devo reverificar MX e TXT em produção?

Após cada alteração de DNS ou provedor de e-mail, mais auditorias trimestrais para domínios que enviam e-mail em massa. Monitorização automatizada via API DN01 pode alertar quando prioridades MX ou strings SPF divergem dos valores esperados.

O DNS Checker armazena minhas consultas?

Verificações bem-sucedidas podem aparecer no histórico recente local da sua sessão do navegador por conveniência. Use a API documentada com seu próprio token se precisar de monitoramento repetível sem a interface web.