SPF, DKIM e DMARC: autenticação de e-mail explicada

Qualquer pessoa pode colocar o seu domínio na linha From de um e-mail. O SMTP, o protocolo que transporta e-mails, foi projetado em uma era de confiança e nunca verifica isso. A autenticação de e-mail é o conjunto de registros DNS que permite aos servidores receptores fazer essa verificação por você: o SPF define quais servidores podem enviar e-mails pelo seu domínio, o DKIM adiciona uma assinatura criptográfica a cada mensagem, e o DMARC vincula os dois ao endereço que o destinatário realmente vê e informa aos receptores o que fazer quando a verificação falha.

Sem esses registros, é mais provável que seus e-mails legítimos caiam no spam, e golpistas podem se passar pelo seu domínio com pouco esforço. Este guia explica o que cada registro faz, como eles funcionam em conjunto e o que verificar primeiro.

SPF: quem tem permissão para enviar

O SPF (Sender Policy Framework) é um único registro TXT no seu domínio que lista os servidores autorizados a enviar e-mails em nome dele. Um registro típico tem este formato:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

• v=spf1: identifica o registro como SPF. Ele deve vir primeiro.
• ip4: / ip6:: endereços individuais ou intervalos.
• include:: "confie também em quem este outro domínio listar". É assim que você autoriza o Google Workspace, o Microsoft 365 ou um serviço de newsletter.
• a e mx: os servidores para os quais seus registros A ou MX apontam.
• ~all ou -all: o que fazer com todos os outros: soft fail (aceitar, mas tratar como suspeito) ou fail.

Há um detalhe fácil de passar despercebido: o SPF verifica o envelope sender (o endereço Return-Path usado durante a entrega), e não o endereço From exibido no cliente de e-mail. Plataformas de newsletter costumam usar o próprio domínio de Return-Path, então o SPF pode passar sem comprovar nada sobre o seu domínio do From. Essa lacuna é exatamente o que o DMARC fecha.

Veja o que o seu domínio publica com o verificador de SPF: ele mostra os mecanismos interpretados, o qualificador final e quantas consultas DNS o registro exige.

DKIM: uma assinatura em cada mensagem

O DKIM (DomainKeys Identified Mail) funciona como um selo. O servidor de envio assina cabeçalhos selecionados e o corpo da mensagem com uma chave privada e adiciona um cabeçalho DKIM-Signature. O receptor busca a chave pública correspondente no DNS e verifica se nada foi alterado durante o trajeto. Duas tags da assinatura são as mais importantes:

• d=: o domínio de assinatura;
• s=: o seletor, o nome sob o qual a chave pública é publicada: selector._domainkey.example.com.

Como a chave é localizada pelo seletor, um domínio pode ter várias chaves DKIM ao mesmo tempo: uma para o seu provedor de caixa de e-mail, uma para a ferramenta de newsletter, uma para o CRM. Seletores, tamanho de chave e rotação são abordados em detalhes em O que é DKIM. Para saber se existe uma chave e qual é o tamanho dela, use o verificador de DKIM.

DMARC: alinhamento e política

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é um registro TXT em _dmarc.example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Ele faz três coisas:

1. Exige alinhamento. Uma mensagem só passa no DMARC se o SPF ou o DKIM passar e o domínio para o qual passou corresponder ao domínio do endereço From visível. No SPF, esse é o domínio do Return-Path; no DKIM, o domínio d=. Por padrão, a correspondência é "relaxed": mail.example.com se alinha com example.com porque eles compartilham o domínio organizacional.
2. Define uma política para mensagens que falham: none (apenas relatar), quarantine (pasta de spam) ou reject (recusar a entrega).
3. Ativa relatórios. Os receptores enviam relatórios agregados diários para o endereço rua, para que você veja todos os servidores que enviam e-mails como o seu domínio, inclusive os que você esqueceu.

Cada tag, a implantação de p=none até p=reject e como ler os relatórios estão explicados em Registro DMARC: como configurar o DMARC passo a passo.

Como os três funcionam em conjunto

