DMARCbis: tudo o que muda (e como se preparar)

Situação em 29 de outubro de 2025. O corpus DMARCbis está praticamente finalizado: o documento principal dmarcbis-41 e aggregate-reporting-32 estão na RFC Editor Queue (MISSREF), aguardando a conclusão de failure-reporting. Os registros DMARC existentes continuam no formato v=DMARC1.

TL;DR

• Descoberta de política e domínio organizacional: a Public Suffix List (PSL) dá lugar a um DNS Tree Walk e ao novo marcador psd (y/n).
• Novos tags: psd, np (política para non-existent domains), t (testing, substitui o uso prático de pct=0).
• Tags removidos: pct, ri, rf.
• Reporting: dividido em dois documentos normativos (agregado e falhas); remove-se o limite de tamanho da URI; cada URI listada DEVE receber um relatório.
• Interoperabilidade: DMARCbis desencoraja p=reject em domínios de uso geral (listas, aliases, redirecionamentos) e recomenda p=quarantine enquanto você não controla toda a cadeia de autenticação; mantenha p=reject apenas quando todos os intermediários estão sob sua gestão. MTAs não devem rejeitar apenas porque existe p=reject.
• Compatibilidade: os registros DMARC atuais continuam válidos; planeje a migração para os novos tags e práticas.

👉 No final do artigo há um glossário com os conceitos essenciais: Public Suffix Domain, Organizational Domain e DNS Tree Walk.

1) Cronograma e status

• 17 de março de 2025: Aggregate Reporting v**–32** → RFC Editor Queue (MISSREF).
• 4 de abril de 2025: DMARCbis v**–41** → RFC Editor Queue (MISSREF).
• 9 de outubro de 2025: Failure Reporting v**–17** entra em WG Last Call.
• Publicação prevista para 2025, caso as referências pendentes sejam resolvidas.
• Impacto imediato: nenhuma mudança de versão (v=DMARC1); ainda assim, operadores e implementadores devem se preparar para os novos algoritmos e tags.

2) Descoberta de política e Organizational Domain: o DNS Tree Walk

DMARCbis substitui a dependência da PSL por uma subida na árvore DNS que

1. descobre a política aplicável (Policy Discovery), e
2. determina o domínio organizacional (Organizational Domain) para o Alignment.

Princípios-chave:

• Primeiro consulta-se "_dmarc." + AuthorDomain. Se não existir, sobe-se etiqueta por etiqueta (máximo de 8 consultas) até encontrar um Organizational Domain ou um PSD.
• O tag psd orienta a interpretação:
  • psd=n ⇒ o domínio que publica o registro é um Organizational Domain.
  • psd=y (num nível acima) ⇒ o Organizational Domain está um rótulo abaixo.
• Se a política vier de um domínio pai (Org ou PSD), aplica-se sp quando o subdomínio existe e np quando o subdomínio não existe.
• Se nada for encontrado, DMARC não se aplica à mensagem.

3) Tags: adições, remoções, inalterados

Adicionados

• psd: marca um domínio como Public Suffix Domain (y/n) para direcionar o Tree Walk.
• np: política para domínios inexistentes (lições aprendidas com o PSD).
• t: modo de testes (y/n) — substitui o padrão prático pct=0 (ver adiante).

Removidos

• pct: os rollouts parciais eram inconsistentes entre implementações; o binário 0/100 passa a ser controlado por t.
• ri: intervalo dos relatórios agregados (migra para o documento Aggregate Reporting e para a prática operacional).
• rf: formato dos relatórios de falha (detalhado no documento Failure Reporting).

Inalterados (exemplos)

v, p, sp, adkim, aspf, fo, rua, ruf, pct (removido — programar a retirada).

4) psd: marcador de Public Suffix Domain

O tag psd informa se o domínio que publica o registro DMARC deve ser tratado como Public Suffix Domain pelo algoritmo de Tree Walk:

• psd=y: o domínio é considerado um PSD. A política publicada cobre o sufixo que você opera, mas deixa que os domínios registráveis abaixo dele gerenciem o próprio DMARC.
• psd=n: o domínio é um Organizational Domain e ancora a descoberta de políticas para seus subdomínios.

Reserve psd=y para operadores de sufixo (TLDs, registros setoriais, grandes organizações com subdomínios delegados). Nos demais casos, omita o tag ou defina explicitamente psd=n para indicar que é um domínio emissor “normal”.

5) np: política para domínios inexistentes

O tag np estende DMARC a subdomínios inexistentes encontrados durante o Tree Walk:

• Só se aplica quando não há um registro _dmarc dedicado ao subdomínio (NXDOMAIN).
• Os valores permitidos (none, quarantine, reject) seguem a mesma semântica de p/sp.
• Sem np, utiliza-se o valor de p (ou o sp herdado).

Publique np=reject no seu domínio organizacional (ou no PSD) para bloquear tentativas de spoofing em subdomínios “vazios” sem precisar criar registros DMARC individuais.

6) t = testing: o sucessor prático de pct=0

