DMARCbis Checker

DMARCbis: o que muda para o seu domínio

O DMARCbis (também chamado DMARC v2) não é uma simples atualização. É uma reformulação completa do protocolo DMARC, dividida em três RFC distintos. Um DMARCbis checker revela exatamente quais ajustes são necessários:

1. Mecanismo principal (RFC 9989): descoberta de política, alignment, avaliação
2. Relatórios agregados (RFC 9990): formato XML, esquema, distribuição
3. Relatórios de falha (RFC 9991): relatórios ARF, privacidade, rate limiting

Novas tags

Tags removidas

Tree walk DNS

A alteração mais significativa do DMARCbis é a substituição da Public Suffix List (PSL) por um algoritmo de percurso DNS nativo.

Por quê? A PSL é uma lista comunitária mantida por voluntários da Mozilla. Sofre de atrasos nas atualizações, inconsistências entre implementações e a ausência de uma especificação IETF sobre a versão a utilizar. O tree walk DNS resolve estes problemas baseando-se unicamente nos dados DNS reais.

Como funciona: o receptor consulta _dmarc.<domínio>, depois sobe um label de cada vez. Se um registro contiver psd=n, esse é o domínio organizacional. Se psd=y for encontrado, o domínio um nível abaixo é o domínio organizacional.

Quem adota o DMARCbis hoje?

Prepare-se agora

Mesmo que a migração não seja urgente, preparar o seu domínio agora permite:

• Identificar as tags obsoletas a remover antes que gerem avisos
• Adicionar a tag np para proteger subdomínios inexistentes
• Compreender o tree walk e verificar que o seu domínio organizacional é corretamente determinado
• Antecipar as alterações no reporting nas suas ferramentas de análise DMARC

DMARC vs DMARCbis: tabela comparativa

Esta tabela resume as diferenças estruturais entre as duas versões do protocolo. Se o seu registro contiver tags da coluna DMARC que não existem mais no DMARCbis, o checker assinala-as automaticamente.

Como funciona o tree walk DNS?

O tree walk DNS é a inovação central do DMARCbis. Substitui as consultas à Public Suffix List por um percurso hierárquico no DNS. Eis um exemplo detalhado para compreender cada etapa.

Exemplo: um email recebido de user@sub.mail.captaindns.com

O receptor precisa encontrar a política DMARC aplicável. Com o DMARCbis, executa as seguintes consultas por ordem:

1. Consulta _dmarc.sub.mail.captaindns.com: o servidor DNS responde NXDOMAIN (nenhum registro encontrado). O receptor sobe um label.
2. Consulta _dmarc.mail.captaindns.com: o servidor DNS responde NXDOMAIN. O receptor sobe novamente.
3. Consulta _dmarc.captaindns.com: é encontrado um registro TXT, por exemplo v=DMARC1; p=reject; psd=n.

A tag psd=n indica que captaindns.com é um domínio organizacional (não um public suffix). O tree walk termina. Resultado: domínio organizacional = captaindns.com, método de descoberta = tree walk.

O que acontece com psd=y? Se _dmarc.captaindns.com contivesse psd=y, significaria que captaindns.com é um public suffix (como .co.uk). Nesse caso, o domínio organizacional seria mail.captaindns.com, o domínio um nível abaixo do suffix.

Limite de segurança: o tree walk executa no máximo 8 consultas DNS para prevenir a amplificação. Além de 8 níveis sem resultado, a descoberta falha e o domínio é tratado como se não tivesse uma política DMARC publicada.

Vantagem principal: ao contrário da PSL, que requer atualizações manuais e varia entre implementações, o tree walk baseia-se nos dados DNS em tempo real. Os administradores DNS mantêm o controle total sobre os limites da sua organização.

Por que a tag np é essencial

A tag np (non-existent subdomain policy) supre uma lacuna de segurança que o DMARC v1 não conseguia resolver: a usurpação de subdomínios inexistentes.

