SPF, DKIM e DMARC: Autenticação de E-mail Explicada de Vez

# SPF, DKIM e DMARC: Autenticação de E-mail Explicada de Vez

O e-mail nasceu sem qualquer noção de identidade. O protocolo SMTP, projetado nos anos 1980 para uma internet de universidades que confiavam umas nas outras, permite que qualquer servidor afirme enviar mensagens em nome de qualquer domínio. Não há checagem embutida. Se eu quiser mandar um e-mail que diz vir de contato@seubanco.com.br, o SMTP não vai me impedir. Essa lacuna é a mãe do spoofing e de boa parte do phishing que você recebe todo dia.

SPF, DKIM e DMARC são as três camadas que a indústria construiu, ao longo de duas décadas, para tapar esse buraco. Elas não mudam o SMTP: são registros publicados no DNS do seu domínio que permitem ao servidor receptor perguntar "esse remetente está mesmo autorizado a falar por este domínio?" e agir conforme a resposta. Este guia destrincha cada uma, na ordem em que fazem sentido, e mostra os erros que derrubam campanhas inteiras.

Por que autenticação de e-mail existe#

Imagine um envelope de correio físico. O remetente escrito no verso pode ser qualquer coisa — ninguém confere. O e-mail funciona igual, e pior: existem dois "remetentes" diferentes na mesma mensagem.

• O envelope-from (também chamado MAIL FROM ou Return-Path) é o endereço usado na negociação SMTP entre servidores. O destinatário humano quase nunca o vê.
• O From de cabeçalho (From:) é o que aparece no cliente de e-mail — o nome e endereço que você lê na caixa de entrada.

Um atacante pode preencher os dois com valores diferentes. É exatamente por isso que precisamos de mais de um protocolo: cada um cobre um ângulo, e o DMARC amarra tudo ao endereço que o usuário realmente enxerga. Sem autenticação, provedores como Gmail, Outlook e Yahoo não têm como distinguir sua campanha legítima de uma fraude que finge ser você. O resultado é caixa de spam, ou pior, um golpe bem-sucedido usando sua marca.

SPF: quem tem permissão de enviar#

O SPF (Sender Policy Framework) responde a uma pergunta simples: este servidor tem permissão para enviar e-mail em nome deste domínio? Você publica, no DNS, uma lista de servidores autorizados. Quando um e-mail chega, o receptor compara o IP de origem com essa lista.

O SPF é um registro TXT publicado na raiz do domínio. Um exemplo real:

``dns exemplo.com.br. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all" ``

Lendo os mecanismos da esquerda para a direita:

• v=spf1 — declara que é um registro SPF.
• include:_spf.google.com — autoriza os servidores do Google Workspace (delega a checagem ao registro SPF deles).
• include:sendgrid.net — autoriza o seu ESP, neste caso o SendGrid.
• ip4:203.0.113.10 — autoriza um IP específico (seu servidor próprio, por exemplo).
• -all — fecha a lista: qualquer outro servidor falha o SPF. O hífen significa "hard fail". Um ~all (til) seria "soft fail", uma rejeição mais branda, útil só na fase de testes.

O limite dos 10 lookups de DNS#

Aqui está a pegadinha que quebra SPF de gente experiente: a especificação (RFC 7208) impõe um teto de 10 consultas DNS para avaliar um registro. Cada include, a, mx, ptr e exists conta. Um único include:_spf.google.com pode, internamente, disparar várias consultas aninhadas.

Se você estourar os 10 lookups, o SPF retorna permerror e é tratado como falha — mesmo com tudo "certo" na aparência. Empresas que usam cinco ou seis ferramentas de e-mail (CRM, faturamento, marketing, suporte) batem nesse teto com facilidade. A solução é o SPF flattening (achatar os includes em IPs diretos, com automação que atualize quando os IPs mudarem) ou consolidar o envio em menos plataformas.

Pergunta: posso ter mais de um registro SPF no meu domínio? Não. Um domínio pode ter apenas um registro TXT começando com v=spf1. Se houver dois, o resultado é permerror e o SPF é ignorado por completo. Este é um dos erros mais comuns: a empresa adiciona um SPF para o Google, depois outro para o novo ESP, e sem querer publica dois registros separados. O correto é mesclar tudo em uma linha só, com múltiplos include.

DKIM: a assinatura criptográfica#

O SPF valida o servidor de origem, mas não protege o conteúdo e quebra em encaminhamentos (o IP muda quando alguém redireciona a mensagem). O DKIM (DomainKeys Identified Mail) resolve isso com criptografia de chave pública.

