SPF, DKIM e DMARC: como configurar a autenticação de e-mail no DNS do seu domínio

1. Dê a cada serviço de envio um lugar no mapa

Os registros MX informam aos servidores remetentes para onde entregar o e-mail que chega ao domínio. O envio funciona de outro jeito. Uma empresa pode receber mensagens no provedor de e-mail corporativo e, ao mesmo tempo, mandar notas fiscais pela plataforma de e-commerce, respostas de suporte pelo sistema de atendimento e newsletters por um serviço de e-mail marketing. Cada um desses caminhos precisa ser autorizado e assinado separadamente.

Monte um inventário de remetentes com uma linha por serviço. Anote o endereço que aparece no campo De (From), o domínio do envelope (o Return-Path, que recebe as devoluções), o domínio que assina com DKIM, a pessoa responsável e um exemplo real de mensagem. Esses três domínios podem ser diferentes de forma legítima: um serviço de newsletter pode usar no envelope um subdomínio dedicado, como bounces.example.com, ou um domínio do próprio provedor. É justamente por isso que vale registrar tudo junto. Anote também o nome exato do domínio de e-mail ao lado do nome do site, porque example.com e www.example.com são nomes diferentes no DNS.

O inventário faz diferença quando a equipe contrata um serviço novo, desativa um antigo ou passa a responsabilidade para outra pessoa. Sem ele, fica difícil saber se um remetente que aparece nos relatórios de DMARC é legítimo ou não.

2. Entenda o que cada mecanismo faz

Cada mecanismo cobre uma parte da história. O SPF olha o servidor que se conecta, e não o endereço que o leitor vê. Como resume o Antispam.br, do CGI.br e do NIC.br, ele existe para combater a falsificação do endereço de retorno (return-path). O DKIM, ao contrário, verifica o cabeçalho e as partes assinadas da própria mensagem. O DMARC é a peça que relaciona esses resultados ao nome que aparece para o destinatário. Já o TLS protege o transporte, não a identidade de quem envia. Com esses papéis claros, os cabeçalhos técnicos de uma mensagem entregue ficam bem mais fáceis de ler.

3. Mantenha o SPF alinhado aos caminhos reais de envio

O SPF compara o endereço IP do servidor que está entregando a mensagem com a política publicada para o domínio do envelope (o MAIL FROM). A política fica em um registro TXT que começa com v=spf1 e pode trazer a configuração de um provedor por meio de include:, que por sua vez pode apontar para outros registros. A especificação do SPF (RFC 7208) limita a avaliação a dez termos que geram consultas DNS (include, a, mx, ptr, exists e redirect), contando também os que estão dentro dos includes. Já ip4, ip6 e all não entram na conta. Passar do limite gera um erro permanente (permerror), e a mesma norma recomenda no máximo duas consultas que voltem vazias.

Publique um único registro SPF por nome: dois registros v=spf1 no mesmo nome também resultam em permerror. Ao contratar um serviço novo, acrescente-o ao registro existente conforme a documentação dele, em vez de criar outro. Quando um serviço for desativado, remova o include correspondente e atualize o inventário no mesmo dia. Evite o mecanismo ptr, que a própria RFC desaconselha, e nunca use +all, que autoriza qualquer endereço da internet a enviar pelo seu domínio.

O final do registro também merece atenção. Com ~all (softfail), o domínio diz que remetentes fora da lista provavelmente não estão autorizados; com -all (fail), diz que não estão autorizados. Parece natural escolher sempre o mais rígido, mas a RFC 9989 alerta que, com -all, alguns destinatários rejeitam a mensagem antes mesmo de avaliar o DMARC, inclusive quando ela passaria por ter uma assinatura DKIM alinhada. Essas rejeições não aparecem nos relatórios. Decida com o inventário na mão e sabendo se suas mensagens costumam passar por encaminhamentos.

Para consultar com dig ou nslookup os registros SPF e DMARC que o seu domínio publica hoje e lê-los termo a termo, siga o guia para verificar SPF e DMARC.

4. Conecte assinaturas, alinhamento e relatórios

O DKIM assina partes da mensagem com uma chave privada. A chave pública fica no DNS, em um nome no formato seletor._domainkey.example.com, como define a especificação do DKIM (RFC 6376). Ative a assinatura em cada serviço do inventário, publique os seletores que ele indicar e envie uma mensagem real para uma caixa de teste. No cabeçalho Authentication-Results da mensagem recebida, você vê como o destinatário avaliou SPF, DKIM e DMARC, do jeito que a mensagem chegou. Como cada serviço escolhe o nome do seletor, uma consulta externa não consegue listar as chaves DKIM de um domínio sem conhecer esses nomes; por isso, a conferência prática é feita na própria mensagem. Quando o serviço permitir escolher, use chaves RSA de 2048 bits: a RFC 8301 exige no mínimo 1024 bits, recomenda 2048 e proíbe o algoritmo rsa-sha1.

O DMARC é publicado em _dmarc.example.com, em um registro que começa com v=DMARC1. Em maio de 2026, a IETF publicou o DMARC como padrão na RFC 9989, que substitui a RFC 7489, um documento apenas informativo. A mensagem passa no DMARC quando o SPF ou o DKIM passam e estão alinhados com o domínio do campo De; uma única assinatura DKIM válida e alinhada já basta. No alinhamento relaxado, que vale quando nada é especificado, os domínios só precisam ter o mesmo domínio organizacional: um envelope em news.example.com se alinha com um campo De em example.com.

