2,77 bilhões de dólares. É o que o FBI contabilizou em perdas de Business Email Compromise para o ano de 2024, segundo o relatório anual IC3. Uma fração desses ataques foi bem-sucedida mesmo quando as organizações alvo tinham DMARC implementado. Isso não é um paradoxo: DMARC protege apenas contra uma forma específica de falsificação, e os atacantes sabem disso. Compreender suas limitações exatas (aquelas que a RFC 7489 documenta ela mesma) é a condição para não superestimar sua cobertura real.
O que o DMARC faz (e nada mais)
DMARC (Domain-based Message Authentication, Reporting and Conformance) é um protocolo que se baseia em SPF e DKIM para fornecer instruções aos servidores de e-mail receptores: rejeitar, colocar em quarentena ou entregar e-mails cuja identidade de domínio não pode ser verificada. Com uma política p=reject, qualquer mensagem cujo cabeçalho From não corresponda a uma fonte autorizada por SPF ou DKIM é bloqueada. Essa proteção é real. Mas seu alcance é estritamente limitado à falsificação exata do domínio. A RFC 7489 escreve em preto e branco: «DMARC não aborda o uso de nomes de domínio visualmente semelhantes nem o abuso do display name legível por humanos.» Cinco vetores de ataque comuns permanecem fora de alcance.
A falsificação do display name escapa completamente
Um e-mail cujo cabeçalho exibe «Serviço ao Cliente da Amazon <phishing@n0treal.com>» passa pelo DMARC sem problemas. DMARC verifica apenas o domínio técnico do remetente, não o nome exibido no cliente de e-mail. O atacante mantém um nome de remetente idêntico a uma marca de confiança enquanto utiliza seu próprio domínio, corretamente autenticado. Para o usuário final, a linha «De:» exibe exatamente o que o atacante decidiu colocar ali. Este vetor não requer nenhuma infraestrutura comprometida e contorna todos os controles de DMARC por definição: o domínio técnico não é falsificado, ele é simplesmente não relacionado ao nome exibido.
Domínios semelhantes não são afetados
DMARC protege example.com. Ele não diz nada sobre examp1e.com, example-support.com ou example.fr. Esses chamados domínios «primos» (typosquatting, domínios parecidos) podem publicar seu próprio registro DMARC válido, com SPF e DKIM corretamente configurados, e enviar e-mails perfeitamente autenticados de um domínio que se assemelha muito ao de uma organização legítima. O problema é documentado pelo PowerDMARC: estes domínios «frequentemente contornam o escopo do DMARC» porque o protocolo não tem controle sobre o que não controla. A vigilância dos domínios primos registrados pertence a outras categorias de ferramentas: monitoramento de marca, vigilância de DNS, análise de certificados SSL recentemente emitidos.
Uma conta comprometida passa pelo DMARC sem alarme
Se um atacante acessa uma caixa de e-mail legítima via stuffing de credenciais, phishing inicial ou vazamento de dados, todas as suas mensagens saindo passam por SPF, DKIM e DMARC normalmente. A mensagem vem do domínio correto, assinada com a chave DKIM correta, a partir de um IP autorizado. DMARC não distingue entre um funcionário legítimo e um atacante que roubou suas credenciais. Este é precisamente o modus operandi do BEC (Business Email Compromise): os 2,77 bilhões de dólares em perdas registradas pelo FBI em 2024 referem-se a ataques onde a infraestrutura de e-mail das vítimas muitas vezes estava configurada corretamente. DMARC não viu nada porque tecnicamente não havia nada para ver.
O encaminhamento de e-mails pode quebrar a autenticação
Quando uma mensagem passa por um serviço intermediário (alias corporativo, lista de discussão como Mailman ou Listserv, redirecionamento automático), o SPF falha quase sistematicamente: o IP do relé não está listado no registro SPF do domínio de origem. Se a lista de discussão modifica o corpo da mensagem (rodapé adicionado, aviso inserido), o DKIM também pode falhar. E-mails perfeitamente legítimos acabam rejeitados ou colocados em quarentena. Segundo a dmarcian, 21% das falhas de DMARC observadas nos relatórios agregados são provenientes dessa quebra do DKIM por modificação de conteúdo. A solução padrão é o ARC (Authenticated Received Chain), mas ele requer uma configuração explícita no lado do relé. A maioria das listas de discussão ainda não a implementou.
Subdomínios podem continuar sendo pontos cegos
Um registro DMARC publicado em example.com não protege automaticamente todos os seus subdomínios. Por padrão, mail.example.com ou newsletter.example.com herdam a política do domínio pai, a menos que exista um registro DMARC específico para esse subdomínio, caso em que é este último que prevalece, mesmo que esteja em p=none. Um subdomínio esquecido configurado para monitoramento anula a proteção p=reject do domínio principal para esse escopo. Valimail indica que mais de 80% dos domínios não possuem uma política DMARC rígida; entre os que têm, a coerência entre o domínio principal e os subdomínios raramente é verificada de maneira sistemática. Os domínios «parking» não utilizados também permanecem como superfícies disponíveis para falsificação.
DMARC em uma estratégia realista
Essas cinco limitações não tornam o DMARC inútil. Em novembro de 2025, o Gmail começou a rejeitar e-mails em massa não conformes, e Valimail estima que a aplicação do DMARC eliminou 265 bilhões de mensagens não autenticadas em 2024. É uma base necessária. Mas é apenas uma base. Uma cobertura realista também requer: uma solução capaz de analisar o display name e detectar domínios primos, uma proteção contra a compromissão de contas (MFA obrigatório, detecção de anomalias comportamentais), uma configuração ARC para fluxos de transferência legítimos, e uma auditoria regular dos subdomínios, incluindo aqueles considerados «inativos». O DMARC fecha uma porta. Antes de considerar o trabalho concluído, é preciso contar as outras.
