SPF, DKIM e DMARC: guia de configuração e alinhamento

SPF, DKIM e DMARC são três padrões publicados no DNS que permitem ao servidor de destino verificar se uma mensagem realmente vem do domínio que diz vir. O SPF (RFC 7208) lista os servidores autorizados a enviar pelo domínio, o DKIM (RFC 6376) assina cada mensagem criptograficamente e o DMARC (RFC 7489) amarra os dois ao endereço visível no From por meio do alinhamento, dizendo ao provedor o que fazer quando a verificação falha. Desde fevereiro de 2024, as diretrizes do Google e do Yahoo exigem os três para remetentes em massa.

Como cada protocolo funciona

SPF: quem pode enviar por este domínio

O SPF verifica o remetente do envelope, ou seja, o endereço do comando MAIL FROM na transação SMTP, que depois aparece no header Return-Path. Ele não olha o From que o usuário vê. O servidor de destino consulta um registro TXT no domínio do envelope e confere se o IP que está conectando está autorizado.

bounces.example.com.br.  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.example.com -all"

Pontos que mais causam problema:

• Um único registro SPF por nome. Dois TXT começando com v=spf1 no mesmo nome resultam em permerror.
• Limite de 10 consultas DNS. Cada include, a, mx, ptr, exists e redirect conta. Os include aninhados também contam. Estourou, é falha.
• -all vs ~all. O -all (fail) diz que tudo fora da lista é ilegítimo; o ~all (softfail) é mais brando. Com DMARC em vigor, o resultado do DMARC pesa mais, mas um -all bem mantido é o sinal mais claro.
• SPF quebra no encaminhamento. Quando alguém encaminha o email de contato@empresa.example.com.br para o Gmail pessoal, quem entrega é o servidor intermediário, cujo IP não está no seu SPF.

DKIM: a assinatura que viaja com a mensagem

O DKIM adiciona um header DKIM-Signature com a assinatura de alguns headers e do corpo. A chave pública fica no DNS, em <seletor>._domainkey.<domínio>.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com.br;
 s=pid2026; h=from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post;
 bh=...; b=...

pid2026._domainkey.example.com.br.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

O que importa aqui:

• O d= é o domínio que "assina" e é ele que conta para o alinhamento do DMARC.
• O s= é o seletor. Usar seletores diferentes permite rotacionar chaves sem interromper o envio: publique a nova chave, troque o seletor no envio e só remova a antiga depois de alguns dias.
• Use RSA de 2048 bits. Registros TXT maiores que 255 caracteres precisam ser divididos em várias strings no mesmo registro; a maioria dos painéis de DNS faz isso automaticamente.
• Inclua no h= os headers que você não quer que sejam adulterados, como From, Subject, List-Unsubscribe e List-Unsubscribe-Post.

DMARC: a política que liga tudo ao From

O DMARC é publicado em _dmarc.<domínio> e faz duas coisas: exige alinhamento e define a política para falhas.

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

O que é alinhamento, na prática

Alinhamento é a regra que impede um golpista de passar no SPF com o próprio domínio e colocar o seu no From. Para o DMARC passar, pelo menos um dos dois precisa acontecer:

1. O SPF passa e o domínio do Return-Path é o mesmo (ou, no modo relaxado, compartilha o domínio organizacional) do From.
2. O DKIM passa e o d= da assinatura é o mesmo (ou, no modo relaxado, do mesmo domínio organizacional) do From.

Exemplo de mensagem bem alinhada:

From: Loja Exemplo <pedidos@example.com.br>
Return-Path: <b+a1f9c3@bounces.example.com.br>
DKIM-Signature: ... d=example.com.br; s=pid2026; ...

• SPF: verificado em bounces.example.com.br. Com aspf=r, alinha com example.com.br.
• DKIM: d=example.com.br, idêntico ao From. Alinhado em qualquer modo.

Exemplo do erro clássico ao usar um provedor de envio sem configurar o domínio:

From: pedidos@example.com.br
Return-Path: <bounce-123@mailer.provedor.example>
DKIM-Signature: ... d=provedor.example; ...

SPF e DKIM passam, mas nenhum alinha com example.com.br. Resultado: DMARC falha. É por isso que um subdomínio de return-path próprio e DKIM no seu domínio são indispensáveis.

Configuração passo a passo

1. Faça o inventário de quem envia em seu nome

Liste tudo: aplicação (transacional), ferramenta de marketing, CRM, helpdesk, sistema de notas fiscais, Google Workspace ou Microsoft 365. Cada fonte precisa passar alinhada. Fontes esquecidas são a causa número um de DMARC quebrado.

2. Configure o subdomínio de return-path e o SPF

Crie um subdomínio dedicado aos bounces, como bounces.example.com.br, com o seu próprio SPF e um MX para receber as notificações de devolução:

bounces.example.com.br.  MX   10 mx.bounces.example.com.br.
bounces.example.com.br.  TXT  "v=spf1 ip4:203.0.113.0/24 -all"

Separar o return-path em um subdomínio mantém o SPF do domínio raiz enxuto e longe do limite de 10 consultas.

3. Publique as chaves DKIM

Gere um par de chaves de 2048 bits por domínio de envio, publique a pública com um seletor e verifique:

dig +short TXT pid2026._domainkey.example.com.br

4. Publique o DMARC em modo de monitoramento

Comece com p=none e rua. Os relatórios agregados chegam em XML, geralmente uma vez por dia por provedor, mostrando cada IP que enviou com o seu domínio e o resultado de SPF, DKIM e alinhamento. Use um processador de relatórios para não ler XML na mão.

5. Corrija e endureça

Quando os relatórios mostrarem que todas as fontes legítimas passam alinhadas por algumas semanas, avance:

1. p=quarantine; pct=25, depois pct=100.
2. p=reject.

Para remetentes em massa, as diretrizes do Google e do Yahoo exigem DMARC publicado com pelo menos p=none. A política mais forte não é obrigatória, mas protege a sua marca contra phishing.

Erros comuns

• Dois registros SPF no mesmo nome, geralmente depois de contratar uma ferramenta nova.
• include demais no domínio raiz, estourando as 10 consultas. Prefira subdomínios por fonte de envio.
• DKIM assinado com o domínio do fornecedor (d=fornecedor.example), o que nunca alinha.
• Pular direto para p=reject e bloquear o envio de notas fiscais ou do helpdesk que ninguém lembrou de configurar.
• Esquecer o sp=: sem ele, subdomínios herdam a política do domínio principal, o que pode ser bom ou péssimo dependendo do seu inventário.
• Copiar o registro com aspas extras ou quebra de linha do painel de DNS, invalidando a chave.

Checklist rápido

• [ ] Um único TXT v=spf1 por nome, com menos de 10 consultas.
• [ ] Return-Path em subdomínio próprio, com SPF e MX.
• [ ] DKIM de 2048 bits com d= no seu domínio, seletor documentado.
• [ ] _dmarc publicado com rua e plano de evolução da política.
• [ ] Todas as fontes de envio verificadas nos relatórios agregados.
• [ ] Teste real: envie para uma caixa do Gmail e confira "Mostrar original" (SPF, DKIM e DMARC devem aparecer como PASS).

Como a Pidgely cuida disso

Na Pidgely, cada domínio verificado recebe sua própria chave DKIM e um subdomínio de return-path com SPF alinhado. O painel mostra exatamente quais registros publicar e confere se estão corretos antes de liberar o envio, para que o alinhamento seja o padrão e não algo a lembrar depois.