DMARCbis: o guia completo para entender e migrar para o novo padrão DMARC

⚡TL;DR

• DMARCbis substitui o DMARC (RFC 7489) e se torna um Proposed Standard IETF. Os três documentos estão na fila do RFC Editor, com publicação esperada ao longo de 2026.
• O DNS Tree Walk substitui a Public Suffix List: a descoberta do domínio organizacional é feita por consultas DNS sucessivas (máx. 8), sem dependência de uma lista externa.
• Três tags adicionados: psd (marcador Public Suffix Domain), np (política para subdomínios inexistentes), t (modo testing binário).
• Três tags removidos: pct (substituído por t), ri e rf (movidos para os documentos de reporting).
• Seus registros DMARC atuais continuam válidos (v=DMARC1). A migração consiste em remover os tags obsoletos e adotar os novos progressivamente.

O DMARC protege domínios contra falsificação de identidade em emails desde 2015. Mas a RFC 7489 apresentava fraquezas estruturais: dependência de uma lista externa (a Public Suffix List), um tag pct mal compreendido e mal implementado, nenhum mecanismo para subdomínios inexistentes.

DMARCbis corrige esses problemas. Não se trata de uma simples atualização: é uma reescrita que eleva o DMARC ao status de Proposed Standard IETF, o primeiro status normativo do protocolo. Os três documentos (base, relatórios agregados, relatórios de falha) estão na fila do RFC Editor desde o final de 2025. A publicação é iminente.

Este guia é voltado para administradores de sistemas, responsáveis por email e engenheiros de segurança que precisam entender as mudanças e preparar a migração. Você encontrará aqui o funcionamento detalhado do DNS Tree Walk, um comparativo completo dos tags, um plano de migração e as implicações para conformidade (PCI DSS 4.0, Google, Yahoo, Microsoft).

Um glossário no final do artigo define os termos técnicos: PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

O que é DMARCbis?

DMARCbis é o sucessor do DMARC conforme definido pela RFC 7489. O termo "bis" segue a convenção IETF para designar a segunda iteração de um protocolo. Na prática, DMARCbis reúne três documentos normativos:

• draft-ietf-dmarc-dmarcbis: o documento de base (descoberta de política, alinhamento, tags)
• draft-ietf-dmarc-aggregate-reporting: os relatórios agregados XML
• draft-ietf-dmarc-failure-reporting: os relatórios de falha (mensagem por mensagem)

Por que essa reformulação?

A RFC 7489, publicada em 2015, tinha o status "Informational". Isso significa que o DMARC não era um padrão Internet no sentido estrito. DMARCbis corrige essa anomalia ao se tornar um Proposed Standard, o que lhe confere peso normativo no ecossistema IETF.

As motivações técnicas são precisas:

1. A Public Suffix List é frágil. Mantida manualmente pela Mozilla, não padronizada, atualizada fora de banda. Um registro esquecido ou um novo TLD não listado provoca falsos negativos.
2. O tag pct era inútil. Na prática, apenas os valores 0 e 100 eram utilizados. As implementações variavam entre receptores, tornando o comportamento imprevisível.
3. Os subdomínios inexistentes não eram protegidos. Um atacante podia enviar a partir de faux.sous-domaine.captaindns.com sem que o DMARC se aplicasse.
4. PSD DMARC (RFC 9091) permanecia experimental. DMARCbis integra e substitui essa extensão, unificando o modelo por meio do tag psd e do Tree Walk.

Cronologia IETF

Data	Evento
2015	RFC 7489 publicada (Informational)
2021	RFC 9091 PSD DMARC (Experimental)
2024-2025	Drafts DMARCbis iterativos no WG DMARC
Q4 2025	Os três drafts entram na fila do RFC Editor (estado EDIT)
Q1/Q2 2026	Publicação esperada como Proposed Standard

Ponto essencial: a versão do registro DNS permanece v=DMARC1. Não existe v=DMARC2. Os registros existentes continuam funcionando.

