Após anos de trabalho dentro do grupo de trabalho DMARC do IETF, a tão aguardada atualização do padrão DMARC foi publicada. Três novos documentos, RFC 9989, RFC 9990 e RFC 9991, agora substituem formalmente a RFC 7489 original de 2015. Juntos, eles são comumente chamados de DMARCbis.
As novas especificações foram publicadas em maio de 2026 e moveram o DMARC de seu status anterior de Informativo para um Padrão Proposto na Trilha de Padrões do IETF. Isso confere ao DMARC um lugar mais forte e formal na pilha de padrões da Internet.
I. O Que Cada RFC Cobre
A especificação DMARC foi dividida em três documentos focados em vez de um único arquivo grande:
- RFC 9989: Define o protocolo DMARC principal, incluindo avaliação de política, alinhamento de identificadores, processamento de registros e procedimentos de DNS Tree Walk.
- RFC 9990: Define relatórios agregados DMARC, também conhecidos como relatórios RUA.
- RFC 9991: Define relatórios de falha DMARC, às vezes chamados de relatórios forenses, que podem fornecer detalhes em nível de mensagem sobre falhas de autenticação quando suportados pelos sistemas receptores.
Essa divisão torna o padrão mais fácil de implementar, manter e referenciar.
II. Seu Registro DMARC Existente Ainda Funciona
Esta não é uma mudança disruptiva para proprietários de domínio.
Os registros DMARC ainda começam com:
v=DMARC1
Você não precisa reconstruir sua implementação DMARC ou republicar todos os registros imediatamente. Os registros existentes permanecem válidos, mas a atualização é um bom motivo para revisar sua configuração, remover comportamentos desatualizados e confirmar que sua plataforma de monitoramento suporta as novas especificações.
III. Principais Mudanças Técnicas
Várias mudanças são importantes para equipes de segurança, administradores DNS e plataformas de autenticação de e-mail.
DNS Tree Walk Substitui Dependência da Lista de Sufixos Públicos
O DMARCbis substitui a dependência da Lista de Sufixos Públicos mantida externamente para descoberta de domínio organizacional por procedimentos de DNS Tree Walk.
Os receptores agora podem navegar pela hierarquia DNS e procurar registros _dmarc relevantes em cada nível. Isso reduz a dependência de uma lista de terceiros e melhora o tratamento para estruturas de domínio complexas, domínios delegados e operadores de domínio de sufixo público.
Novas Tags: np, psd e t
A RFC 9989 atualiza o registro de tags DMARC e introduz suporte ativo para:
np: política para subdomínios inexistentes.psd: tratamento de domínio de sufixo público.t: flag de teste, comt=ypara teste et=npara operação normal.
A tag np é especialmente importante para organizações com domínios grandes ou complexos, pois ajuda a lidar com tentativas de spoofing contra subdomínios inexistentes.
Tags Históricas: pct, rf e ri
A RFC 9989 marca várias tags antigas como históricas:
pctrfri
A tag pct foi originalmente destinada a suportar implementação parcial de política, mas a implementação foi inconsistente entre receptores. O DMARCbis substitui essa abordagem por comportamento de teste mais claro através da tag t.
As organizações devem revisar registros DMARC existentes para tags históricas e planejar limpeza quando apropriado.
Orientação Mais Clara para Encaminhamento e Listas de E-mail
Fluxos de e-mail indiretos, como encaminhamento e listas de e-mail, continuam difíceis para o DMARC porque o alinhamento SPF ou DKIM pode falhar mesmo quando a mensagem é legítima.
O DMARCbis fornece orientação mais explícita sobre esses cenários do mundo real. Isso é importante porque muitas falhas de produção não são causadas por e-mails maliciosos, mas por e-mails legítimos passando por sistemas que alteram roteamento, cabeçalhos ou contexto de autenticação.
Conformidade Melhor Definida
As especificações atualizadas fornecem definições mais claras para participação DMARC e comportamento de implementação.
Isso deve ajudar a reduzir interpretações inconsistentes entre remetentes, receptores e fornecedores. Para organizações, também fica mais fácil perguntar se uma ferramenta ou provedor está realmente alinhado com o padrão DMARC atual.
IV. RFC 9989: Protocolo DMARC Principal
A RFC 9989 substitui a RFC 7489 como a especificação DMARC primária.
Ela define o protocolo principal, incluindo:
- Descoberta de política DMARC.
- Processamento de registros.
- Alinhamento de identificadores.
- Avaliação de política.
- Comportamento de DNS Tree Walk.
- Tratamento de tags atualizado.
- Expectativas de conformidade.
Descoberta e Herança de Política
A RFC 9989 esclarece como funciona a descoberta de política DMARC através de hierarquias de domínio.
Isso é importante para organizações com muitos subdomínios, domínios delegados ou domínios regionais. Sem descoberta clara de política, as equipes podem acreditar que um domínio está protegido quando um receptor não descobre ou aplica a política esperada.
Alinhamento de Identificadores
O DMARC ainda depende do alinhamento de identificadores.
Uma mensagem passa no DMARC apenas quando pelo menos uma das seguintes condições é verdadeira:
- SPF passa e o domínio autenticado SPF se alinha com o domínio From visível.
- DKIM passa e o domínio de assinatura DKIM se alinha com o domínio From visível.
SPF passando sozinho não significa que DMARC passou. DKIM passando sozinho não significa que DMARC passou. O alinhamento é o que vincula a autenticação de volta ao domínio que o destinatário vê.
DNS Tree Walk
O DNS Tree Walk é uma das mudanças operacionais mais importantes na RFC 9989.
Em vez de confiar na Lista de Sufixos Públicos para determinar o domínio organizacional, os receptores usam consultas DNS através da hierarquia de domínio para descobrir a política DMARC aplicável.
Isso melhora a capacidade do padrão de lidar com modelos complexos de delegação e cenários de domínio de sufixo público.
V. RFC 9990: Relatórios Agregados
A RFC 9990 define o formato de relatórios agregados DMARC.
Os relatórios agregados dão aos proprietários de domínio visibilidade sobre como seu domínio está sendo usado em todo o ecossistema de e-mail. Esses relatórios geralmente incluem:
- Endereços IP de origem.
- Resultados de autenticação.
- Resultados de alinhamento.
- Disposição de política.
- Volume de envio.
- Organização relatora.
A RFC dedicada a relatórios agregados deve melhorar a consistência entre implementações e facilitar a interpretação do comportamento de relatórios para fornecedores e proprietários de domínio.
Para equipes de segurança, os relatórios agregados continuam sendo uma das formas mais úteis de descobrir remetentes legítimos, identificar fontes não autorizadas e monitorar o progresso de aplicação do DMARC.
VI. RFC 9991: Relatórios de Falha
A RFC 9991 define relatórios de falha DMARC como uma especificação dedicada na Trilha de Padrões.
Os relatórios de falha podem fornecer detalhes em nível de mensagem sobre falhas de autenticação, dependendo da implementação do receptor e controles de privacidade.
Esses relatórios podem ser úteis para solução de problemas e investigação de ameaças, mas devem ser tratados com cuidado. Relatórios de falha podem conter metadados sensíveis e, dependendo da implementação, podem incluir cabeçalhos de mensagem ou elementos de conteúdo. As organizações devem considerar privacidade, volume, retenção e controles de acesso antes de habilitar ou confiar em relatórios de falha.
Nem todos os receptores enviam relatórios de falha. As equipes de segurança devem tratá-los como um sinal suplementar, não como uma fonte completa de monitoramento.
VII. O Que Proprietários de Domínio Devem Fazer
Os proprietários de domínio não precisam editar registros DNS em pânico, mas devem revisar sua postura DMARC em relação às especificações atualizadas.
Uma revisão prática deve incluir:
- Confirmar que todos os registros DMARC ainda usam
v=DMARC1. - Identificar e planejar limpeza de tags históricas como
pct,rferi. - Revisar se a tag
npé relevante para proteção de subdomínio inexistente. - Confirmar como os subdomínios estão protegidos.
- Verificar se remetentes terceiros estão devidamente alinhados.
- Revisar visibilidade de relatórios agregados.
- Confirmar que sua plataforma DMARC suporta RFC 9989, RFC 9990 e RFC 9991.
- Perguntar aos fornecedores como eles tratam a descoberta de política baseada em DNS Tree Walk.
- Revisar se relatórios de falha são úteis, apropriados e seguros em termos de privacidade para sua organização.
O objetivo não é migração urgente. O objetivo é alinhamento controlado com o padrão DMARC atual.
VIII. O Que Plataformas DMARC Precisam Suportar
A preparação para DMARCbis não é apenas uma questão de proprietário de domínio. Plataformas que gerenciam ou monitoram DMARC também devem se adaptar.
Uma plataforma pronta para DMARCbis deve suportar:
- Comportamento do protocolo principal RFC 9989.
- Descoberta de política baseada em DNS Tree Walk.
- Análise e interpretação de
np,psdet. - Reconhecimento de tags históricas como
pct,rferi. - Ingestão e análise de relatórios agregados RFC 9990.
- Tratamento de relatórios de falha RFC 9991 quando habilitados.
- Distinção clara entre autenticação e alinhamento.
- Visibilidade através de subdomínios e domínios delegados.
- Comportamento de conformidade atualizado à medida que implementações de receptor evoluem.
Se uma plataforma não pode interpretar as tags atualizadas ou comportamento de relatórios, as equipes de segurança podem perder visibilidade sobre mudanças importantes de autenticação.
IX. Como o Skysnag Protect Ajuda
O Skysnag Protect ajuda organizações a se prepararem para o DMARCbis ao suportar análise de registros atualizada, visibilidade de relatórios e monitoramento de política à medida que as implementações de receptor evoluem.
A plataforma foi projetada para ajudar organizações a:
- Monitorar postura de aplicação DMARC.
- Rastrear alinhamento SPF e DKIM.
- Identificar fontes de envio legítimas e não autorizadas.
- Manter visibilidade através de domínios e subdomínios.
- Interpretar comportamento de relatórios agregados.
- Suportar tratamento de tags DMARC atualizadas.
- Preparar-se para descoberta de política baseada em DNS Tree Walk.
- Reduzir complexidade manual no gerenciamento contínuo de DMARC.
À medida que a indústria adota RFC 9989, RFC 9990 e RFC 9991, as organizações precisam de ferramentas que acompanhem o padrão sem forçar interrupção operacional desnecessária.
X. Considerações sobre Migração e Conformidade
O DMARCbis não é um novo protocolo. É uma versão mais clara e na trilha de padrões do DMARC baseada em mais de uma década de experiência operacional.
As organizações devem tratar a atualização como um ponto de revisão estruturado:
Revisar Registros
Verificar tags históricas, políticas de subdomínio inconsistentes, endereços de relatório ausentes e suposições desatualizadas sobre implementação de política.
Revisar Remetentes
Confirmar que todo remetente legítimo pode passar SPF alinhado ou DKIM alinhado. Isso é especialmente importante para plataformas de marketing, CRMs, sistemas de tickets, ferramentas de helpdesk e outros serviços de terceiros.
Revisar Relatórios
Certificar-se de que os relatórios agregados estão sendo processados corretamente e que quaisquer relatórios de falha são tratados com controles adequados de privacidade e acesso.
Revisar Fornecedores
Perguntar aos fornecedores de segurança de e-mail se eles suportam RFC 9989, RFC 9990 e RFC 9991, incluindo descoberta de política DNS Tree Walk e interpretação de tags atualizada.
XI. Palavras Finais
O DMARCbis é o mesmo DMARC, mas mais claro, mais formal e melhor alinhado com como o e-mail realmente se comporta.
A publicação da RFC 9989, RFC 9990 e RFC 9991 é um bom incentivo para os proprietários de domínio revisarem seus registros, validarem alinhamento de remetentes, verificarem cobertura de subdomínios e confirmarem que suas ferramentas estão prontas para o padrão atual.
Para organizações responsáveis por proteção de marca, prevenção de phishing e confiança em e-mail, a mudança não é disruptiva. É uma oportunidade para melhorar a qualidade da implementação.
XII. Principais Conclusões
- A RFC 9989 substitui a RFC 7489 como a especificação central do protocolo DMARC.
- A RFC 9990 define relatórios agregados DMARC.
- A RFC 9991 define relatórios de falha DMARC.
- Registros DMARC existentes ainda usam
v=DMARC1. - DNS Tree Walk substitui a dependência da Public Suffix List para descoberta de políticas.
- A RFC 9989 introduz suporte ativo para
np,psdet. pct,rferiagora são tags históricas.- DMARCbis melhora a clareza e consistência de implementação em vez de alterar o propósito básico do DMARC.
- As organizações devem revisar registros, subdomínios, remetentes, relatórios e prontidão de fornecedores.
Pronto para alinhar seu programa de autenticação de e-mail com DMARCbis? Explore o Skysnag Protect.