O tag t=y não desativa os relatórios, mas solicita uma aplicação mais branda da política:

• p=reject + t=y ⇒ tratar falhas como quarantine.
• p=quarantine + t=y ⇒ tratar falhas como none.
• p=none ⇒ permanece igual.

Objetivo: permitir uma subida gradual segura sem os problemas de interoperabilidade que pct causava.

7) Reporting: separação, entregabilidade e segurança

• Separado em dois RFCs: relatórios agregados (XML) e relatórios de falha (mensagem a mensagem).
• Removido o limite de tamanho da URI.
• Várias URIs em rua/ruf: cada URI DEVE receber seu próprio relatório.
• Destinos externos (rua/ruf apontando para outro domínio): o mecanismo de autorização permanece (registros publicados pelo receptor do relatório).
• Privacidade: habilite relatórios de falha com cautela; a maioria dos operadores ainda prioriza relatórios agregados.

8) Interoperabilidade e políticas

• DMARCbis declara explicitamente que em domínios de uso geral (listas, aliases, redirecionamentos) não se deve publicar p=reject; prefira p=quarantine até controlar a cadeia de autenticação de ponta a ponta e mantenha p=reject apenas quando cada salto está sob sua autoridade.
• Receptores não devem rejeitar uma mensagem somente porque existe uma política reject; eles precisam correlacionar outros sinais (comportamento de listas, reescritas de cabeçalho, ARC, reputação etc.).
• Para evitar contornar o modo relaxed, publique registros DMARC o mais perto possível dos domínios que realmente enviam (e considere adkim=s/aspf=s quando fizer sentido).

9) Compatibilidade e transição

• v=DMARC1 permanece: os registros existentes continuam válidos.
• Para remover: pct, ri, rf.
• Para introduzir: psd quando pertinente (PSOs / TLDs ou domínios registráveis especiais), np para controlar non-existent domains, t para conduzir o rollout.

Exemplos de registros

Política organizacional + escalada controlada

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; 
  rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; t=y"

Marcação PSD por um operador de sufixo

_dmarc.bank.example. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:psd-agg@pso.example"

Política para domínios inexistentes

_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:agg@example.net"

10) Playbook CaptainDNS (checklist prática)

1. Inventário: liste Author Domains reais e subdomínios ativos; identifique zonas sem DMARC.
2. Árvores DNS: confira o resultado do Tree Walk (onde termina o Organizational Domain?) e publique registros o mais próximo possível dos remetentes reais.
3. Políticas: inicie com p=quarantine + t=y; monitore relatórios agregados por 2–4 semanas; avance para t=n e endureça se os falsos positivos estiverem controlados.
4. Alignment: priorize adkim=s (DKIM assinado no From); mantenha aspf=r salvo quando precisar de SPF estrito.
5. PSD / np: se você opera um domínio raiz ou “de família”, use np para bloquear non-existent domains; publique psd apenas se for PSO/PSD.
6. Reporting: caixas dedicadas rua/ruf, com criptografia em trânsito; verifique autorizações externas ao enviar relatórios para terceiros.
7. Listas / intermediários: antecipe reescritas de From:; ARC ajuda a preservar reputação e evitar rejeições indevidas.
8. Limpeza: remova pct, ri, rf; acompanhe os agregados para detectar problemas de interoperabilidade.

11) FAQ

• Precisamos alterar v=DMARC1 para v=DMARC2? Não — o valor continua sendo DMARC1.
• pct ainda é respeitado? Foi removido da especificação; alguns receptores podem ignorá-lo. Use t.
• A PSL deixa de existir? Para DMARCbis, sim: a descoberta agora depende do DNS Tree Walk.
• Posso publicar p=reject em todos os domínios? Apenas se você controlar totalmente a cadeia de autenticação; para comunicações gerais (listas, aliases, redirecionamentos) DMARCbis recomenda ficar em p=quarantine.

12) Glossário

• Public Suffix List (PSL): lista de sufixos públicos mantida historicamente pela Mozilla; DMARCbis substitui seu uso pelo DNS Tree Walk.
• Public Suffix Domain (PSD): sufixo de domínio operado por uma entidade que delega subdomínios a terceiros (ex.: TLDs, registros setoriais) e pode publicar uma política DMARC para todo o sufixo.
• Public Suffix Operator (PSO): entidade que administra um sufixo público (PSD) e pode publicar uma política DMARC de referência para os domínios associados.
• DNS Tree Walk: procedimento DMARCbis que percorre a árvore DNS etiqueta por etiqueta para encontrar um registro _dmarc, reconhecer um PSD e, quando necessário, aplicar uma política herdada (p, sp, np).
• Organizational Domain: domínio principal de uma organização, identificado pelo Tree Walk, que governa a política DMARC dos subdomínios alinhados.
• Author Domain: domínio presente no cabeçalho visível From:; base para o cálculo de alinhamento do DMARC.

---

Ilustrações: diagramas SVG feitos em casa para o CaptainDNS.