Seu registro TXT _dmarc ainda contém uma tag pct=50? Ela deixou de servir para algo desde o 20 de maio de 2026. Nesse dia, a IETF publicou o DMARCbis na forma de três RFCs: a 9989 para a base do protocolo, acompanhada das 9990 e 9991 para reporting, que substituem oficialmente a RFC 7489 de 2015 (dmarc.org, maio de 2026). A tag pct desaparece, duas novas tags entram e o mecanismo de descoberta do domínio organizacional muda. Perder 30% de delivery em três meses sem alteração de conteúdo, com um SaaS de emailing que continua mostrando status verde, às vezes remonta a uma configuração DNS nunca revisada, e não ao conteúdo das campanhas. Para os fundamentos do protocolo, especialmente o que ele não cobre, DMARC: 5 coisas que ele não pode fazer continua sendo a referência. Aqui, o foco é a migração em si e o que precisa ser corrigido antes que os grandes provedores (Google, Microsoft, Yahoo) alinhem seus parsers a ela.
O que o DMARCbis muda na prática em relação à RFC 7489?
A RFC 7489 tinha status “Informational” desde a publicação, em 2015: o DMARC nunca virou um padrão Internet no sentido estrito da IETF. A RFC 9989 corrige esse ponto. O protocolo passa a ser Proposed Standard, o primeiro degrau normativo da IETF, e torna obsoletas a RFC 7489 e também a RFC 9091, a extensão PSD DMARC que permanecia experimental. A RFC 9990 agora rege os relatórios agregados XML; a RFC 9991 cobre os relatórios de falha mensagem por mensagem. Tudo isso vem do rascunho draft-ietf-dmarc-dmarcbis-41, publicado em 4 de abril de 2025 ao fim de um trabalho iniciado em 2019, na esteira da finalização do protocolo ARC.
Um ponto tranquiliza os administradores apressados. O valor v=DMARC1 não muda. Um registro publicado em 2019 continua respondendo em 2026, sem interrupção de serviço no dia da migração.
As tags que o DMARCbis remove
Três tags saem da especificação, com a pct na frente. Destinada a aplicar a política a um percentual do tráfego, ela sofria de um defeito documentado há anos: na prática, só os valores 0 e 100 eram aplicados de forma confiável, e os valores intermediários produziam comportamentos inconsistentes de um provedor para outro (dmarcian, 2025). Ela é substituída por uma tag binária, t, com apenas dois valores: t=y para o modo teste, equivalente ao antigo pct=0, e t=n para aplicação completa, equivalente a pct=100. Junto dela desaparecem rf, o formato dos relatórios agregados, e ri, o intervalo entre relatórios, movidos para os documentos de reporting RFC 9990 e RFC 9991. Um registro que ainda contém uma dessas três tags continua funcionando, apenas fica obsoleto.
As tags que o DMARCbis adiciona
A tag np mira um ponto cego real da RFC 7489, o dos subdomínios que não existem no DNS. Um atacante podia até então enviar a partir de fake.pagamento.exemplo.com sem que nenhuma política DMARC se aplicasse, já que o subdomínio simplesmente não tinha registro a consultar (dmarcian, 2025). Com np=reject ou np=quarantine, o dono do domínio fecha essa porta sem precisar endurecer o resto do tráfego legítimo. Junto dela, a tag psd retoma o conteúdo da antiga RFC 9091: marca um domínio como sufixo público (psd=y), e essa informação alimenta o mecanismo de descoberta descrito mais adiante. Um domínio que busca a exibição do BIMI no Gmail terá de qualquer forma que passar por p=quarantine ou p=reject: a clarificação trazida pelo np não muda esse pré-requisito, que já existia.
A descoberta por árvore DNS substitui a Public Suffix List
Pegue mail.marketing.exemplo.com. Sob a RFC 7489, determinar o domínio organizacional desse endereço dependia da Public Suffix List, uma lista mantida manualmente pela Mozilla, atualizada fora de banda, nunca formalmente padronizada. Um registro esquecido ou um novo TLD ausente da lista produzia um falso negativo silencioso. A RFC 9989 substitui esse mecanismo por um DNS Tree Walk: o receptor consulta sucessivamente mail.marketing.exemplo.com, depois marketing.exemplo.com, depois exemplo.com, depois o TLD, parando assim que encontra um registro com psd=n (domínio organizacional) ou psd=y (sufixo público). O algoritmo tem um teto de 8 consultas DNS, um número que a própria RFC fixa na seção 4.10. Os relatórios agregados da RFC 9990 acrescentam dois campos até então inexistentes: discovery_method e testing, que indicam como a política foi encontrada e se o domínio está rodando em modo t=y. Um administrador que lia seus relatórios XML sem nunca verificar esses dois campos vai precisar incorporá-los ao seu dashboard.
O impacto no alinhamento SPF e DKIM
O alinhamento continua sendo a mesma mecânica: comparar o domínio autenticado por SPF ou DKIM ao domínio organizacional do domínio From. O que muda é o cálculo desse domínio organizacional, que não sai mais de uma lista externa, mas de uma resolução DNS determinística. Num domínio de estrutura clássica, tipo exemplo.com sem subnível exótico, nada muda. Numa estrutura DNS profunda, com vários níveis de subdomínios geridos por entidades diferentes, o resultado do tree walk pode divergir do que a PSL retornava, principalmente quando um nível intermediário passa a publicar um registro psd. A RFC 9989 também esclarece um ponto que já era verdade na prática, mas raramente escrito por extenso: o alinhamento SPF incide apenas sobre a identidade MAIL FROM do comando SMTP, nunca sobre a identidade HELO. Um domínio que apostava num alinhamento HELO nunca esteve, na realidade, coberto; a clarificação só torna isso explícito. Quanto aos pontos de fricção estruturais do próprio protocolo SPF, o limite das 10 consultas DNS e as consequências de um SPF ausente continuam válidos, o DMARCbis não os elimina.
Um limite permanece. Passadas oito consultas DNS, o tree walk não resolve nada. A RFC fixa esse teto para evitar loops e ataques de amplificação, mas uma arquitetura com delegação profunda, um provedor DNS empilhado sobre outro provedor, pode esbarrar nisso antes mesmo de alcançar o domínio organizacional real.
Quais tags DNS TXT _dmarc corrigir antes da migração?
A documentação da IETF não especifica em quanto tempo os grandes provedores (Google, Microsoft, Yahoo) vão migrar seus parsers de recepção para o DMARCbis. As três RFCs estão publicadas; a adoção do lado dos provedores segue progressiva e sem calendário definido até o momento. Corrigir o registro agora evita ficar para trás no dia em que um dos três mudar sua leitura padrão.
- Remover toda tag pct= do registro TXT _dmarc, seja qual for seu valor atual.
- Excluir rf= e ri= se estiverem presentes, dois parâmetros que um receptor compatível com a RFC 9989 não lê mais.
- Adicionar np=quarantine ou np=reject assim que a política principal, p=, já estiver aplicada, para fechar a porta dos subdomínios inexistentes.
- Verificar a estrutura dos subdomínios geridos por prestadores externos, registrador, filial, marca secundária, e avaliar se uma tag psd=y ou psd=n deve ser publicada num nível intermediário.
- Documentar o modo t= escolhido, t=y em teste ou t=n em aplicação, em vez de deixar um valor pct herdado servir de referência.
Nenhuma dessas correções exige encerrar ou reconfigurar um registro SPF ou DKIM existente. O trabalho fica restrito ao campo DMARC, mesmo que toque na mesma zona DNS que os registros CNAME já em uso para outras finalidades.
“As mudanças e melhorias conhecidas como DMARCbis já são oficiais: o protocolo passa para a via normativa da IETF” (dmarc.org, maio de 2026).
O que a migração muda para a reputação de envio
Limpar o registro DMARC resolve só parte do problema. Um domínio perfeitamente alinhado que envia para uma lista degradada continua gerando rejeições, por outro motivo: a taxa de hard bounce sobe, a sender reputation piora junto ao postmaster do Gmail e um DMARC reject num domínio que, fora isso, é limpo, acaba sendo lido como sinal de spam em vez de anomalia pontual. Essa é a objeção de sempre: verificar uma lista antes do envio tem um custo, mais vale filtrar depois. Só que uma rejeição DMARC pós-autenticação não se recupera na triagem como um soft bounce comum, ela prejudica a reputação do IP antes mesmo que essa triagem aconteça. Os feedback loops dos provedores e o complaint rate costumam subir antes que o SNDS da Microsoft sinalize qualquer anomalia. Uma migração DMARCbis mal preparada, somada a uma lista nunca higienizada, acumula as duas causas de rejeição em vez de isolar uma só. Para entender por que as rejeições SMTP aumentam e como reduzi-las, o assunto se conecta diretamente ao do registro DNS tratado aqui. A única forma de saber qual das duas causas pesa mais é passar a lista pelo crivo antes da próxima campanha, separadamente do trabalho no registro DNS.
Os protocolos se atualizam sozinhos. Os registros DNS, nunca.