O Tree Walk DNS: o fim do PSL

A mudança mais estruturante do DMARCbis é a substituição da Public Suffix List por um algoritmo de descoberta puramente DNS: o Tree Walk.

O problema do PSL

Com o DMARC v1, para determinar o domínio organizacional (Organizational Domain), o receptor consultava a Public Suffix List. Essa lista, mantida pela Mozilla, cataloga os sufixos públicos (co.uk, com.au, gouv.fr). O receptor subtraía o sufixo público do domínio para identificar a organização.

As limitações eram conhecidas:

• A lista precisa ser baixada e atualizada regularmente (possível defasagem)
• Novos TLDs ou sufixos não listados provocam erros
• O mecanismo não é padronizado: cada implementação gerencia a lista de forma diferente
• Nenhuma autoridade DNS valida a exatidão da lista

Como funciona o Tree Walk?

O Tree Walk consulta diretamente o DNS para descobrir a política DMARC aplicável. O algoritmo é o seguinte:

Entrada: o domínio do cabeçalho From: (Author Domain)

Etapas:

1. Consultar _dmarc.<AuthorDomain>. Se um registro DMARC for encontrado com psd=n (ou sem tag psd), esse domínio é o domínio organizacional. Fim.
2. Se nenhum registro for encontrado, remover o rótulo mais à esquerda e recomeçar.
3. Se um registro for encontrado com psd=y, o domínio organizacional está um rótulo abaixo do domínio atual.
4. Se um registro for encontrado com psd=u, continuar a subida.
5. Repetir até encontrar um resultado ou atingir o limite de 8 consultas DNS.

Saída: o domínio organizacional e a política aplicável (ou "sem DMARC" se nada for encontrado).

Exemplos concretos

Caso 1: domínio simples

Para newsletter.captaindns.com:

Consulta 1: _dmarc.newsletter.captaindns.com → sem registro
Consulta 2: _dmarc.captaindns.com → "v=DMARC1; p=reject; psd=n"

Resultado: psd=n confirma que captaindns.com é o domínio organizacional. 2 consultas DNS.

Caso 2: Public Suffix Domain

Para contact.banque.co.uk:

Consulta 1: _dmarc.contact.banque.co.uk → sem registro
Consulta 2: _dmarc.banque.co.uk → sem registro
Consulta 3: _dmarc.co.uk → "v=DMARC1; p=reject; psd=y"

Resultado: psd=y indica que co.uk é um PSD. O domínio organizacional é banque.co.uk (um rótulo abaixo do PSD). 3 consultas DNS.

Caso 3: domínio profundo

Para um domínio com mais de 8 rótulos, o algoritmo pula diretamente para 7 rótulos após a primeira consulta, depois sobe rótulo por rótulo. O limite de 8 consultas garante que o processo termine.

Comparação entre o PSL e o Tree Walk

Aspecto	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Fonte de verdade	Lista estática (Mozilla)	O próprio DNS
Atualização	Download periódico	Tempo real via consultas DNS
Cobertura	Manual, potencialmente incompleta	Qualquer domínio que publique um registro _dmarc
Detecção PSD	Busca na lista	Tag psd=y no registro DNS
Padronização	Projeto comunitário, não normativo	Standards Track IETF

Desempenho do Tree Walk

Para um domínio típico com 3 rótulos (como newsletter.captaindns.com), o Tree Walk adiciona no máximo 1 consulta DNS a mais em relação ao DMARC v1. O limite de 8 consultas garante que domínios profundos não causem sobrecarga.

O cache DNS atenua o impacto na prática. Os registros _dmarc do domínio organizacional são armazenados em cache após a primeira consulta. As respostas NXDOMAIN também são armazenadas em cache conforme o TTL do campo MINIMUM do SOA. Um domínio que recebe milhares de mensagens por hora gerará apenas poucas consultas Tree Walk efetivas.

