Pare de adivinhar o seu DNS: um tour amigável para desenvolvedores por MX, SPF, DKIM e DMARC

Por que os registros DNS de e-mail importam agora

A autenticação de e-mail costumava ser opcional. Em 2026, é o básico. Gmail e Outlook exigem SPF e DKIM para remetentes em massa, e o DMARC está rapidamente se tornando obrigatório para qualquer domínio que envie e-mails transacionais. Se seus registros DNS estiverem errados, seus e-mails não chegam — sem bounce, sem aviso, apenas silêncio.

O problema é que esses registros são documentados como RFCs, não como ferramentas. A maioria dos desenvolvedores copia e cola exemplos do guia de configuração do provedor de e-mail e torce pelo melhor. Isso funciona até você precisar solucionar um problema, adicionar um segundo serviço de envio ou explicar a um cliente por que os e-mails do formulário de contato estão caindo no spam.

Este guia percorre MX, SPF, DKIM e DMARC na ordem em que você realmente os encontrará, com detalhes suficientes para configurá-los corretamente e contexto suficiente para depurá-los quando quebrarem.

Registros MX: para onde vai o e-mail de entrada

Registros MX informam à internet quais servidores de e-mail aceitam mensagens para o seu domínio. Eles são os mais simples dos quatro, mas também os mais fáceis de configurar incorretamente.

Um registro MX tem duas partes: um número de prioridade e um hostname. Números de prioridade menores são tentados primeiro. Se você usa Google Workspace, seus registros MX podem se parecer com isto:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Os pontos finais importam — eles sinalizam que o hostname é totalmente qualificado. A maioria dos provedores de DNS os adiciona automaticamente, mas nem todos.

Erros comuns: apontar registros MX para um registro A em vez de um hostname, definir todas as prioridades com o mesmo número (o que anula o propósito de ter backups) ou esquecer de remover registros MX antigos ao migrar de provedor. Registros MX obsoletos não ficam ali de forma inofensiva — eles podem causar loops de e-mail ou dividir a entrega entre duas caixas de entrada.

Se você administra seu próprio formulário de contato e quer evitar spam sem depender de serviços de terceiros, entender como formulários viram vetores de spam é um bom ponto de partida.

SPF: quais servidores têm permissão para enviar como você

SPF (Sender Policy Framework) é um registro TXT que lista os endereços IP e domínios autorizados a enviar e-mail em nome do seu domínio. É a primeira verificação que a maioria dos servidores de e-mail faz ao receber uma mensagem que afirma vir de você.

Um registro SPF básico se parece com isto:

v=spf1 include:_spf.google.com ~all

Detalhando:

• v=spf1 declara a versão do SPF
• include:_spf.google.com delega para o registro SPF do Google
• ~all é uma falha leve — rejeite e-mails de fontes não listadas, mas sem ser rígido demais

Você também pode usar ip4: ou ip6: para permitir endereços específicos, ou a e mx para referenciar os registros A e MX do seu domínio. O mecanismo all no final controla o que acontece com e-mails de fontes que você não listou: -all é uma falha rígida (rejeitar), ~all é uma falha leve (marcar como suspeito), ?all é neutro (sem opinião), e +all é liberação total (não use isto).

O SPF tem duas arestas afiadas. Primeiro, ele quebra quando o e-mail é encaminhado, porque o servidor de encaminhamento não está no seu registro SPF. Segundo, registros SPF têm um limite de dez consultas DNS. Se você incluir serviços de terceiros demais, excederá o limite e o SPF deixará de funcionar. A correção é achatar seu registro SPF — substituir diretivas include: pelos intervalos de IP reais —, mas isso exige manutenção quando os provedores alteram seus IPs.

DKIM: prova criptográfica da identidade do remetente

DKIM (DomainKeys Identified Mail) adiciona uma assinatura digital ao seu e-mail de saída. O servidor receptor verifica a assinatura contra uma chave pública publicada no seu DNS. Se a assinatura for válida e a mensagem não tiver sido adulterada, o DKIM passa.

Ao contrário do SPF, o DKIM sobrevive ao encaminhamento, porque a assinatura viaja com a mensagem. Ele também é mais flexível — você pode ter várias chaves DKIM para diferentes serviços de envio, cada uma com seu próprio seletor.

Um registro DNS DKIM se parece com isto:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

O seletor (default neste exemplo) é arbitrário — seu provedor de e-mail o escolhe. O valor p= é a chave pública, geralmente uma string longa codificada em base64. Seu provedor de e-mail gera a chave privada e a usa para assinar mensagens de saída.

