Chegou a RFC 9989: Como a Excello Mail Já Suporta o Novo Padrão DMARC

A IETF publicou a RFC 9989 em 12 de maio de 2026, encerrando o trabalho que a comunidade de segurança de e-mail vem chamando de “DMARCbis” há cinco anos. É a primeira revisão substancial do DMARC desde que a RFC 7489 saiu em 2015, e traz mudanças suficientes para que toda plataforma de monitoramento DMARC, todo receptor de relatórios e todo proprietário de domínio que publica um registro precise prestar atenção.

Acompanhamos o rascunho ao longo de quarenta e uma revisões dentro do grupo de trabalho DMARC da IETF. Hoje temos o prazer de confirmar que a Excello Mail já analisa, valida e gera registros DMARC com o novo conjunto de tags da RFC 9989, e que nosso pipeline de ingestão de relatórios agregados lê as adições de esquema da RFC 9990 de fábrica.

O Que a RFC 9989 Realmente Muda

A RFC 9989 substitui a RFC 7489 e a RFC 9091. Os dois documentos complementares, RFC 9990 (relatórios agregados) e RFC 9991 (relatórios de falhas), reúnem as partes do formato de relatório que antes ficavam dentro da especificação original. Juntos, eles formam o novo padrão DMARC.

As mudanças substanciais se agrupam em três áreas.

1. O Conjunto de Tags É Diferente

Chegam três tags novas, uma é removida e o restante permanece.

np= (nova). Política de Subdomínio Inexistente. Os receptores a aplicam quando uma mensagem afirma vir de um subdomínio que não existe no DNS. Valores: none, quarantine ou reject. Seção 4.7.
t= (nova). Modo de Teste. Quando vale y, a política publicada está em modo de teste e os receptores devem tratar as ações como consultivas, não obrigatórias. Substituta do antigo papel da tag pct. Seção 4.7.
psd= (nova). Sinalizador de Domínio de Sufixo Público. Usada por operadores de Sufixo Público (os operadores de .co.uk, .gov.au, etc.) para indicar se o registro está em um PSD ou em um Domínio Organizacional. Valores: y, n, u. Seção 4.10.
pct= (removida). A tag de percentual desaparece. O Apêndice A.6 da RFC 9989 documenta a remoção. Registros existentes continuam funcionando, mas os novos devem usar t=y para o modo de teste.

2. O Domínio Organizacional Agora Vem do DNS, Não de uma Lista

A mudança arquitetonicamente mais importante. A RFC 7489 instruía os receptores a derivar o Domínio Organizacional (o domínio dono da política à qual os subdomínios devem recorrer) consultando uma Public Suffix List. A PSL é mantida pela Mozilla, depende de um repositório centralizado no GitHub e produz resultados inconsistentes entre receptores que usam diferentes snapshots dela.

A RFC 9989 substitui a PSL pela Caminhada na Árvore do DNS. O algoritmo está na Seção 4.10. Em linguagem clara: partindo do domínio no cabeçalho From da mensagem, o receptor consulta _dmarc.<esse-dominio>. Se não houver nada lá, ele retira o rótulo mais à esquerda e consulta de novo. Continua subindo a árvore até encontrar um registro DMARC ou esbarrar na tag psd= de um operador de Sufixo Público. A caminhada é limitada a oito consultas para evitar abusos.

O resultado: o próprio DNS, e não uma lista externa, determina onde fica a fronteira do Domínio Organizacional. Operadores de sufixos podem publicar seus próprios registros DMARC com psd=y para marcar a fronteira explicitamente. Como efeito colateral, os proprietários de domínios ganham que um subdomínio sem registro DMARC próprio agora herda do pai de maneira confiável via DNS, e não via o snapshot de PSL que o receptor por acaso tivesse carregado.

3. Os Formatos de Relatório Receberam Adições de Esquema