O vetor de ataque: um atacante envia um email de fake123.captaindns.com. Este subdomínio não existe na sua zona DNS. Com o DMARC v1, o receptor aplica a política sp (se presente) ou recorre a p. Se a sua configuração for p=reject; sp=none (uma configuração comum para permitir subdomínios legítimos), o atacante contorna a sua proteção.

A solução DMARCbis: a tag np=reject aplica-se exclusivamente aos subdomínios para os quais o DNS responde NXDOMAIN. Você pode manter uma política flexível nos seus subdomínios existentes (sp=none ou sp=quarantine para subdomínios com fluxos de email legítimos) enquanto bloqueia subdomínios inventados por atacantes.

Configuração recomendada:

• Se p=reject: adicione np=reject para cobertura máxima
• Se p=quarantine: adicione np=reject (subdomínios fictícios merecem bloqueio rigoroso)
• Se p=none: adicione np=quarantine como primeiro passo para o endurecimento

A tag np é particularmente eficaz contra ataques de CEO fraud, em que os atacantes inventam subdomínios credíveis como secure-payment.captaindns.com ou internal-hr.captaindns.com para enganar os destinatários.

Cronologia de adoção do DMARCbis

A transição para o DMARCbis segue uma cronologia gradual orientada pela IETF e pelos principais provedores de email.

As RFC 9989, 9990 e 9991 foram publicadas em maio de 2026. A migração agora consiste em remover tags históricas e verificar np e o tree walk DNS.

Ferramentas complementares

Recursos úteis

• RFC 7489 - DMARC
• RFC 9989 - DMARC
• RFC 9091 - PSD DMARC
• DMARCbis: todas as alterações e como se preparar

FAQ - Perguntas frequentes

P: O que é o DMARCbis?

R: O DMARCbis é a revisão publicada em maio de 2026 como RFC 9989, RFC 9990 e RFC 9991. A RFC 9989 torna obsoleta a RFC 7489 sem alterar v=DMARC1; padroniza o tree walk DNS e np, enquanto pct, rf e ri passam a ser tags históricas.

P: Quais são as diferenças entre DMARC e DMARCbis?

R: O DMARCbis adiciona três novas tags (np, t, psd), remove três tags (pct, rf, ri), substitui a descoberta via Public Suffix List por um algoritmo tree walk DNS e restringe a validação SPF unicamente ao MAIL FROM.

P: Devo migrar para o DMARCbis imediatamente?

R: Não há urgência. Os registros DMARC atuais continuam funcionando porque a versão permanece v=DMARC1. No entanto, recomenda-se auditar os seus registros agora para remover as tags obsoletas e adicionar as novas tags np e psd.

P: A tag pct é realmente removida?

R: Sim. A experiência operacional mostrou que a tag pct era aplicada de forma inconsistente pelos receptores. Apenas os valores 0 e 100 eram confiáveis. É substituída pela tag binária t (t=y para modo de teste, t=n para aplicação completa).

P: O que é o tree walk DNS?

R: O tree walk DNS é o algoritmo de descoberta de política DMARC no DMARCbis. Em vez de consultar uma Public Suffix List externa, o receptor percorre a hierarquia DNS consultando _dmarc em cada nível até encontrar um registro válido. Isto elimina a dependência da PSL.

P: A tag fo é removida no DMARCbis?

R: Não. A tag fo (failure reporting options) é mantida no DMARCbis. Apenas as tags pct, rf e ri são removidas.

P: Como sei se o meu domínio está pronto para o DMARCbis?

R: Execute uma análise com o nosso DMARCbis checker. A ferramenta executa um tree walk DNS completo, detecta tags obsoletas (pct, rf, ri), verifica a presença da tag np e mostra o domínio organizacional descoberto. O resultado indica um estado claro: conforme, compatível ou não conforme com o DMARCbis.

P: O tree walk DNS atrasa a entrega de email?

R: Não. O tree walk executa no máximo 8 consultas DNS e os receptores armazenam os resultados em cache com base no TTL de cada registro. Na prática, para a maioria dos domínios, o tree walk resolve-se em 2 ou 3 consultas. O impacto no tempo de entrega é negligenciável.