Colar um registro DMARC na zona DNS não encerra nada: o record não faz nada enquanto ninguém lê os relatórios que ele gera todos os dias. O monitoramento de domínio designa esse trabalho de leitura contínua, dividido em 4 eixos: os relatórios DMARC, os registros DNS (MX, SPF, DKIM), a data de expiração do domínio e os domínios similares registrados por terceiros. Sem ele, uma equipe de growth descobre o problema depois do fato, quando o CMO pergunta por que a taxa de abertura caiu. Um caso clássico circula nos fóruns de email marketing: uma sender reputation que despenca 30% em três meses sem que nenhum conteúdo de campanha tenha mudado. A causa quase sempre é um registro DNS alterado sem que ninguém percebesse.
Os 4 eixos do monitoramento de domínio
Um domínio mal monitorado perde o controle em 4 frentes ao mesmo tempo, raramente apenas uma. A primeira envolve os relatórios DMARC agregados (RUA), que chegam diariamente a uma caixa de e-mail dedicada e que poucas equipes abrem. A segunda cobre os próprios registros DNS: SPF, DKIM e o registro DMARC podem ser alterados por um prestador externo ou um script de migração, sem que nenhum alerta seja disparado. O terceiro eixo trata da expiração do domínio, assunto administrativo que ninguém quer assumir. O quarto envolve os domínios que se parecem com o seu por apenas um caractere de diferença, registrados para enganar seus clientes por meio de usurpação; explicamos o mecanismo dessa ameaça mais adiante. O monitoramento de domínio não bloqueia nenhum ataque sozinho. Ele dispara o alerta cedo, nas 4 frentes ao mesmo tempo.
Ler os relatórios DMARC em vez de apenas publicá-los
Um registro DMARC em p=none não rejeita nem coloca em quarentena nenhuma mensagem. Ele dispara o envio de relatórios agregados (RUA), em formato XML, em média uma vez por dia, por cada provedor que recebe e-mail assinado pelo seu domínio: Gmail, Outlook, Yahoo, além dos servidores corporativos que aplicam DMARC. Os relatórios forenses (RUF), por sua vez, detalham uma mensagem individual que falhou. O Google não os envia mais. Microsoft e Yahoo ainda o fazem de forma intermitente. Decodificar os campos de um relatório agregado (IP de origem, alinhamento SPF/DKIM, disposição aplicada pelo servidor receptor) é um exercício técnico à parte, que detalhamos em nosso artigo sobre como ler um relatório DMARC agregado sem errar. Aqui, o ponto prático se resume a uma frase: sem leitura regular, a política permanece travada em p=none. É o caso da maioria dos domínios protegidos no mundo, por falta de alguém para vasculhar o fluxo XML e fazer a política avançar para p=quarantine e depois p=reject.
Detectar uma alteração DNS não autorizada em MX, SPF, DKIM, DMARC
Ferramentas como MXToolbox, CaptainDNS ou DNS Assistant consultam a zona DNS em intervalos regulares e disparam um alerta por e-mail ou Slack assim que um registro MX, SPF, DKIM ou DMARC muda de valor, após comparação com o valor anterior. A diferença entre o valor antigo e o novo aparece no alerta, o que evita refazer um diagnóstico completo a cada incidente. Um registro SPF que ultrapassa o limite de 10 consultas DNS falha sem bounce nem alerta visível do lado do remetente, um cenário detalhado em nosso artigo sobre o limite SPF de 10 consultas DNS. Um registro DKIM removido após uma migração de hospedagem quebra da mesma forma a assinatura de todos os e-mails enviados; o único sintoma visível às vezes é um NDR (non-delivery report) exibindo o Enhanced Status Code 5.7.1, sem ligação evidente com a mudança de DNS ocorrida no dia anterior. Uma transição protocolar planejada, como a retirada da tag pct prevista pelo DMARCbis, produz esse mesmo tipo de mudança aparentemente suspeita, mas legítima: comparar antes e depois continua sendo mais confiável do que reagir às cegas. Nada para conferir todo dia numa stack já sobrecarregada de alertas: esses serviços rodam em segundo plano e só emitem um sinal quando um valor realmente muda. Um único caso justifica a instalação. O domínio raramente muda de configuração DNS depois de estabilizado. Quando muda, é quase sempre uma alteração intencional de alguém da equipe. O monitoramento serve para identificar aquela que nenhum ticket interno anuncia, a pista mais comum por trás de um registro sequestrado sem comprometimento da conta do registrador, um cenário documentado por Infoblox e Eclypsium sob o nome Sitting Ducks.
Quase 800 mil domínios vulneráveis identificados e mais de 30 mil sequestros confirmados desde 2019, sem que nenhuma conta de registrador tenha sido comprometida (Infoblox e Eclypsium, 2024).
Monitorar a expiração e a renovação do domínio
O ciclo que segue uma expiração tem três fases: um período de carência de cerca de 30 dias em que a renovação continua simples, um período de resgate de cerca de 30 dias com multa de 80 a 200 euros, e depois uma janela de exclusão final de 5 a 15 dias antes da recolocação à venda pública. 13% dos nomes de domínio corporativos expirados são reregistrados por terceiros, segundo pesquisas internas da CSC publicadas em 2024. Esse número sobe para os domínios antigos deixados no ponto cego de um portfólio de marca nunca auditado após uma fusão ou troca de fornecedor. Um domínio perdido nesse estágio leva junto o site e os endereços de e-mail corporativos. Também apaga o posicionamento no Google acumulado ao longo de vários anos.
Identificar domínios similares e o typosquatting
Um domínio copiado com um caractere de diferença (troca de um l por um i maiúsculo, adição de um hífen, extensão .co em vez de .com) já basta para montar uma página de phishing convincente ou um endereço de envio que engana um cliente apressado. Mais de 30 mil domínios lookalike imitando marcas conhecidas foram registrados entre fevereiro e julho de 2024 pela Zscaler ThreatLabz, dos quais mais de 10 mil identificados como maliciosos. Só em março de 2025, mais de 26 mil domínios usurpando marcas ou serviços públicos foram detectados pela Palo Alto Networks Unit 42 em campanhas de smishing. O mecanismo técnico dessa usurpação, a forma como um atacante falsifica o remetente de um e-mail, está detalhado em nosso artigo dedicado ao email spoofing. A detecção antecipada, antes do envio da primeira campanha fraudulenta, limita os danos. Um serviço de monitoramento de variantes do nome da marca ajuda a fechar essa lacuna.
Frequência de verificação recomendada por eixo
| Eixo monitorado | Frequência recomendada | Sinal de disparo | Ação se houver alerta |
|---|---|---|---|
| Relatórios DMARC (RUA) | Leitura semanal | IP de origem não identificado, alinhamento SPF/DKIM com falha | Identificar o remetente, ajustar o SPF ou avançar a política para p=quarantine |
| Registros DNS (MX, SPF, DKIM) | Monitoramento contínuo com alerta automático | Valor alterado sem mudança planejada | Comparar antigo/novo, restaurar se não autorizado |
| Expiração do domínio | Verificação trimestral do portfólio | Renovação inferior a 60 dias | Ativar a renovação automática e o bloqueio do registrador |
| Domínios similares / typosquatting | Monitoramento mensal | Registro de uma variante próxima ao nome da marca | Denúncia ao registrador, procedimento UDRP se o uso fraudulento for confirmado |
Esse ritmo funciona na maioria das configurações observadas em domínios já estabilizados. Um domínio que acabou de migrar para um novo prestador de emailing justifica uma leitura diária de DMARC no primeiro mês, até que o alinhamento SPF e DKIM se estabilize na nova infraestrutura.
O que o monitoramento de domínio não cobre
A causa de uma queda na deliverability às vezes aponta para outro lugar além do domínio: quase sempre para a própria lista, com uma taxa de hard bounce em alta e endereços catchall acumulados ao longo das importações. Um domínio pode estar perfeitamente monitorado (DMARC lido, DNS estável, renovação antecipada, nenhuma variante de typosquatting detectada) e ainda assim ver sua deliverability cair. O complaint rate também sobe, visível através dos feedback loops de vários provedores de caixa de entrada. Esses sinais degradam a reputação do remetente da mesma forma que um registro SPF quebrado. Nenhuma ferramenta de monitoramento DNS os detecta, e o equivalente da Microsoft ao Postmaster do Gmail (SNDS, Smart Network Data Services, menos consultado, mas igualmente revelador) também não cobre a qualidade dos endereços enviados. A única forma de saber se a lista se deteriorou junto com o DNS é passá-la a limpo antes do próximo envio, em vez de descobrir o problema num painel depois que a reputação já caiu.
O padrão BIMI, que exibe o logotipo do remetente na caixa de entrada, exige um DMARC em p=reject estável há várias semanas para ser ativado na maioria dos provedores. Poucos domínios ainda atendem a essa condição em 2026.