O formato XML de relatórios agregados (RUA) na RFC 9990 agora carrega elementos opcionais version, discovery_method, np e testing sobre policy_published, transforma o elemento selector do DKIM em parte obrigatória de cada entrada de auth_results e adiciona os campos opcionais human_result e scope para diagnósticos mais ricos.

O formato de relatórios de falhas (RUF) na RFC 9991 introduz um cabeçalho obrigatório Identity-Alignment listando os mecanismos que falharam em autenticar uma identidade alinhada, mais os campos DKIM-Domain, DKIM-Identity, DKIM-Selector e SPF-DNS com a mesma finalidade. Também oficializa o Auth-Failure: dmarc.

O Que Isso Significa para Seu Domínio

Nada quebra imediatamente. Registros RFC 7489 continuam sendo lidos corretamente por todas as implementações que conhecemos, incluindo a nossa. Os receptores vão implantar o suporte à RFC 9989 gradualmente, com os grandes provedores de caixa de entrada provavelmente saindo na frente.

Dito isso, duas recomendações práticas:

Se você publica pct= hoje, planeje migrar para t=y na próxima vez que revisar seu registro. Os receptores continuarão tolerando a tag descontinuada por um bom tempo, mas o sinal mais limpo para “política em modo de teste” agora é a nova tag.
Se você administra um domínio com vários subdomínios, considere definir np= explicitamente. Hoje muitas plataformas se complicam com correio falsificado a partir de subdomínios inexistentes, e np=reject é a forma mais limpa de fechar esse vetor.

Como a Excello Mail Suporta

Nosso trabalho nas últimas duas semanas trouxe cada parte da plataforma à conformidade com a RFC 9989, a RFC 9990 e a RFC 9991:

Analisador de registros DMARC. Nossa página /details/dmarc agora exibe np, t e psd quando presentes, com descrições completas do significado de cada tag. Se seu registro publicado usa pct=, nós o mostramos (nenhum registro fica quebrado) e destacamos a descontinuação pela RFC 9989 na descrição do campo.
Caminhada na Árvore do DNS. Nosso módulo de descoberta de política sobe pela hierarquia do DNS a partir do domínio autor, respeita as fronteiras psd= e o teto de oito consultas. Subdomínios sem registro DMARC próprio agora herdam corretamente do Domínio Organizacional.
Ingestão de relatórios agregados. Nosso pipeline RUA extrai cada elemento novo da RFC 9990. O selector DKIM, as strings de diagnóstico legíveis, o escopo SPF e os identificadores envelope-from / envelope-to são analisados e armazenados de forma relacional. Sem blobs JSON.
Processamento de relatórios de falhas. Nosso parser ARF lê os novos campos Identity-Alignment, DKIM-Selector, DKIM-Domain, DKIM-Identity e SPF-DNS, e reconhece Auth-Failure: dmarc como tipo de falha de primeira classe.
Gerador de registros. Nossa ferramenta /generate/dmarc oferece np e t como opções configuráveis. Removemos o campo pct para novos registros porque a RFC 9989 o remove, e explicamos essa mudança ao lado do formulário. Traduzido para inglês, espanhol e português.

Se você publica ou monitora registros DMARC, suas ferramentas precisam acompanhar o novo padrão. A maneira mais simples de se manter em dia é terceirizar o trabalho.

Experimente a Excello Mail

A Excello Mail é uma plataforma de monitoramento DMARC totalmente gerenciada. Recebemos seus relatórios agregados e de falhas, analisamos contra os últimos padrões (agora incluindo RFC 9989, RFC 9990 e RFC 9991), mostramos como seu tráfego realmente se comporta em cada fonte autenticadora, e te guiamos de p=none até p=reject sem quebrar seus fluxos de e-mail legítimos.

Comece seu teste grátis em excello.email

Tem uma dúvida sobre como alguma mudança específica da RFC 9989 afeta você? Crie uma conta e nosso time vai revisar com você o registro publicado.