Resumo

  • O DMARC produz pass quando pelo menos um domínio autenticado por SPF ou DKIM está alinhado ao domínio de RFC5322.From. Isso valida o uso autorizado do domínio autor, não a parte local, o nome exibido, a pessoa ou o conteúdo.
  • Fail não é a condenação inversa. Encaminhadores e listas legítimos podem quebrar o alinhamento de SPF ou invalidar uma assinatura DKIM antes da chegada.
  • p, sp e np são preferências de tratamento solicitadas por DNS. O receptor mantém a política local, pode rejeitar uma mensagem aprovada ou aceitar uma reprovada e deve usar outras evidências de reputação, conteúdo e abuso.

O recibo começa no domínio, não na pessoa

Uma mensagem reúne elementos que a interface costuma mostrar como uma identidade única: nome visível, endereço, domínio, assinatura, servidor de envio e conteúdo. A RFC 9989 recusa essa fusão. O objeto de seu resultado é o uso do Author Domain em RFC5322.From.

Publicado em maio de 2026 no Standards Track, o documento substitui as RFCs 7489 e 9091. Todd M. Herr e John Levine aparecem como coeditores. Logo na introdução, o texto afirma que um pass indica somente que o uso do Author Domain foi validado como autorizado pelo Domain Owner. A autorização não carrega avaliação explícita ou implícita da mensagem ou do proprietário e não garante que a entrega na caixa de entrada seja segura ou desejável.

Não se trata de diminuir o protocolo. Trata-se de conservar a unidade que ele consegue provar. Uma investigação que precisa de uma conclusão maior deve registrar qual outra fonte a produziu.

O cálculo que aproxima identidades diferentes

SPF autoriza hosts a usar um domínio no MAIL FROM ou HELO de uma transação SMTP; para DMARC, interessa o MAIL FROM. DKIM valida uma assinatura e identifica o domínio d= que assumiu responsabilidade pelos campos cobertos. Nenhum dos dois, isoladamente, exige relação com o From percebido pelo usuário.

DMARC extrai o Author Domain de RFC5322.From e aplica alinhamento. No modo estrito, o domínio autenticado e o Author Domain são idênticos. No modo relaxado, compartilham o mesmo Organizational Domain. O Domain Owner seleciona os modos em aspf e adkim; a RFC observa que quase todos os proprietários consideram o modo relaxado suficiente.

Um único identificador autenticado e alinhado basta. Entre várias assinaturas DKIM, uma pode fornecer o resultado mesmo se outra falhar. Um SPF aprovado para o domínio de um encaminhador não produz alinhamento com o domínio autor original. Por isso o recibo completo precisa indicar mecanismo, domínio, modo, horário e observador.

O que o recibo não diz permanece grande. Ele não diz quem digitou a mensagem, quem controla a conta, o que significa o nome visível nem por que o destinatário deveria confiar no conteúdo.

A parte local e a aparência continuam sem prova

Em um endereço que combina a parte local diretoria com o domínio example.com, o DMARC trabalha com example.com. Não autentica diretoria, a existência da caixa, o ocupante do cargo nem um indivíduo. A RFC 9989 declara que os mecanismos usados não validam a parte local de endereços.

O nome legível por humanos também pode ser escolhido por quem compõe a mensagem. Um atacante pode escrever o nome de uma executiva real diante de um endereço não relacionado. Pode registrar um domínio visualmente semelhante, acrescentar uma palavra convincente e configurar SPF, DKIM e DMARC corretamente. A especificação exclui ataques ao display name e domínios parecidos de sua solução direta.

Análise de conteúdo é outra tarefa fora de escopo. Um serviço legítimo comprometido pode distribuir malware com domínio autorizado. Um usuário interno pode enviar fraude. Um atacante pode passar perfeitamente em seu próprio domínio. Links, anexos, dados bancários, intenção e adequação ao destinatário pertencem a filtros, reputação, autenticação de conta e controles de negócio.

Se uma mensagem maliciosa passa, a pergunta correta não é automaticamente “por que DMARC falhou?”. Talvez DMARC tenha acertado e outra barreira tenha faltado. A linguagem exata impede a equipe de corrigir o componente errado.

Quando a viagem destrói a evidência

A RFC 7960 descreve fluxos indiretos. Se um encaminhador preserva o MAIL FROM original, o novo IP pode não constar no SPF do domínio. Se substitui o MAIL FROM por seu próprio domínio, SPF pode passar, mas o alinhamento com RFC5322.From desaparece.