Em comparação, a abordagem PSL não gerava nenhuma consulta DNS para a descoberta. Porém, exigia o download periódico de uma lista de aproximadamente 250 KB e sua manutenção em memória.

Recomendação de TTL: publique seus registros _dmarc com um TTL de pelo menos 3600 s. Um TTL de 86400 s reduz ainda mais a carga DNS. Isso é particularmente útil para registros com psd=n ou psd=y, que servem como pontos de ancoragem do Tree Walk.

O que muda nos tags DMARC

DMARCbis adiciona três tags, remove três e modifica o comportamento de dois existentes. O tag de versão (v=DMARC1) e os tags fundamentais (p, sp, adkim, aspf, fo) permanecem inalterados.

Tags adicionados

O tag psd: marcador de sufixo público

O tag psd indica se o domínio que publica o registro é um Public Suffix Domain.

Valor	Significado
y	Este domínio é um PSD (ex.: co.uk, gouv.fr). O domínio organizacional está um rótulo abaixo.
n	Este domínio é um domínio organizacional normal.
u	Não determinado. O Tree Walk continua a subida.

Valor padrão: u (undetermined).

Quem deve usá-lo? Apenas os operadores de sufixos públicos (registros de TLD, registros setoriais). Para um domínio padrão, deixe psd ausente ou indique psd=n.

Exemplo para um registro:

_dmarc.co.uk. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:dmarc-agg@registry.co.uk"

O tag np: política para subdomínios inexistentes

O tag np preenche um ponto cego do DMARC v1: os subdomínios que não existem no DNS. Um atacante podia enviar a partir de faux.captaindns.com sem que nenhuma política se aplicasse, caso nenhum registro _dmarc existisse nesse nível.

Com np, o domínio organizacional pode declarar uma política específica para esses casos. Os valores são idênticos a p: none, quarantine, reject.

A cadeia de fallback é: np (se presente), depois sp (se presente), depois p.

O receptor verifica a existência do subdomínio via DNS. Se o DNS retornar NXDOMAIN, a política np se aplica.

Exemplo:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-agg@captaindns.com"

Resultado: os subdomínios existentes herdam p=quarantine. Os subdomínios inexistentes são bloqueados por np=reject.

O tag t: modo testing

O tag t substitui o uso de pct=0 para o modo teste. A semântica é binária:

• t=y: a política é rebaixada em um nível (reject se torna quarantine, quarantine se torna none)
• t=n: a política se aplica normalmente (valor padrão)

O modo testing não afeta o reporting: os relatórios agregados são enviados normalmente, o que permite monitorar os resultados antes de aplicar a política rigorosa.

Ponto crítico para a transição: os receptores DMARC v1 ignoram tags desconhecidos. Se você publicar p=reject; t=y, um receptor que ainda não implementa DMARCbis aplicará reject sem levar em conta o t=y. Esse comportamento é intencional: garante que a política mais rigorosa se aplique por padrão.

Tags removidos

Tag	Motivo da remoção	Substituição
pct	Na prática, apenas os valores 0 e 100 eram utilizados. O comportamento variava entre implementações.	t=y para o modo teste, remoção para o restante
ri	O intervalo de reporting era padronizado de fato em 24 h. Os receptores ignoravam outros valores.	Gerenciado pelo documento Aggregate Reporting
rf	Apenas um formato existia (afrf). Nenhuma alternativa foi implantada.	Gerenciado pelo documento Failure Reporting

Se seus registros DMARC ainda contêm pct, ri ou rf, eles continuarão funcionando (os receptores os ignorarão). Mas é recomendado removê-los para evitar qualquer ambiguidade.

Tags modificados

rua (relatórios agregados): a sintaxe de limite de tamanho (!10m) é removida. A verificação de destino externo é reforçada: se o domínio do endereço rua for diferente do domínio DMARC, um registro de autorização _dmarc-report._report.<rua-domain> deve existir.

