O pecado original

O (Simple Mail Transfer Protocol) não tem autenticação de remetente. Qualquer servidor pode afirmar que envia em nome de qualquer domínio, e o protocolo carrega aquilo sem reclamar. Tudo o que vem abaixo é remendo posterior.

O remendo é confuso por uma razão estrutural: uma mensagem tem dois endereços de origem. O remetente de envelope é o que o servidor emissor declara durante a conversa SMTP, e é para onde vão as devoluções. O cabeçalho From é o que o destinatário de fato vê no cliente de e-mail. Eles podem ser diferentes de forma legítima, com frequência são, e a distância entre os dois é exatamente onde mora a falsificação.

Guarde essa distinção e os três registros deixam de ser siglas intercambiáveis.

SPF — quais servidores podem enviar

O (Sender Policy Framework) é um registro DNS que lista os endereços autorizados a enviar e-mail por um domínio. O servidor receptor compara o endereço que conectou com a lista e obtém aprovação ou reprovação.

O que ele confere é o remetente de envelope, e não o From visível. Esse é o fato mais incompreendido da área: uma mensagem pode passar no SPF com nota máxima exibindo o From que bem entender.

Seus limites práticos merecem ser conhecidos antes de você depender dele. A avaliação é limitada a dez consultas DNS, e cada include: de um provedor grande consome várias, então registros inchados falham em silêncio em vez de falhar alto. E encaminhamento quebra: quando um destinatário encaminha a mensagem, o servidor que encaminha não está na sua lista, então o SPF reprova sem que ninguém tenha errado.

DKIM — a mensagem foi alterada, e por quem

O (DomainKeys Identified Mail) assina cabeçalhos selecionados e o corpo com uma chave privada; a chave pública fica no DNS. O receptor verifica a assinatura e aprende que um domínio específico assumiu responsabilidade pela mensagem e que as partes assinadas não foram modificadas em trânsito.

Como a assinatura viaja com a mensagem, o DKIM sobrevive a encaminhamento simples, que é onde o SPF falha. Ele também não diz nada, por si só, sobre o From visível — uma assinatura válida de um domínio pode acompanhar uma mensagem que exibe outro.

Duas observações operacionais: chaves precisam de rotação como qualquer material criptográfico, e a etiqueta opcional de comprimento de corpo permite que a assinatura cubra só o começo do corpo, o que deixa acrescentar conteúdo abaixo de uma assinatura válida. Não use.

DMARC — o que amarra tudo

O DMARC (Domain-based Message Authentication, Reporting and Conformance) acrescenta a peça que faltava: alinhamento. Ele exige que um resultado aprovado de SPF ou DKIM pertença ao mesmo domínio que o leitor vê no campo From. Essa é a proteção de verdade, e nem SPF nem DKIM a fornecem sozinhos.

Ele também faz duas coisas subestimadas:

Publica uma política — none, quarantine ou reject — dizendo aos receptores o que fazer com mensagens não alinhadas que reivindicam o seu domínio.

Pede relatórios. Relatórios agregados chegam dos receptores descrevendo o que passou e o que falhou pelo seu domínio, e de quais endereços. Essa é a parte que torna a implantação possível, e é inteligência gratuita sobre quem envia como você — inclusive seus próprios sistemas esquecidos e quem estiver forjando o seu nome.

Por que quase todo mundo empaca no p=none

O caminho honesto de implantação não é o que se recomenda numa frase só.

  1. Publique SPF e DKIM direito, e então o DMARC em p=none. Nada é bloqueado ainda.
  2. Leia os relatórios por semanas. Você vai encontrar remetentes legítimos que ninguém te contou: o sistema de faturamento, a plataforma de marketing, a ferramenta de chamados, o relay de uma filial.
  3. Corrija ou autorize cada um. Este é o trabalho real, é organizacional e não técnico, e é onde os projetos morrem.
  4. Vá para quarantine, depois reject, de preferência com implantação percentual.

Organizações ficam anos em p=none porque o passo 3 exige achar todo sistema que envia e-mail em nome da empresa, numa empresa em que ninguém tem essa lista. Publicar p=reject antes de terminar significa bloquear as próprias faturas.

O que quebra no mundo real

Encaminhamento quebra o SPF, como descrito. Listas de discussão com frequência quebram o DKIM também, porque alteram assuntos ou acrescentam rodapés, invalidando a assinatura.

O existe para isso: um intermediário registra os resultados de autenticação que viu e assina esse registro, para que um receptor posterior consiga ver que a mensagem só falhou porque passou por um encaminhador confiável. A adoção é parcial, e exige confiar na afirmação do intermediário.

Contra o que isso não protege

Esta é a parte que se vende demais, então vale dizer sem rodeio:

  • Domínios parecidos. DMARC em suaempresa.com não faz nada quanto a sua3mpresa.com. Os atacantes registram o próprio domínio e o autenticam com perfeição.
  • Falsificação de nome de exibição. Uma mensagem de um endereço qualquer exibindo o nome do seu presidente passa em tudo, porque nada aqui autentica um nome legível por humanos.
  • Contas legítimas comprometidas. E-mail enviado de uma caixa real e sequestrada é autêntico por toda medida que esses padrões aplicam.

O resumo exato: esses padrões impedem que outros enviem como o seu domínio. Eles não impedem que seus usuários caiam em phishing. Esse segundo problema exige outros controles, e confundir os dois é como organizações acabam acreditando que um projeto de autenticação as deixou seguras.

Vizinhos que costumam ser confundidos com estes

O MTA-STS e o DANE protegem o transporte — garantem que o e-mail para o seu domínio viaje sobre TLS verificado, em vez de ser rebaixado. Isso é confidencialidade e integridade em trânsito, problema diferente de autenticar o remetente. O BIMI exibe o logotipo da marca em clientes compatíveis e exige DMARC em aplicação, o que faz dele, na prática, um incentivo comercial para terminar o trabalho acima.

A lista curta

  • Um registro SPF só, abaixo do limite de consultas, sem +all.
  • Assinatura DKIM em todo sistema que envia, chaves com rotação, sem etiqueta de comprimento de corpo.
  • DMARC em p=none com endereço de relatório agregado, desde o primeiro dia.
  • Um dono nomeado para os relatórios, porque relatório não lido é igual a relatório nenhum.
  • Um inventário escrito de tudo que envia e-mail como você — o artefato de que o projeto inteiro realmente trata.
  • Aplicação quando, e somente quando, esse inventário estiver completo.