Listas de discussão alteram assunto, rodapé, MIME ou outras partes para prestar seu serviço. Essas transformações podem invalidar a assinatura DKIM original. Uma mensagem legítima sai com assinatura e autorização, atravessa um mediador legítimo e chega sem nenhum identificador ainda válido e alinhado.

Por isso a RFC 9989 escolhe dizer que um fail não está “necessariamente associado” ao Author Domain. O resultado descreve o material verificável que sobrou no ponto final. Não reconstrói toda a cadeia nem declara fraude.

A política operacional precisa conhecer esses caminhos. Caso contrário, dois erros opostos se tornam automáticos: confiar em conteúdo perigoso porque o domínio passou e eliminar conteúdo legítimo porque a prova não sobreviveu ao trajeto.

A publicação remota para na porta do receptor

A descoberta procura registro primeiro no Author Domain, depois em seu Organizational Domain e, por fim, no Public Suffix Domain. A origem do registro e a existência do subdomínio determinam o uso de p, sp ou np. O cadastro da IANA chama essas etiquetas de políticas solicitadas; também mostra pct, rf e ri como históricos.

O pedido não ganha acesso à fila. A RFC 9989 deixa o tratamento final sempre sob política local do Mail Receiver. Um pass pode ser rejeitado ou isolado por reputação e conteúdo. Um fail pode ser aceito mesmo diante de p=reject. O texto recomenda que o receptor não rejeite apenas por causa da política publicada, sobretudo quando conhecimento adicional evita dano a mensagens legítimas e listas.

Erros de DNS tornam essa divisão incontornável. Se consultas necessárias não terminam, não há pass ou fail; a política do domínio não pode ser aplicada como se tivesse sido lida. Entregar, adiar ou usar outro procedimento é decisão local.

Em The Policy Mirror, Heng Lu submete regras comuns a um teste de escopo: elas preservam o mínimo necessário para coordenação ou capturam escolhas que deveriam permanecer com quem suporta o risco? A RFC tem sua própria autoridade, mas a disciplina ajuda a ler o desenho. O Domain Owner torna o pedido verificável. O receptor não terceiriza o controle.

Relatórios pedidos não formam um censo

O registro pode usar rua para solicitar agregados e ruf para solicitar informações por falha. Os agregados ajudam a encontrar tanto falsificação quanto falhas da própria configuração legítima. Contudo, o Mail Receiver não é obrigado a enviar tudo. A RFC recomenda agregados; relatórios por mensagem são opcionais e muitas vezes reduzidos por privacidade.

Logo, o URI publicado prova intenção de receber. Um relatório recebido prova uma observação de um receptor por um período. Não prova cobertura universal, execução de reject nem destino final de cada mensagem.

Antes de subir de monitoramento para quarentena ou rejeição, o proprietário deve inventariar fontes, testar encaminhamento e listas, medir cobertura, observar subdomínios e preparar reversão. A etiqueta t, o histórico de DNS e as decisões de mudança fazem parte da evidência operacional.

A contribuição de Todd Herr dentro de uma autoria distribuída

Na captura de 1º de setembro de 2026, o Datatracker da IETF associa Todd Herr à RFC 9989 e à função de revisor da ART Area Review Team. O retrato público estabelece sua identidade visual. A RFC registra Herr com a Valimail e John Levine com a Standcore LLC. Os agradecimentos preservam o trabalho do grupo DMARC e dos participantes da especificação anterior.

O perfil pode reconhecer uma realização editorial: o documento repete os limites quando seria fácil vender o resultado como selo geral. Não pode transformar Herr em inventor único, validador de todos os domínios, operador de receptores ou dono da política local. A arquitetura depende de essas funções continuarem separadas.

Uma cadeia em que nenhuma linha herda a próxima

O registro auditável inclui a mensagem recebida e o From; todos os resultados SPF e DKIM com domínios, seletores e motivos; o alinhamento aplicado; o caminho DNS e a etiqueta efetiva; erros de consulta; transformações indiretas conhecidas; sinais locais de reputação e conteúdo; disposição; resultado ao usuário; e relatórios realmente enviados e recebidos.

O domínio autorizado não herda a identidade da pessoa. O alinhamento não herda a verdade do texto. O pass não herda segurança. A preferência remota não herda execução. Aceitação SMTP não herda caixa de entrada. Caixa de entrada não herda ausência de dano.

Dentro de seu limite, DMARC continua decisivo. Reduz falsificação exata, fornece uma unidade estável para reputação e devolve informação sobre fluxos. O protocolo não precisa dominar toda a mensagem para produzir um recibo confiável.

Fontes