A configuração de DKIM quase sempre é tratada pelo seu provedor de e-mail. Seu trabalho é copiar o registro TXT que ele fornece e colá-lo no seu DNS. A parte complicada é que alguns provedores de DNS não lidam bem com registros TXT longos — eles os truncam ou exigem que você divida o valor em várias strings entre aspas.

Para verificar se o DKIM está funcionando, envie um e-mail de teste para um endereço Gmail e confira os cabeçalhos. Procure dkim=pass no cabeçalho Authentication-Results.

DMARC: aplicação de políticas e relatórios

DMARC (Domain-based Message Authentication, Reporting and Conformance) conecta SPF e DKIM e informa aos servidores receptores o que fazer quando a autenticação falha. Ele também habilita relatórios, para que você veja quem está enviando e-mail como seu domínio — tanto remetentes legítimos quanto falsificados.

Um registro DMARC mínimo se parece com isto:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none significa apenas monitorar — não rejeitar nem colocar em quarentena mensagens com falha
• rua=mailto:[email protected] especifica para onde enviar relatórios agregados

Quando você tiver confiança de que SPF e DKIM estão funcionando, pode endurecer a política para p=quarantine (enviar falhas para spam) ou p=reject (devolvê-las imediatamente). Você também pode definir uma política de subdomínio com sp= e especificar uma porcentagem de mensagens às quais aplicar a política com pct=.

Relatórios DMARC são arquivos XML enviados diariamente pelos principais receptores. Eles são verbosos e difíceis de ler em estado bruto, mas mostram exatamente quais mensagens passaram ou falharam na autenticação e por quê. Se você está vendo e-mails legítimos serem rejeitados, os relatórios mostrarão qual verificação de SPF ou DKIM está falhando.

Um detalhe importante: DMARC exige alinhamento. Para SPF, o domínio no cabeçalho Return-Path deve corresponder ao domínio no cabeçalho From (ou ser um subdomínio). Para DKIM, o domínio d= na assinatura DKIM deve corresponder ao domínio From. Se você usa um serviço de envio de terceiros, ele precisa oferecer suporte a caminhos de retorno personalizados ou assinatura DKIM com o seu domínio, não o dele.

Como auditar sua configuração atual

A maioria dos problemas de DNS é invisível até causar uma falha. Veja como verificar seus registros antes que algo quebre:

1. Consulte seus registros MX: dig MX example.com deve retornar os hostnames e prioridades dos seus servidores de e-mail. Verifique se eles correspondem à documentação do seu provedor de e-mail.

1. Verifique a sintaxe SPF: dig TXT example.com e procure o registro v=spf1. Passe-o por um validador SPF para detectar erros de sintaxe e violações do limite de consultas.

1. Verifique as chaves DKIM: Envie um e-mail de teste e inspecione o cabeçalho DKIM-Signature. Extraia o seletor e o domínio e então consulte dig TXT selector._domainkey.example.com para confirmar que a chave pública existe.

1. Valide a política DMARC: dig TXT _dmarc.example.com deve retornar seu registro DMARC. Certifique-se de que rua= aponta para um endereço que você realmente monitora.

1. Teste de ponta a ponta: Use um serviço como mail-tester.com ou envie para um endereço Gmail e confira os cabeçalhos completos. Procure spf=pass, dkim=pass e dmarc=pass no cabeçalho Authentication-Results.

Se você está depurando por que os e-mails não estão chegando, os cabeçalhos são sua melhor ferramenta. A maioria dos clientes de e-mail permite visualizar cabeçalhos brutos — no Gmail, abra a mensagem, clique nos três pontos e selecione “Mostrar original”. O cabeçalho Authentication-Results dirá exatamente qual verificação falhou e por quê.

Quando usar políticas de subdomínio

Se você envia e-mail a partir de vários subdomínios — por exemplo, newsletter.example.com para marketing e app.example.com para e-mails transacionais —, pode definir políticas DMARC por subdomínio. Isso permite aplicar políticas rígidas nos subdomínios que você controla enquanto mantém uma política mais flexível no domínio principal.

A contrapartida é a complexidade. Cada subdomínio precisa de seus próprios registros SPF, DKIM e DMARC, e você precisa acompanhar quais serviços de envio estão autorizados para quais subdomínios. Para a maioria das equipes pequenas, um único domínio bem configurado é mais simples e igualmente seguro.

O que fazer quando a autenticação quebra