Comece com p=none, que não pede nenhuma ação aos destinatários, e um endereço em rua para receber os relatórios agregados. Eles resumem quais fontes enviaram em nome do domínio e com que resultado. Use esses dados para confirmar os serviços legítimos, corrigir os que falham e só então avançar. A RFC 9989 sugere pelo menos um mês em p=none e um período igual em p=quarantine antes de pensar em p=reject, e recomenda que domínios cujos usuários escrevem em listas de discussão não publiquem p=reject. Quem publicar reject deve assinar todas as mensagens com DKIM, porque o encaminhamento quebra o SPF. Cuidado com guias antigos: a tag pct foi removida, e para testar uma política agora existe a tag t=y, que pede ao destinatário aplicar um nível abaixo do publicado (reject passa a valer como quarantine, e quarantine como none).

Os grandes provedores de caixa postal também têm regras próprias. As diretrizes do Gmail para remetentes pedem a quem envia mais de 5.000 mensagens por dia para contas pessoais do Gmail: SPF e DKIM, um registro DMARC (que pode ficar em p=none), alinhamento do campo De com SPF ou DKIM e cancelamento de inscrição com um clique nas mensagens de marketing. A Microsoft pede um conjunto parecido aos domínios que enviam mais de 5.000 mensagens por dia para endereços do Outlook.com, Hotmail e Live, e passou a recusar com o erro 550 5.7.515 as mensagens que não atendem a esses requisitos.

5. Coordene certificados e transporte de e-mail

O registro CAA indica quais autoridades certificadoras podem emitir certificados para o domínio. Antes de emitir, a autoridade procura o registro CAA mais próximo do nome pedido, subindo na árvore de nomes. Assim, como explica a documentação do Let's Encrypt sobre CAA, um registro em example.com vale também para os subdomínios que não tenham registro próprio, e não ter CAA nenhum é permitido. Comece pela lista de quem emite seus certificados hoje: hospedagem, CDN, plataforma da loja e qualquer serviço que use um subdomínio seu com HTTPS. Inclua todos no registro, para que uma renovação automática não seja recusada. A especificação do CAA (RFC 8659) explica o formato e também os limites: o CAA não impede um erro de uma autoridade que você autorizou, e os navegadores não o usam para validar certificados.

O MTA-STS trata do caminho inverso: as mensagens que chegam ao seu domínio. Com ele, o domínio que recebe pede aos servidores remetentes que só entreguem aos seus servidores MX quando eles oferecerem TLS com certificado confiável. A configuração junta quatro peças: um registro TXT em _mta-sts.example.com; um arquivo de política servido por HTTPS em https://mta-sts.example.com/.well-known/mta-sts.txt, com o modo testing, enforce ou none; os nomes MX listados nessa política; e o certificado TLS desses servidores. Revise as quatro como um único serviço. Trocar de provedor de e-mail sem atualizar uma política em modo enforce, por exemplo, pode fazer remetentes recusarem a entrega. A especificação do MTA-STS (RFC 8461) descreve o ciclo de vida da política; começar em testing permite observar antes de exigir.

Para acompanhar essa fase de teste, publique também um registro de relatórios de TLS (TLS-RPT) em _smtp._tls.example.com, como define a RFC 8460. Ele indica para onde os remetentes podem enviar estatísticas e detalhes de possíveis falhas de TLS ao entregar mensagens para o seu domínio. Documentar juntos certificados, CAA e transporte de e-mail ajuda a equipe a manter a identidade do domínio coerente entre os serviços.

6. Revise o conjunto com mensagens reais

Antes de mudar o DNS, salve uma cópia dos registros atuais, identifique o provedor autoritativo do domínio e anote o TTL de cada registro que vai alterar. Comandos como dig TXT example.com e dig TXT _dmarc.example.com mostram o que está publicado; ao apontar a consulta para o servidor autoritativo, você vê a resposta na origem. Depois de publicar, compare essa resposta com a de um resolvedor público, lembrando que o valor antigo pode continuar em cache até o TTL expirar. Programe a próxima conferência levando esse tempo em conta.

1. Envie uma mensagem representativa de cada serviço do inventário para caixas de teste em provedores diferentes.
2. Abra o cabeçalho Authentication-Results de cada mensagem recebida.
3. Anote o resultado de SPF, DKIM e DMARC e com qual domínio cada um passou ou falhou no alinhamento.
4. Compare com os relatórios agregados dos dias seguintes e atualize o inventário e os responsáveis.

Inclua os tipos de mensagem que a empresa realmente envia: notas fiscais, redefinição de senha, respostas do suporte, avisos de conta e newsletters. Guarde um exemplo datado de cada caminho de envio, com os cabeçalhos completos, para que a próxima pessoa da equipe veja a configuração funcionando. Assim, a manutenção do DNS deixa de ser uma tarefa isolada e vira uma rotina que a equipe consegue repetir.

Para consultar agora os registros SPF, DMARC, MTA-STS e CAA de um domínio, use o verificador de SPF e DMARC gratuito.

7. Reúna a identidade do domínio em um só lugar

Junte o inventário de remetentes, os registros DNS, as autoridades certificadoras autorizadas e as mensagens de exemplo em um único documento, com data e responsáveis. Para uma primeira leitura de fora, o snapshot gratuito de prontidão para lançamento do Sitelemetry roda oito verificações passivas em uma origem pública, sem cadastro; ele não é um pentest. Entre essas verificações estão SPF, DMARC, CAA e o registro DNS do MTA-STS, consultados no nome exato que você digitar. Por isso, se o domínio que aparece no campo De dos seus e-mails também responde como site, informe esse nome (example.com, e não www.example.com): um registro que falta em www não quer dizer que o domínio principal esteja sem DMARC ou CAA. O DKIM fica de fora, então o teste com mensagens reais continua sendo a conferência principal.

Para seguir, veja o guia de certificado SSL/TLS e cabeçalhos de segurança para as conexões do site ou o guia de integrações para os serviços conectados ao negócio.