ruf (relatórios de falha): definido em um documento RFC separado (Failure Reporting). Mesma verificação de destino externo que rua.

Tabela resumo v1 vs DMARCbis

Tag	DMARC v1	DMARCbis	Status
v	DMARC1	DMARC1	Inalterado
p	none / quarantine / reject	Idêntico	Inalterado
sp	Política de subdomínios	Idêntico	Inalterado
adkim	r / s	Idêntico	Inalterado
aspf	r / s	Idêntico	Inalterado
fo	0 / 1 / d / s	Idêntico	Inalterado
rua	URIs com limite de tamanho	URIs sem limite, verificação externa reforçada	Modificado
ruf	URIs	Definido em RFC separado	Modificado
pct	0-100	Removido	Removido
ri	Segundos	Removido	Removido
rf	afrf	Removido	Removido
np	N/A	none / quarantine / reject	Novo
psd	N/A	y / n / u	Novo
t	N/A	y / n	Novo

O reporting se separa em três documentos

O DMARC v1 reunia tudo na RFC 7489: política, relatórios agregados e relatórios de falha. DMARCbis separa essas responsabilidades em três documentos normativos distintos.

Os relatórios agregados

Os relatórios agregados continuam no formato XML, mas o esquema evolui. As principais mudanças:

• Novo namespace XML: urn:ietf:params:xml:ns:dmarc-2.0
• Novo campo <testing>: indica se o domínio estava em modo teste (t=y)
• Novo campo <np>: política para subdomínios inexistentes
• Novo campo <discovery_method>: como a política foi descoberta (Tree Walk vs direto)
• Nova disposição pass: adicionada às disposições possíveis
• Remoção de sampled_out: o motivo de override desaparece com pct

Cada URI listada em rua recebe seu próprio relatório. Isso não é mais opcional: os receptores DEVEM enviar um relatório distinto para cada endereço.

Os relatórios de falha

Os relatórios de falha agora são cobertos por um documento separado. Essa mudança reflete a realidade: a maioria dos grandes provedores não enviava relatórios de falha, por questões de privacidade e volume.

O documento esclarece os requisitos de privacidade e os casos em que o envio é apropriado.

Outras mudanças notáveis

• SPF restrito ao MAIL FROM: DMARCbis elimina a verificação SPF baseada em HELO/EHLO. Apenas o domínio MAIL FROM é avaliado para o alinhamento.
• Orientação reforçada sobre p=reject: os domínios com p=reject devem usar DKIM (não apenas SPF). Os receptores não devem rejeitar exclusivamente com base em p=reject sem avaliação DKIM/SPF. Os domínios cujos usuários publicam em listas de discussão não deveriam publicar p=reject.

DMARCbis e as listas de discussão

As listas de discussão são o caso de uso mais problemático do DMARC desde 2015. DMARCbis não resolve o problema, mas o documenta formalmente e reforça as recomendações.

Por que as listas quebram o alinhamento?

Uma lista de discussão modifica a mensagem em trânsito. O envelope SMTP muda (novo MAIL FROM), o que quebra o alinhamento SPF. O conteúdo é frequentemente modificado (adição de prefixo no assunto, rodapé de cancelamento de inscrição), o que invalida a assinatura DKIM. O resultado: uma falha DMARC sistemática para domínios com p=reject.

DMARCbis reforça formalmente a recomendação: os domínios cujos usuários participam de listas de discussão não deveriam publicar p=reject. A política p=quarantine é preferível nesse caso.

ARC como mecanismo de recuperação

ARC (Authenticated Received Chain, RFC 8617) permite que intermediários preservem uma cadeia de autenticação. DMARCbis referencia o ARC como mecanismo que os receptores PODEM usar para recuperar os resultados de autenticação originais. Mas DMARCbis não torna o ARC obrigatório. É uma opção, não uma garantia.

Os tipos de override nos relatórios agregados

