Como o sistema de correio chegou a precisar destes três é o assunto da linhagem do e-mail.

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: se 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 (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.

O DMARC apareceu primeiro em março de 2015 como (RFC) 7489, um documento informativo publicado pelo Independent Submissions Editor, fora de qualquer frente de trabalho da Internet Engineering Task Force. Desde maio de 2026 ele é um protocolo Standards Track, a RFC 9989, com os relatórios agregados na RFC 9990 e os de falha na RFC 9991, e as três tornam obsoleta a RFC 7489 (RFC 9989, apêndice C.1; RFC Editor, RFC 7489). Guias escritos antes disso descrevem o texto de 2015.

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. O formato deles é o que a RFC 9990 define, e o receptor só os envia quando o registro indica um endereço na tag rua (RFC 9989, seção 4.7). 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, um passo de cada vez, comparando os relatórios a cada passo.

A RFC 9989 põe números nessa paciência para todo domínio cujos usuários escrevem em listas de discussão: publicar p=none "for at least a month", por pelo menos um mês, depois p=quarantine por um período igual, e comparar os resultados antes de pensar em p=reject, que ela recomenda que esses domínios nem publiquem (RFC 9989, seção 7.4). Um domínio que publica p=reject "MUST apply valid DKIM signatures to their messages", precisa assinar as mensagens com DKIM válido, porque o encaminhamento quebra o SPF (seção 7.4). A implantação percentual que guias antigos recomendam acabou: a RFC 9989 removeu a tag pct, porque os receptores em geral só a aplicavam com precisão em 0 e 100, e guardou a metade útil dela na tag t, de testing, em que t=y pede ao receptor que aplique um nível abaixo da política publicada, none no lugar de quarantine e quarantine no lugar de reject (apêndices A.6 e C.5.2, seção 4.7).

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 (Authenticated Received Chain), descrito na RFC 8617, foi criado 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. Ele não vingou. A RFC 9989 registra que, depois de uma década de tentativas de fazer as listas funcionarem sem mexer na linha From, com o ARC como exemplo de destaque, "none of the methods have become widely used", nenhum dos métodos ganhou uso amplo (RFC 9989, seção 7.4), e o ARC ainda exige confiar na afirmação do intermediário. O que funciona na prática é o contorno: o software da lista reescreve a linha From, com o endereço da própria lista ou com uma forma reversível do endereço do autor, para que ela fique alinhada, e a RFC 9989 chama esses contornos de "firmly established", consolidados (seção 7.4).

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 -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.

Fontes