Funciona assim: seu servidor de envio assina cada mensagem com uma chave privada. Essa assinatura vai em um cabeçalho chamado DKIM-Signature. A chave pública correspondente fica publicada no seu DNS. O receptor busca a chave pública, recalcula o hash da mensagem e confere se a assinatura bate. Se bater, duas coisas ficam provadas: a mensagem realmente veio de quem tem a chave privada, e o conteúdo assinado não foi alterado no caminho.

A chave pública é publicada em um subdomínio específico chamado seletor. O seletor permite que você tenha várias chaves ativas ao mesmo tempo (útil para rotação):

``dns s1._domainkey.exemplo.com.br. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7..." ``

O s1 é o seletor; _domainkey é o namespace fixo; e p= carrega a chave pública. O cabeçalho DKIM-Signature de cada e-mail aponta para qual domínio (d=) e qual seletor (s=) usar na verificação.

O que exatamente é assinado? O corpo da mensagem e um conjunto de cabeçalhos que você escolhe — tipicamente From, Subject, Date, To. A tag bh= guarda o hash do corpo e a tag h= lista quais cabeçalhos entraram na assinatura. Cabeçalhos fora dessa lista podem ser adicionados por um servidor intermediário sem invalidar a assinatura, o que dá ao DKIM uma resiliência que o SPF não tem.

Na prática, quase todo ESP moderno gera o par de chaves para você e entrega os registros DKIM prontos para colar no DNS. O erro clássico aqui é não configurar o DKIM no ESP — deixar no default do provedor, que assina com o domínio dele, não com o seu. Isso quebra o alinhamento do DMARC, como veremos a seguir.

DMARC: alinhamento, política e relatórios#

SPF e DKIM, isolados, têm uma falha grave: eles validam o envelope-from e o d= da assinatura, mas nada obriga esses valores a baterem com o From: que o usuário vê. Um golpista pode passar no SPF com o domínio dele e ainda estampar seubanco.com.br no cabeçalho visível.

O DMARC (Domain-based Message Authentication, Reporting and Conformance) fecha essa brecha exigindo alinhamento: o domínio que passou no SPF ou no DKIM precisa casar com o domínio do From: visível. Só então a mensagem é considerada autêntica.

• Alinhamento SPF: o domínio do envelope-from bate com o domínio do From:.
• Alinhamento DKIM: o d= da assinatura DKIM bate com o domínio do From:.

O DMARC exige que pelo menos um dos dois esteja alinhado e válido. Cada um pode operar em modo relaxed (basta o mesmo domínio organizacional, subdomínios servem) ou strict (o domínio precisa ser idêntico).

O registro fica em _dmarc.seudominio:

``dns _dmarc.exemplo.com.br. IN TXT "v=DMARC1; p=none; rua=mailto:relatorios@exemplo.com.br; ruf=mailto:forense@exemplo.com.br; fo=1; pct=100" ``

As políticas (p=) definem o que o receptor faz com mensagens que falham o DMARC:

• p=none — não faz nada, só observa e reporta. É o ponto de partida.
• p=quarantine — manda para o spam/quarentena.
• p=reject — rejeita a mensagem antes mesmo da entrega. É o objetivo final.

Os relatórios: RUA e RUF#

O "R" de reporting é o que torna o DMARC operável. Dois tipos de relatório:

• RUA (agregado): resumos periódicos, em XML, enviados pelos receptores. Dizem quantas mensagens passaram, quantas falharam, de quais IPs, e qual mecanismo (SPF/DKIM) alinhou. É o seu radar. Ferramentas de análise transformam esse XML em painéis legíveis.
• RUF (forense): cópias detalhadas de mensagens individuais que falharam. Úteis para investigação, mas raros na prática — a maioria dos grandes provedores não envia RUF por preocupação com privacidade e dados pessoais.

Pergunta: por que não começar direto no p=reject? Porque você quase certamente tem fontes de envio legítimas que ainda não estão autenticadas — a ferramenta de nota fiscal, o sistema de RH, um formulário do site. Ir direto ao reject faz esses e-mails legítimos serem rejeitados silenciosamente, e você só descobre quando um cliente reclama que não recebeu a fatura. O caminho certo é começar em p=none, ler os relatórios RUA por algumas semanas até enxergar todas as suas fontes, autenticar cada uma, e só então subir para quarantine e depois reject. Use pct= para aplicar a política a uma fração do tráfego durante a transição. Essa evolução gradual é parte central de qualquer estratégia séria de entregabilidade de e-mail.