DMARCbis reconhece os seguintes tipos de override nos relatórios agregados:

• forwarded: mensagem redirecionada por um terceiro
• mailing_list: mensagem proveniente de uma lista de discussão
• trusted_forwarder: encaminhador de confiança identificado pelo receptor
• local_policy: política local do receptor (whitelist, reputação)
• policy_test_mode: novo tipo, substitui sampled_out (removido com pct)

Esses tipos permitem entender por que um receptor optou por não aplicar a política publicada.

Conselho prático

Os softwares modernos de listas de discussão (Mailman 3, Sympa) incluem mitigações DMARC integradas. A mais comum: a reescrita do From: para usar o endereço da lista em vez do endereço original. Se seu domínio é usado por listas, verifique se essas mitigações estão ativadas. E prefira p=quarantine a p=reject.

DMARCbis e os provedores de envio (ESP)

Nenhum ESP importante (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) anunciou suporte específico ao DMARCbis em março de 2026. Isso é normal e esperado: DMARCbis é uma mudança do lado do receptor, não do lado do remetente. Os ESPs não precisam modificar sua infraestrutura.

O alinhamento DKIM: a questão crítica

A questão principal para os ESPs continua sendo o alinhamento DKIM. Dois modos de assinatura existem:

• Domínio compartilhado (ex.: d=sendgrid.net): a assinatura DKIM usa o domínio do ESP. O alinhamento strict falha porque o domínio DKIM não corresponde ao domínio From:. O alinhamento relaxed também falha.
• Domínio personalizado via CNAME (ex.: d=captaindns.com): a assinatura DKIM usa seu próprio domínio. O alinhamento funciona tanto em strict quanto em relaxed.

DMARCbis recomenda adkim=s (strict). Essa recomendação torna a assinatura DKIM personalizada indispensável para qualquer domínio que use um ESP.

SPF e o domínio de bounce

DMARCbis elimina a verificação SPF baseada em HELO/EHLO. Apenas o domínio MAIL FROM (Return-Path) conta para o alinhamento SPF. A maioria dos ESPs usa um domínio de bounce genérico por padrão (ex.: bounce.sendgrid.net). Esse domínio não corresponde ao seu domínio From:, o que faz o alinhamento SPF falhar.

A solução: configure um domínio de bounce personalizado (Return-Path) que corresponda ao seu domínio From:. A maioria dos ESPs oferece essa opção via um CNAME DNS.

Checklist ESP

1. Verificar a assinatura DKIM personalizada: seu ESP deve assinar com d=captaindns.com, não com seu próprio domínio.
2. Verificar o Return-Path personalizado: o domínio de bounce deve corresponder ao seu domínio From:.
3. Testar o alinhamento strict: envie um email de teste e verifique os cabeçalhos. Os campos d= (DKIM) e Return-Path devem corresponder ao domínio From:.
4. Começar em relaxed, passar para strict: publique adkim=r primeiro, valide os relatórios, depois passe para adkim=s.

Como migrar para DMARCbis

A boa notícia: a migração é progressiva. Seus registros DMARC atuais continuam funcionais. Veja as etapas recomendadas.

Etapa 1: auditar seus registros atuais

Identifique todos os seus domínios e subdomínios que publicam um registro _dmarc. Anote os tags utilizados, em particular pct, ri e rf.

Exemplo de registro existente:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Etapa 2: remover os tags obsoletos

Remova pct, ri e rf de seus registros. Esses tags serão ignorados pelos receptores DMARCbis e não trazem nada aos receptores v1.

Registro limpo:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Etapa 3: ativar o modo testing se necessário

Se você está preparando uma transição de quarantine para reject, use t=y para testar primeiro:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Com t=y, os receptores DMARCbis aplicarão quarantine em vez de reject. Os relatórios refletirão esse modo de teste. Após validação (2 a 4 semanas de relatórios limpos), remova t=y ou passe para t=n.

