Spoofar um domínio corporativo continua sendo o primeiro passo do phishing dirigido contra clientes, fornecedores e auditores. O problema raramente é publicar DMARC: é parar em p=none, a política que coleta relatórios mas não bloqueia nada, deixando mensagens falsificadas chegarem à caixa de entrada. Times de infraestrutura, segurança e prevenção a fraudes precisam concluir o ciclo completo — inventariar remetentes, endurecer a política por degraus e alcançar p=reject em todos os domínios de segundo nível — para transformar a falsificação de identidade em um erro barato de detectar.
A referência operacional mais sólida vem do governo federal americano. A diretiva de segurança de e-mail do CISA obrigou agências federais a publicar, em todos os domínios, registros SPF/DMARC válidos com no mínimo p=none e um endereço para receber relatórios agregados e de falha, e definiu o prazo de um ano para chegar à política reject também nos hosts de envio. A justificativa técnica da agência é direta: p=quarantine ainda entrega a mensagem na pasta de lixo eletrônico, onde o usuário pode encontrá-la e ser enganado; só o reject bloqueia a entrega por completo, no servidor receptor, antes da caixa de entrada.
Por que parar em p=none
A política p=none existe para uma função só: telemetria. Enquanto ela estiver publicada, todo servidor receptor que respeita DMARC devolve relatórios agregados mostrando quem envia e-mail em nome do domínio — incluindo invasores e sistemas legítimos esquecidos. O que p=none não faz é proteger alguém: a mensagem não autenticada é entregue do mesmo jeito. p=quarantine melhora ao mandar o e-mail suspeito para o spam, mas a mensagem continua entregue, e campanhas dirigidas instruem a vítima a procurar o e-mail na pasta de lixo. O endurecimento real é uma decisão de política publicada em DNS, não um ajuste de antispam no gateway: sem reject, o domínio segue emprestando a própria reputação a qualquer falsificador.
Essa camada também não resolve tudo. DMARC autentica o remetente, não o conteúdo: uma mensagem perfeitamente autenticada ainda pode carregar um link de phishing. Por isso o controle trabalha em conjunto com a autenticação resistente de usuários e com a substituição do elo humano por chaves, como detalhamos nas análises sobre phishing resistente com vínculo de origem e sobre o que muda quando o phishing passa a usar IA.
Inventário antes da política
O erro clássico é apertar a política antes de saber quem envia e-mail legítimo. O caminho recomendado pela própria CISA é inverso: publique p=none com destinatário de relatórios (rua) ativo, aguarde ciclos completos de envio — folha de pagamento, faturamento, monitoramento, CRM, marketing — e só depois classifique cada fonte. O relatório agregado mostra, remetente por remetente, se a mensagem passa por SPF, por DKIM e, o mais decisivo, se existe alinhamento entre o domínio visível no cabeçalho From e o domínio autenticado. Sem esse cruzamento, a política bloqueia exatamente o e-mail que o negócio precisa entregar.
O alinhamento merece atenção redobrada em quem usa provedores de nuvem. A orientação do NCSC é proteger todos os domínios da organização, inclusive quando o e-mail fica hospedado em provedores como Google G Suite e Microsoft O365, porque a simples contratação do provedor não publica SPF, DKIM e DMARC por você — cada domínio precisa dos três controles configurados e verificados. Domínios antigos, marcas de campanha e endereços de eventos costumam ficar fora do inventário e são justamente os mais explorados em falsificação, porque ninguém monitora o que enviam em seu nome.
Dois detalhes de engenharia economizam semanas de retrabalho: encaminhadores de e-mail quebram SPF por natureza, já que o teste passa a falhar no servidor final, o que torna a assinatura DKIM com alinhamento relaxado indispensável para mensagens repassadas; e toda ferramenta nova de SaaS que envia “como” o domínio precisa ser incorporada ao SPF e assinada por DKIM antes de entrar em produção, não depois de derrubar a entregabilidade.
Suba por degraus até reject
O DMARC foi desenhado para implantação cautelosa: além dos três estados de política, o registro oferece o parâmetro pct, que aplica a regra a uma fração das mensagens e permite validar o comportamento com risco controlado. A progressão abaixo resume a sequência que reduz a chance de bloquear e-mail legítimo:
| Etapa | Ação | Verificação |
|---|---|---|
| 1 — Observação | Publicar DMARC p=none com rua para caixa monitorada | Relatórios agregados chegando; nenhuma ação de bloqueio |
| 2 — Autenticação | Incluir remetentes legítimos no SPF e assinar DKIM com alinhamento | Origens críticas passando por SPF ou DKIM alinhado |
| 3 — Quarentena parcial | Migrar para p=quarantine com pct em rampa (10, 50, 100) | Falhas legítimas zeradas nos relatórios antes de cada aumento |
| 4 — Bloqueio | Publicar p=reject, sem sp= mais fraco no domínio principal | Teste externo de spoof retornando falha de entrega |
| 5 — Contínuo | Ler relatórios semanalmente e revisar a cada nova ferramenta | Nenhum remetente novo sem autenticação em produção |
O degrau que as equipes pulam é o terceiro: a rampa de pct existe para descobrir o remetente esquecido bloqueando 10% das mensagens, e não 100% delas. Se a quarentena parcial estabilizar sem perdas legítimas, o reject deixa de ser um salto de fé para ser a conclusão natural do processo — com o histórico de relatórios servindo de evidência para a aprovação da mudança.
Domínios que nunca enviam e-mail
A vitória mais rápida do programa está fora da caixa postal principal. Domínios de marca, redirecionadores e endereços de landing page normalmente não enviam nada — e, sem política publicada, aceitam ser falsificados à vontade. Para esses casos, o CISA recomenda ir direto ao ponto: publicar DMARC p=reject e um registro SPF nulo em DNS, que declara aos receptores que aquele domínio não envia mensagens. Como não existe usuário legítimo para proteger, não há rampa, relatório nem risco operacional: qualquer e-mail que alegue vir dali deve morrer no servidor receptor, protegendo a reputação da marca e o destinatário final.
Sinais a monitorar
Três indicadores mostram se a política está madura para o próximo degrau: a taxa de mensagens legítimas falhando em SPF ou DKIM alinhado, que deve tender a zero antes de qualquer endurecimento; o volume de fontes desconhecidas nos relatórios agregados, em que cada pico indica ferramenta nova ou abuso em curso; e a presença de encaminhadores legítimos, que dependem de DKIM para sobreviver à política. Uma queda súbita na entregabilidade após um aumento de pct não é motivo para recuar sem dado: é motivo para abrir o relatório de falha e identificar o remetente específico afetado.
Externamente, vale validar o resultado com um verificador independente, como o serviço gratuito de checagem de segurança de e-mail do NCSC, que testa se o domínio está configurado conforme as diretrizes publicadas pela própria entidade britânica.
Ações priorizadas P1 e P2
P1 — nesta semana: publicar DMARC p=none com rua ativo em todos os domínios da organização; aplicar p=reject imediato nos domínios que não enviam e-mail; designar um responsável por ler os relatórios agregados a cada ciclo.
P2 — nos próximos 60 dias: corrigir o alinhamento dos remetentes críticos (folha de pagamento, faturamento, monitoramento, CRM); iniciar a rampa de quarentena com pct; revisar encaminhadores e garantir assinatura DKIM; programar a publicação do p=reject no domínio principal com base no histórico acumulado.
Se a organização ainda discute se vale a pena, o argumento de fechamento é simples: a falsificação de domínio é o vetor de phishing mais barato de neutralizar no portfólio de controles, e a política reject é o único estado em que a neutralização acontece no servidor receptor, sem depender do julgamento do destinatário.