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 registos DMARC existentes continuam no formato v=DMARC1.

⚡TL;DR

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).
• Novas etiquetas: psd, np (política para non-existent domains), t (testing, substitui o uso prático de pct=0).
• Etiquetas removidas: 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 não controlar toda a cadeia de autenticação; mantenha p=reject apenas quando todos os intermediários estão sob a sua gestão. MTAs não devem rejeitar apenas porque existe p=reject.
• Compatibilidade: os registos DMARC atuais continuam válidos; planeie a migração para as novas etiquetas 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 alteração de versão (v=DMARC1); ainda assim, operadores e implementadores devem preparar-se para os novos algoritmos e etiquetas.

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 a etiqueta (máximo de 8 consultas) até encontrar um Organizational Domain ou um PSD.
• A etiqueta psd orienta a interpretação:
  • psd=n ⇒ o domínio que publica o registo é 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) Etiquetas: adições, remoções, inalteradas

Adicionadas

• psd: assinala um domínio como Public Suffix Domain (y/n) para orientar 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).

Removidas

• 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).

Inalteradas (exemplos)

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

4) psd: marcador de Public Suffix Domain

A etiqueta psd informa se o domínio que publica o registo 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 opera, mas permite que os domínios registáveis abaixo dele gerem o próprio DMARC.
• psd=n: o domínio é um Organizational Domain e ancora a descoberta de políticas para os seus subdomínios.

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

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

A etiqueta np estende DMARC a subdomínios inexistentes encontrados durante o Tree Walk:

• Só se aplica quando não há um registo _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 de criar registos DMARC individuais.

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

A etiqueta 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 o seu próprio relatório.
• Destinos externos (rua/ruf apontando para outro domínio): o mecanismo de autorização mantém-se (registos publicados pelo recetor do relatório).
• Privacidade: ative relatórios de falha com cautela; a maioria dos operadores continua a privilegiar 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 a sua autoridade.
• Recetores não devem rejeitar uma mensagem apenas porque existe uma política reject; precisam de correlacionar outros sinais (comportamento de listas, reescritas de cabeçalho, ARC, reputação etc.).
• Para evitar contornar o modo relaxed, publique registos DMARC o mais próximo 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 registos existentes continuam válidos.
• A remover: pct, ri, rf.
• A introduzir: psd quando pertinente (PSOs / TLDs ou domínios registáveis especiais), np para controlar non-existent domains, t para conduzir o rollout.

Exemplos de registos

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 registos o mais perto possível dos remetentes reais.

3. Políticas

   Inicie com p=quarantine + t=y; monitorize 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 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

   Utilize caixas dedicadas rua/ruf, com encriptação 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 detetar problemas de interoperabilidade.

11) FAQ

Precisamos de alterar `v=DMARC1` para `v=DMARC2`?

Não — o valor mantém-se DMARC1.

`pct` ainda é respeitado?

Foi removido da especificação; alguns recetores podem ignorá-lo. Utilize 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 controlar totalmente a cadeia de autenticação; para comunicações gerais (listas, aliases, redirecionamentos) DMARCbis recomenda manter p=quarantine.

12) Glossário

• Public Suffix List (PSL): lista de sufixos públicos mantida historicamente pela Mozilla; DMARCbis substitui o 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, registos 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 a etiqueta para encontrar um registo _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 desenhados internamente para o CaptainDNS.