Lembrete: os receptores DMARC v1 ignorarão t=y e aplicarão p=reject diretamente. Isso não é um bug: é o comportamento esperado.

Etapa 4: proteger os subdomínios inexistentes

Adicione np=reject para bloquear a falsificação a partir de subdomínios que não existem no seu DNS:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; sp=quarantine; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Etapa 5: verificar o alinhamento DKIM

DMARCbis recomenda adkim=s (strict) para domínios onde você controla a assinatura DKIM. O alinhamento strict impede que um subdomínio reutilize a assinatura de um domínio pai.

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Etapa 6: validar as autorizações de reporting externo

Se seus endereços rua ou ruf apontam para um domínio diferente do domínio DMARC, verifique se o registro de autorização existe:

captaindns.com._dmarc-report._report.monitoring.captaindns.com. IN TXT "v=DMARC1"

Erros comuns de migração

Sete armadilhas aparecem regularmente durante a migração para DMARCbis. Conhecê-las evitará surpresas em produção.

1. Publicar t=y sem entender o comportamento v1. Os receptores DMARC v1 (ainda a maioria em março de 2026) ignoram t=y porque é um tag desconhecido. Eles aplicam p=reject diretamente, sem rebaixamento. Esse comportamento é previsto por design, mas frequentemente surpreende os administradores que esperam um modo de teste universal.

2. Manter pct=0 com t=y. Essa combinação cria um comportamento inconsistente. Os receptores v1 aplicam pct=0 (sem enforcement). Os receptores DMARCbis ignoram pct e aplicam t=y (enforcement rebaixado). Resultado: duas populações de receptores com comportamentos diferentes. Solução: remova pct antes de adicionar t.

3. Tree Walk produzindo um domínio organizacional diferente do PSL. Alguns TLDs pouco comuns têm uma entrada PSL que não está atualizada. O Tree Walk pode então identificar um domínio organizacional diferente daquele determinado pelo antigo mecanismo PSL. Mitigação: publique um registro _dmarc explícito com psd=n no nível do seu domínio organizacional.

4. Esquecer os registros de autorização de reporting externo. Quando você muda de provedor de monitoramento DMARC, os antigos registros _dmarc-report._report apontam para o provedor anterior. Os relatórios cessam silenciosamente sem mensagem de erro. Atualize esses registros a cada mudança de provedor.

5. Não testar o impacto de np=reject. Essa política pode afetar serviços legítimos que usam subdomínios dinâmicos. Alguns CDNs, plataformas de marketing ou ferramentas de campanha criam subdomínios sob demanda. Verifique se esses serviços não enviam email a partir de subdomínios não registrados no seu DNS.

6. Confiar nos relatórios de falha (ruf). Os grandes provedores (Google, Yahoo, Microsoft) praticamente pararam de enviar relatórios de falha por questões de privacidade e conformidade com LGPD/GDPR. Use os relatórios agregados (rua) como fonte principal de análise. Os relatórios de falha são um complemento, não uma base confiável.

7. Planejar uma implantação progressiva sem pct. Com pct removido no DMARCbis, a implantação por porcentagem não existe mais. As opções são t=y (rebaixamento completo) ou enforcement completo (sem t ou t=n). Use t=y com janelas de monitoramento manuais de 2 a 4 semanas para reproduzir uma implantação progressiva.

DMARCbis e a conformidade regulatória

Conformidade anti-phishing e padrão de pagamento

A versão 4.0 do PCI DSS (aplicável desde março de 2025) exige controles anti-phishing para entidades que processam pagamentos. DMARC em modo enforcement (quarantine ou reject) faz parte das medidas esperadas. DMARCbis reforça essa postura com np=reject (proteção de subdomínios inexistentes) e a recomendação de alinhamento strict DKIM.

As exigências do Google e Yahoo para envio em massa