A conclusão prática: o DKIM é a metade mais robusta porque sobrevive ao encaminhamento. Faça com que todo fluxo legítimo de e-mail passe com DKIM alinhado e trate o SPF como uma segunda linha de defesa.

O que o Gmail e o Yahoo exigem dos remetentes

Desde fevereiro de 2024, o Google e o Yahoo aplicam requisitos publicados para remetentes, e outros grandes provedores de e-mail seguiram na mesma direção. Em resumo:

• Todos que enviam para endereços pessoais do Gmail ou do Yahoo precisam de SPF ou DKIM, DNS direto e reverso válidos para os IPs de envio, TLS e uma baixa taxa de reclamações de spam.
• Remetentes em massa (o Google cita um limite de cerca de 5.000 mensagens por dia para seus usuários) precisam de SPF e DKIM, um registro DMARC com pelo menos p=none, um domínio do From alinhado com o SPF ou o DKIM e cancelamento de inscrição com um clique para e-mails de marketing.

Checklist de configuração

1. Liste todos os serviços que enviam e-mails em nome do seu domínio: provedor de e-mail, formulário de contato do site, ferramenta de newsletter, CRM, helpdesk, sistema de cobrança. Remetentes esquecidos são o principal motivo de e-mails quebrados na implantação do DMARC.
2. Publique um único registro SPF que cubra os serviços que usam seu domínio no Return-Path. Mantenha abaixo de 10 consultas DNS.
3. Ative o DKIM em cada serviço com o seu próprio domínio, não com o padrão do provedor. Cada serviço fornece um registro TXT ou CNAME para você publicar.
4. Publique o DMARC com p=none e um endereço rua que você realmente leia ou um serviço de processamento de relatórios.
5. Leia os relatórios por 2–4 semanas e corrija toda fonte legítima que falhar no alinhamento.
6. Endureça a política aos poucos: quarantine e depois reject.
7. Verifique o básico ao redor: a consulta de MX confirma onde seus e-mails são recebidos, e a verificação de blacklist de IP mostra se o seu IP de envio está listado. Para o restante do cenário de DNS, veja como verificar os registros DNS de um domínio.

Erros comuns

Dois registros SPF

Adicionar um novo serviço muitas vezes termina com um segundo registro v=spf1 ao lado do antigo. O padrão SPF trata isso como um erro permanente, e muitos receptores passam a ignorar o SPF por completo. Deve haver exatamente um registro SPF; una os mecanismos nele.

Mais de 10 consultas DNS

Cada include, a, mx, ptr, exists e redirect custa uma consulta, e os includes dentro de includes também contam. Acima de 10, o resultado é um erro permanente. Remova serviços que você não usa mais, substitua a/mx por IPs explícitos quando forem estáveis e evite ptr.

Remetentes terceiros sem DKIM

Google Workspace, Microsoft 365, Mailchimp e serviços semelhantes podem assinar com o seu domínio, mas geralmente só depois que você publica os registros DKIM deles e ativa a assinatura. Até lá, eles assinam com o próprio domínio ou não assinam, e o e-mail falha no alinhamento do DMARC.

p=reject no primeiro dia

Ir direto para reject sem ler os relatórios bloqueia todos os remetentes que você esqueceu: o sistema de faturas, o formulário do site, um parceiro que envia em seu nome. Comece com p=none, colete dados e depois endureça.

Esquecer os domínios que nunca enviam e-mail

Domínios estacionados e secundários são populares para spoofing justamente porque ninguém os monitora. Para um domínio que não envia nada, publique v=spf1 -all e v=DMARC1; p=reject.

Um exemplo real

Nosso próprio domínio publica v=DMARC1; p=none; rua=mailto:dmarc@promopilot.link e assina e-mails com o seletor DKIM mail usando uma chave de 2048 bits (verificado em outubro de 2026). Esse é um estágio normal de monitoramento: os relatórios são coletados e a política é endurecida quando todas as fontes forem confirmadas. Use o verificador de DMARC no seu próprio domínio para ver como ele está.