Alinhamento de domínio na prática: From visível vs envelope#

O ponto que confunde mais gente: existem três domínios em jogo numa mensagem, e o DMARC só se importa com um deles ser respeitado.

1. O envelope-from — usado pelo SPF.
2. O d= do DKIM — o domínio que assinou.
3. O From: visível — o que aparece na caixa de entrada.

Quando você usa um ESP, é comum que o envelope-from aponte para um subdomínio do próprio ESP (algo como bounces.sendgrid.net). Nesse caso, o SPF passa, mas não alinha com o seu From:. É por isso que o DKIM costuma ser o herói do DMARC em envios via ESP: se o ESP assina com d=exemplo.com.br (usando as chaves que você configurou), o DKIM alinha e o DMARC passa, mesmo com o SPF desalinhado.

Muitos ESPs oferecem configurar um domínio de retorno personalizado (custom return-path / custom MAIL FROM), o que também alinha o SPF. Vale ativar: quanto mais mecanismos alinhados, mais robusta a autenticação.

Domínios de envio dedicados e subdomínios#

Uma decisão estratégica que impacta reputação: não envie tudo pelo domínio raiz. A prática recomendada é segmentar por subdomínio de envio:

• noticias.exemplo.com.br para newsletter e marketing.
• avisos.exemplo.com.br para transacionais (recibos, redefinição de senha).
• O domínio raiz exemplo.com.br para e-mail corporativo humano.

A vantagem é o isolamento de reputação. Se uma campanha de marketing gerar reclamações de spam, o estrago fica contido no subdomínio de marketing e não contamina os e-mails transacionais críticos nem a correspondência da equipe. Cada subdomínio tem seus próprios SPF, DKIM e pode ter política DMARC própria — inclusive um DMARC no domínio organizacional com a tag sp= para definir a política dos subdomínios.

BIMI: a camada visível seguinte#

Com o DMARC em quarantine ou reject, você desbloqueia o BIMI (Brand Indicators for Message Identification). É a camada mais nova e a única que o usuário final vê: ela exibe o logotipo da sua marca ao lado do e-mail na caixa de entrada.

O BIMI publica, no DNS, a URL de um logo em formato SVG específico. Provedores como Gmail e Apple Mail exibem esse logo — mas só se o DMARC estiver em política de enforcement (nada de p=none) e, para máxima cobertura, com um certificado VMC (Verified Mark Certificate) que comprova a titularidade da marca. BIMI não é autenticação em si; é o prêmio de reputação por ter feito o dever de casa com DMARC. Trate-o como etapa final, não como prioridade inicial.

Os erros que mais derrubam envios#

Reunindo as armadilhas espalhadas pelo texto, mais algumas frequentes:

• Dois registros SPF — resultado é permerror e SPF ignorado. Sempre mescle em uma linha.
• Estourar os 10 lookups de DNS do SPF — falha silenciosa; use flattening ou reduza ferramentas.
• DKIM não configurado no ESP — o ESP assina com o domínio dele, o DKIM não alinha, e o DMARC não passa via DKIM.
• DMARC em reject cedo demais — e-mails legítimos rejeitados antes de você mapear todas as fontes. Comece em none.
• Esquecer subdomínios — sem política sp=, um subdomínio sem registro pode ser abusado.
• Não ler os relatórios RUA — publicar o DMARC e nunca olhar o XML é dirigir de olhos fechados.
• Chave DKIM fraca ou nunca rotacionada — prefira chaves RSA de 2048 bits e planeje rotação usando seletores distintos.

Fechando o ciclo#

A ordem lógica de implantação é sempre a mesma: publique o SPF com todas as fontes de envio; ative o DKIM em cada plataforma, garantindo que assine com o seu domínio; então publique o DMARC em p=none e leia os relatórios até ter certeza de que todo o seu tráfego legítimo está alinhado. Só depois evolua para quarantine, reject e, por fim, adote o BIMI.

Autenticação de e-mail não é um projeto de configurar-e-esquecer. Fontes de envio surgem, IPs mudam, ferramentas entram e saem. Os relatórios agregados do DMARC são o mecanismo que mantém você informado. Feito com método, esse tripé transforma seu domínio de um alvo fácil de falsificação em uma identidade que os provedores confiam — e confiança, no mundo do e-mail, é o que separa a caixa de entrada da caixa de spam.