Desde fevereiro de 2024, Google e Yahoo exigem DMARC para remetentes com mais de 5.000 mensagens por dia. Embora esses provedores ainda não tenham implementado DMARCbis, eles reconhecerão os registros limpos (sem pct, ri, rf), já que esses tags já são amplamente ignorados.

Microsoft e Exchange Online

A Microsoft aplica progressivamente verificações DMARC mais rigorosas no Exchange Online e Outlook. A adoção do DMARCbis pela Microsoft ainda não foi anunciada, mas a preparação antecipada evitará ajustes de última hora.

Adoção atual (março de 2026)

A adoção do lado dos receptores ainda é marginal. Apenas a United Internet AG (GMX, mail.com, WEB.DE) emite relatórios no formato DMARCbis (3 reporters em 3.493 nos dados observados). Google, Microsoft, Yahoo e Amazon SES ainda não migraram. Este é o momento de preparar seus registros: quando os grandes provedores fizerem a transição, você estará pronto.

Plano de ação: preparar a transição

1. Inventariar todos os domínios e subdomínios que publicam um registro _dmarc. Identificar os Author Domains reais e as zonas sem registro DMARC.
2. Testar com o DMARCbis Checker a compatibilidade de cada domínio. Identificar os tags obsoletos e as recomendações específicas.
3. Limpar seus registros: remover pct, ri, rf. Manter v=DMARC1.
4. Adicionar np=reject no nível do domínio organizacional para proteger os subdomínios inexistentes.
5. Usar t=y para qualquer elevação de política (transição de quarantine para reject).
6. Reforçar o alinhamento: priorizar adkim=s, manter aspf=r salvo necessidade strict.
7. Validar as autorizações externas se seus endereços rua/ruf apontam para um terceiro.
8. Monitorar os relatórios agregados durante 2 a 4 semanas após cada mudança para detectar anomalias.

FAQ

É necessário mudar v=DMARC1 para v=DMARC2?

Não. A versão do registro permanece v=DMARC1. DMARCbis não modifica o tag de versão. Seus registros existentes continuam funcionando sem nenhuma modificação do tag v.

O que é o DNS Tree Walk?

O DNS Tree Walk é o algoritmo DMARCbis que substitui a Public Suffix List para descobrir a política DMARC aplicável a um domínio. Ele consulta o DNS subindo rótulo por rótulo a partir do domínio remetente (Author Domain), com um limite de 8 consultas, até encontrar um registro _dmarc que identifique o domínio organizacional por meio do tag psd.

O PSL desaparece totalmente?

Sim, do ponto de vista do DMARCbis. A descoberta de política e a determinação do domínio organizacional passam integralmente pelo DNS Tree Walk. A Public Suffix List não é mais referenciada no padrão. Alguns receptores poderão manter um fallback PSL durante a transição, mas isso não é obrigatório.

Por que o tag pct foi removido?

Na prática, apenas os valores 0 (modo teste) e 100 (aplicação completa) eram utilizados. O comportamento para valores intermediários variava entre receptores, tornando o resultado imprevisível. O tag t=y/n o substitui com uma semântica binária clara: a política é rebaixada em um nível (teste) ou se aplica normalmente.

Meu registro DMARC atual é compatível com DMARCbis?

Sim, desde que o tag v=DMARC1 esteja presente. DMARCbis é retrocompatível. Os tags pct, ri e rf serão ignorados pelos receptores DMARCbis, sem causar erro. A migração recomendada consiste em removê-los e adotar progressivamente np, psd e t.

Posso publicar p=reject para todos os meus domínios?

DMARCbis desaconselha p=reject para domínios de uso geral (listas de discussão, alias, redirecionamentos). Reserve p=reject para domínios onde você controla cada intermediário de ponta a ponta. Para os demais casos, p=quarantine continua sendo recomendado. Os receptores não devem rejeitar uma mensagem apenas porque p=reject está publicado: devem cruzar com outros sinais (ARC, reputação, listas de discussão).

O tag t=y é arriscado durante a transição?