O modo de falha mais comum é adicionar um novo serviço de envio sem atualizar o DNS. Se você começar a usar um novo provedor de e-mail transacional, precisa adicionar o include SPF ou intervalo de IP dele, configurar assinatura DKIM com o seu domínio e verificar o alinhamento DMARC.

O segundo problema mais comum é encaminhamento. Se usuários encaminham seu e-mail para outro endereço, o SPF falhará porque o servidor de encaminhamento não está no seu registro SPF. O DKIM geralmente sobrevive ao encaminhamento, então, desde que o DKIM passe e sua política DMARC permita alinhamento parcial, a mensagem ainda deve ser entregue. Se você está vendo e-mails encaminhados serem rejeitados, verifique sua política DMARC — p=reject com alinhamento estrito quebrará o encaminhamento.

O terceiro problema é propagação de DNS. Alterações em registros DNS podem levar horas para se propagar, e diferentes servidores de e-mail armazenam registros em cache por períodos diferentes. Se você acabou de atualizar um registro e ele não está funcionando, espere algumas horas e teste novamente. Você pode verificar a propagação com uma ferramenta como whatsmydns.net.

Principais conclusões

• Registros MX roteiam e-mail de entrada; SPF, DKIM e DMARC autenticam e-mail de saída. Eles resolvem problemas diferentes e você precisa dos quatro.
• SPF quebra no encaminhamento e tem um limite de dez consultas. DKIM sobrevive ao encaminhamento, mas exige configuração por serviço. DMARC conecta os dois e habilita relatórios.
• Comece com p=none no DMARC, monitore os relatórios por algumas semanas e depois endureça para p=quarantine ou p=reject quando tiver confiança de que e-mails legítimos estão passando.
• Erros de DNS são silenciosos. Teste sua configuração com e-mail real e inspecione os cabeçalhos para confirmar que SPF, DKIM e DMARC estão passando.
• Se a autenticação quebrar após adicionar um novo serviço de envio, verifique includes SPF, seletores DKIM e alinhamento DMARC. Os cabeçalhos dirão qual verificação falhou.

FAQ

Q: Posso ter vários registros SPF?

A: Não. Vários registros SPF farão com que todos eles sejam ignorados. Se você precisa autorizar vários serviços, use diretivas include: dentro de um único registro SPF, ou liste intervalos de IP diretamente. Fique atento ao limite de dez consultas.

Q: Preciso de DMARC se envio apenas alguns e-mails por dia?

A: Sim. DMARC não é sobre volume — é sobre provar que você é quem diz ser. Mesmo domínios pequenos se beneficiam do DMARC porque ele evita spoofing e oferece visibilidade sobre problemas de entrega. Comece com p=none e um endereço de relatórios.

Q: O que acontece se DKIM e SPF falharem, mas o e-mail parecer legítimo?

A: Depende da sua política DMARC. Se p=none, o e-mail é entregue com um aviso. Se p=quarantine, vai para o spam. Se p=reject, é devolvido. É por isso que você deve monitorar relatórios DMARC antes de aplicar uma política rígida — talvez existam remetentes legítimos que você desconhece.

Q: Posso usar a mesma chave DKIM para vários domínios?

A: Tecnicamente, sim, mas não faça isso. Cada domínio deve ter seu próprio par de chaves DKIM. Compartilhar chaves dificulta a rotação e aumenta o raio de impacto se uma chave privada for comprometida.

Q: Com que frequência devo rotacionar chaves DKIM?

A: Não há uma regra universal, mas uma vez por ano é razoável para a maioria dos domínios. Se você suspeitar que uma chave foi comprometida, rotacione imediatamente. Certifique-se de publicar a nova chave pública no DNS antes de começar a assinar com a nova chave privada, e deixe a chave antiga no DNS por alguns dias após a rotação para lidar com e-mails atrasados.

<!-- tool-cta:start -->

💡 Experimente isto: Inspecione a política publicada de qualquer domínio com DMARC Lookup para ver como os registros MX, SPF e DMARC se encaixam na prática.

<!-- tool-cta:end -->

Fontes

• RFC 7208: Sender Policy Framework (SPF) — A especificação do SPF, incluindo regras de sintaxe e o limite de dez consultas.
• RFC 6376: DomainKeys Identified Mail (DKIM) — A especificação do DKIM, cobrindo geração e verificação de assinaturas.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — A especificação do DMARC, incluindo sintaxe de políticas e formato de relatórios agregados.
• Google Workspace: Prevent spoofing and spam — Orientação prática sobre configuração de SPF, DKIM e DMARC para domínios do Google Workspace.