SPF, DKIM e DMARC na prática

SPF, DKIM e DMARC são três registros no DNS, e a maioria dos tutoriais para aí: publique e pronto. Não está pronto. O trabalho só termina quando uma mensagem real chega ao destino e o cabeçalho dela diz dmarc=pass.

Cada um responde a uma pergunta diferente. E só o terceiro olha para o endereço que o seu cliente vê.

SPF: quem pode enviar

O SPF é a lista dos servidores autorizados a mandar e-mail com um domínio. Mas qual domínio? O do envelope SMTP, o MAIL FROM, que quase ninguém vê e que muitas vezes pertence ao provedor de envio, não a você. A RFC 7208 é clara sobre isso. Os tutoriais, quase nunca.

v=spf1 include:_spf.provedor-a.example include:_spf.provedor-b.example -all

Duas regras derrubam mais SPF do que todo o resto junto:

• Um registro por nome. Dois TXT começando com v=spf1 no mesmo domínio é erro permanente. Cada serviço novo pede para "adicionar o SPF dele", e alguém cria um segundo registro em vez de juntar tudo no primeiro.
• Dez consultas, no máximo. Cada include gasta pelo menos uma, e os includes de provedores grandes costumam ter outros por dentro. O analisador de SPF faz a conta para você.

Termine com -all ou ~all. +all autoriza o planeta inteiro e não deveria existir em zona nenhuma.

DKIM: a assinatura

O serviço de envio assina cada mensagem com uma chave privada que só ele tem. A chave pública fica no seu DNS, num nome neste formato:

seletor._domainkey.seudominio.com.br

Quem escolhe o seletor é o provedor. Ele aparece no painel e no s= de toda assinatura. Não existe consulta que liste os seletores de um domínio, então "procurar o DKIM" sem saber o seletor é chute.

Alguns provedores pedem um TXT com a chave. Outros pedem um CNAME apontando para um nome deles, o que permite trocar a chave sem você tocar no DNS. Faça o que o painel da sua conta pedir, não o que um tutorial mostrou para a conta de outra pessoa.

A chave estar publicada não prova nada sobre as mensagens. Quem prova é o dkim=pass no cabeçalho de uma mensagem assinada. O mecanismo inteiro está na RFC 6376.

DMARC: amarrando tudo ao From

Aqui está o pulo do gato. O DMARC pega o domínio do From, o que o cliente vê, e exige que o SPF ou o DKIM tenham passado para esse domínio, ou para outro da mesma organização, como um subdomínio. Isso se chama alinhamento. SPF aprovado para o domínio do provedor não conta.

O registro mora em _dmarc e diz o que fazer com quem falha: p=none só observa, quarantine manda para o spam, reject recusa. A referência atual é a RFC 9989, de 2026, que substituiu a 7489 e aposentou tags antigas como pct. O gerador de DMARC já monta o registro no formato novo.

Comece em p=none com relatórios. Sempre. Quem publica reject no primeiro dia descobre que a nota fiscal saía por outro sistema quando o cliente liga reclamando.

A ordem que funciona

1. Liste tudo que manda e-mail com o seu domínio. Tudo mesmo: caixas da equipe, loja, ERP, cobrança, helpdesk, a ferramenta de newsletter que o marketing assinou e esqueceu.
2. Pegue os registros no painel de cada serviço. Não copie de exemplo de outra empresa.
3. Exporte a zona atual e publique um SPF só, com todos os includes, as chaves DKIM e o DMARC em p=none com rua.
4. Mande uma mensagem de cada sistema para uma conta de teste sua e cole os cabeçalhos no leitor.
5. Leia os relatórios por algumas semanas e corrija o que aparecer.
6. Suba para quarantine. Depois, reject.

Encaminhamentos e listas de discussão alteram mensagens e quebram assinaturas, então é normal ver falhas vindas deles nos relatórios. Isso não é motivo para afrouxar a política. É motivo para saber de onde elas vêm.

O DNS mostra o desenho, o cabeçalho mostra o resultado

A consulta DNS diz se os registros existem e se há duplicados. Ela não sabe se uma mensagem passou. Para isso, só o cabeçalho.

Os relatórios agregados (RFC 9990) chegam como XML, todo dia, de cada provedor grande. Se ninguém lê, é alarme sem ninguém em casa. Leia você, ou use um serviço que transforme aquilo em gráfico.