Um domínio pode ter um registro DMARC que parece perfeitamente válido em todos os aspectos, estar em p=reject, citar um endereço de relatórios real, e ainda assim não proteger nada. Isso acontece no momento em que um segundo registro TXT aparece no mesmo host _dmarc. A especificação não faz média entre os dois registros, nem prefere o mais rígido, nem sinaliza um conflito. Ela descarta ambos e trata o domínio como se o DMARC nunca tivesse sido configurado.
O Que a Especificação Realmente Exige
A descoberta de política do DMARC é mais restrita do que a maioria imagina. Um servidor de e-mail receptor consulta os registros TXT de _dmarc.seudominio.com, e a regra que rege o que deve ser retornado permanece inalterada desde o RFC 7489 original e segue no RFC 9989: deve existir exatamente um registro TXT que comece com v=DMARC1. Zero registros correspondentes significa que não há política. Mais de um registro correspondente também significa que não há política, sem exceção, independentemente do que cada um diga.
Isso não é um caso extremo que os redatores deixaram passar. É uma regra deliberada contra a ambiguidade. Se um receptor encontrasse dois registros, um dizendo p=reject e outro dizendo p=none, não haveria uma forma fundamentada de decidir qual o proprietário do domínio realmente pretendia, então a especificação se recusa a adivinhar. Ela descarta ambos e volta a não ter nenhuma política DMARC para aquele domínio.
Como Dois Registros Acabam no Mesmo Domínio
Ninguém senta e publica deliberadamente um registro DMARC duplicado. Isso se acumula através de atividades operacionais comuns que ninguém considera estar mexendo no DNS ao mesmo tempo que outra pessoa.
Um fornecedor de conscientização em segurança ou de autenticação de e-mail executa um assistente de configuração guiada durante a ativação e grava um registro TXT em _dmarc como parte do processo. Meses depois, uma plataforma de email marketing diferente executa seu próprio assistente de “autentique seu domínio de envio”, não verifica se já existe um registro, e grava o seu próprio. Ambas as ferramentas acreditam ter configurado o DMARC corretamente, porque, sob a visão isolada de cada ferramenta, elas de fato configuraram.
O mesmo acontece durante migrações de provedor de DNS, quando um arquivo de zona é exportado de um registrador e importado em outro sem deduplicação, e um registro antigo que deveria ter sido removido meses antes acaba seguindo junto com seu substituto. Acontece após fusões e consolidações de domínios, quando duas equipes de TI trazem cada uma suas próprias convenções de DNS para uma zona compartilhada. Acontece quando um contratado configura um registro temporário para um projeto de migração e ninguém o remove depois que ela termina.
Nenhuma dessas pessoas está cometendo um erro óbvio. Cada uma, por conta própria, publicou um registro DMARC sintaticamente correto. O domínio acaba desprotegido por causa do que acontece quando essas duas ações, corretas individualmente, coincidem na mesma zona DNS.
Por Que Nada Avisa Que Isso Aconteceu
Um registro DMARC malconfigurado costuma deixar um rastro visível. Um erro de sintaxe aparece se você passar o registro por um validador. Uma política em p=none é visivelmente permissiva se você a lê. Um registro duplicado não produz nenhum desses sinais, porque não existe um único registro para inspecionar em busca do erro; o erro existe apenas na relação entre dois registros que, isoladamente, parecem completamente corretos.
Execute dig TXT _dmarc.seudominio.com e você verá as duas entradas impressas, uma após a outra, e a menos que você esteja contando especificamente quantas começam com v=DMARC1, duas strings de política com aparência válida soam tranquilizadoras, não alarmantes. A maioria das ferramentas de verificação de registro DMARC feitas para uma checagem manual rápida exibe o registro que analisam primeiro e nunca aponta o segundo como um conflito.
O canal de relatórios que normalmente detectaria uma configuração como essa também fica comprometido pela mesma falha. Os relatórios agregados são gerados de acordo com a política que o receptor acredita estar em vigor, e um receptor que determinou corretamente que não existe uma política válida não tem obrigação de tratar o e-mail daquele domínio de forma diferente, e muitas vezes não tem motivo para continuar enviando relatórios agregados detalhados para um endereço vinculado a uma política que acabou de descartar. O mecanismo de visibilidade que deveria revelar a brecha fica desativado exatamente pela condição que a criou.
O Que Isso Custa Para Você
Enquanto dois registros permanecem em _dmarc, o domínio se comporta, da perspectiva de qualquer servidor de e-mail receptor, exatamente como um domínio que nunca adotou o DMARC. O alinhamento de SPF e DKIM não é aplicado, porque a aplicação de alinhamento é uma função do DMARC e o DMARC não está em vigor. E-mails falsificados alegando vir do domínio são avaliados puramente pelos resultados de SPF e DKIM, sem nenhuma verificação de alinhamento que os vincule ao cabeçalho From visível, que é exatamente a brecha que o DMARC existe para fechar. Um domínio que acredita estar em p=reject pode ser ativamente personificado em tentativas de phishing e comprometimento de e-mail corporativo sem que nenhuma aplicação atue sobre isso, por todo o tempo em que a duplicidade persistir.
O Que Isso Significa Para o Seu Programa
Conte os registros, não apenas o conteúdo deles. Consulte diretamente _dmarc.seudominio.com com dig ou uma ferramenta equivalente e confirme que existe exatamente um registro TXT começando com v=DMARC1. Não pare ao confirmar que o valor da política parece correto; confirme que há apenas um valor para verificar.
Trate a “configuração automática de DMARC” de qualquer fornecedor como uma gravação no DNS que você precisa verificar, não confiar cegamente. Qualquer ferramenta que se ofereça para configurar DMARC, SPF ou DKIM para você durante a integração é capaz de gravar um registro conflitante se não verificar primeiro o que já existe. Verifique o estado resultante do DNS após cada integração desse tipo, não apenas após suas próprias alterações manuais.
Reverifique após migrações de DNS e consolidações de domínio. Uma importação de arquivo de zona é exatamente o tipo de operação em massa que pode arrastar silenciosamente um registro obsoleto junto com um atual. Audite os registros _dmarc de cada domínio em uma zona imediatamente após qualquer migração ou fusão, não apenas dos domínios que alguém lembra de verificar.
Monitore de forma contínua, não apenas na configuração inicial. Um registro que era único e correto no dia em que você configurou o DMARC pode se tornar duplicado meses depois por uma equipe completamente diferente adotando uma ferramenta completamente diferente. Uma verificação única no momento da implantação não diz nada sobre o estado do seu DNS seis meses depois.
A Conclusão
Quando o DMARC falha em impedir um ataque, isso normalmente gera uma história dramática envolvendo um desvio engenhoso ou um remetente malicioso genuinamente autenticado. Esse modo de falha não tem nenhum atacante envolvido. Duas equipes bem-intencionadas, ou uma equipe e o script de integração de um fornecedor, fazem cada uma algo razoável isoladamente, e o resultado é um domínio que parece protegido à primeira vista e não está protegido de forma alguma. A correção não custa mais do que um comando dig e o hábito de contar.
Um registro DMARC que parou de funcionar silenciosamente meses atrás parece idêntico a um que nunca funcionou, até que você saiba exatamente o que verificar. A Excello Mail monitora continuamente o estado real do seu DNS, não apenas a política que você configurou uma vez, para que um registro duplicado seja detectado antes que um atacante encontre a brecha primeiro. Cadastre-se gratuitamente na Excello Mail e veja hoje sua real postura de autenticação.