Existe um risco calculado. Os receptores DMARC v1 ignoram t=y (tag desconhecido) e aplicam a política normalmente. Se você publicar p=reject; t=y, um receptor v1 aplicará reject sem rebaixamento. Um receptor DMARCbis aplicará quarantine. Esse comportamento é intencional: favorece a segurança por padrão. Use t=y apenas se aceitar que a política rigorosa se aplique nos receptores que ainda não migraram.

Quem deve usar o tag psd?

Apenas os operadores de sufixos públicos: registros de TLD (co.uk, com.au, gouv.fr), registros setoriais, e as grandes organizações que delegam subdomínios a entidades independentes. Para um domínio empresarial padrão, deixe psd ausente ou indique psd=n.

Quando os grandes provedores implementarão DMARCbis?

Nenhuma data foi anunciada publicamente (março de 2026). A adoção do lado dos receptores é marginal: apenas a United Internet AG (GMX, mail.com, WEB.DE) emite relatórios no formato DMARCbis. A publicação das RFCs provavelmente desencadeará a implementação nos grandes provedores. Preparar seus registros agora coloca você à frente.

Como funciona a cadeia de fallback np, sp, p?

Quando um receptor DMARCbis recebe um email de um subdomínio, ele verifica primeiro se esse subdomínio existe no DNS. Se não existir (NXDOMAIN), a política np se aplica. Se np não estiver definido, o receptor usa sp. Se sp também não estiver definido, p se aplica. Para subdomínios existentes, o fallback é sp depois p (idêntico ao DMARC v1).

DMARCbis deixa o processamento de emails mais lento?

Não. O Tree Walk adiciona 1 a 2 consultas DNS para um domínio típico com 3 rótulos. O cache DNS atenua esse impacto: os registros _dmarc e as respostas NXDOMAIN são armazenados em cache. O limite de 8 consultas garante um tempo de processamento limitado, mesmo para domínios profundos. Na prática, a diferença de latência é desprezível.

Meu ESP precisa suportar DMARCbis?

DMARCbis é uma mudança do lado do receptor. Seu ESP não precisa suportá-lo especificamente. No entanto, verifique dois pontos críticos: a assinatura DKIM personalizada (com d= correspondendo ao seu domínio) e o Return-Path personalizado (domínio de bounce alinhado com seu domínio From:). Esses dois elementos são indispensáveis para o alinhamento strict recomendado pelo DMARCbis.

Glossário

• Author Domain: domínio utilizado no cabeçalho From: da mensagem. É o ponto de partida do Tree Walk e do alinhamento DMARC.
• DNS Tree Walk: algoritmo DMARCbis que sobe a árvore DNS rótulo por rótulo para encontrar um registro _dmarc e determinar o domínio organizacional. Limite de 8 consultas.
• Organizational Domain: domínio principal de uma organização, identificado pelo Tree Walk (via psd=n ou ausência de psd). Ele é autoritativo para a política DMARC aplicável a seus subdomínios.
• PSL (Public Suffix List): lista mantida pela Mozilla dos sufixos públicos. Utilizada pelo DMARC v1, substituída pelo Tree Walk no DMARCbis.
• PSD (Public Suffix Domain): sufixo de nome de domínio operado por uma entidade que delega subdomínios (ex.: co.uk, gouv.fr). Identificado por psd=y no registro DMARC.
• PSO (Public Suffix Operator): entidade que administra um PSD e pode publicar uma política DMARC de referência para os domínios vinculados.

Guias de email relacionados

• DKIM2: tudo o que muda
• ARC: a cadeia de autenticação explicada
• BIMI, VMC, CMC: compatibilidade DNS
• Gmail Bulk Sender 2025

Fontes

1. draft-ietf-dmarc-dmarcbis (IETF Datatracker)
2. draft-ietf-dmarc-aggregate-reporting (IETF Datatracker)
3. draft-ietf-dmarc-failure-reporting (IETF Datatracker)
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)