Roteamento de e-mail mal configurado: o alerta da Microsoft sobre o spoofing interno (janeiro de 2026)

⚡TL;DR

• A Microsoft revelou em janeiro de 2026 que as configurações MX que apontam para serviços de terceiros (antispam, arquivamento) criam um ponto cego explorado pelos atacantes para falsificar domínios internos
• A plataforma Tycoon2FA gerou 13 milhões de e-mails de phishing bloqueados pelo Defender em um único mês (outubro de 2025), explorando esse vetor combinado com ataques AiTM
• O trio SPF ~all + DKIM ausente + DMARC p=none deixa passar 100 % das tentativas de falsificação por roteamento MX indireto
• A análise forense dos cabeçalhos de e-mail revela o mecanismo exato: saltos inesperados na cadeia Received, spf=softfail, dkim=none, dmarc=fail action=none
• O plano de correção em 5 etapas: DMARC progressivo rumo a p=reject, SPF -all, DKIM ativado, conectores de terceiros auditados, MX direto para o Microsoft 365

Em janeiro de 2026, a equipe do Microsoft Defender for Office 365 publicou um alerta que abalou as equipes de segurança: milhares de organizações que usam o Microsoft 365 estavam vulneráveis a uma falsificação de identidade interna, não por causa de um bug de software, mas por causa da sua própria configuração DNS. O mecanismo é simples e devastador. Quando o registro MX de um domínio aponta para um serviço de terceiros (gateway antispam, solução de arquivamento, relay de filtragem) em vez de apontar diretamente para o Microsoft 365, os e-mails de entrada passam por um intermediário que não recalcula corretamente os resultados de autenticação SPF, DKIM e DMARC. Os atacantes entenderam isso e exploram essa falha em larga escala.

Não se trata de um cenário teórico. A Microsoft documentou que a plataforma de phishing-as-a-service Tycoon2FA gerou sozinha 13 milhões de e-mails maliciosos bloqueados pelo Defender em outubro de 2025. Esses e-mails exploravam o roteamento MX indireto combinado com técnicas de adversary-in-the-middle (AiTM) para roubar credenciais e cookies de sessão, mesmo de usuários protegidos pela autenticação multifator. As iscas utilizadas imitavam redefinições de senha, mensagens do RH e notificações de documentos compartilhados, enviados a partir do endereço interno da vítima para ela mesma.

Este artigo detalha o mecanismo técnico desse ataque, a análise forense dos cabeçalhos de e-mail que permite detectá-lo, um diagnóstico DNS em cinco minutos para saber se o seu domínio é vulnerável e um plano de correção completo.

O contexto: o que revela o alerta da Microsoft de janeiro de 2026?

Um problema de roteamento, não de protocolo

O alerta da Microsoft não trata de uma vulnerabilidade no SPF, DKIM ou DMARC em si. Esses protocolos funcionam exatamente como foram projetados. O problema está na arquitetura de roteamento dos e-mails.

Em uma configuração padrão, o registro MX de um domínio aponta diretamente para os servidores Exchange Online Protection (EOP) do Microsoft 365:

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Com essa configuração, o Microsoft 365 recebe os e-mails diretamente do remetente. Ele avalia o SPF verificando o IP de origem contra o registro SPF do domínio do envelope. Valida a assinatura DKIM. Aplica a política DMARC. Cada verificação é feita no contexto correto.

Mas milhares de organizações têm um MX que aponta para um serviço de terceiros:

captaindns.com.  IN  MX  10  mx.filtro-terceiros.com.

O serviço de terceiros recebe o e-mail, realiza seu processamento (antispam, arquivamento, análise de conteúdo) e depois transmite a mensagem para o Microsoft 365. O problema: quando o Microsoft 365 recebe a mensagem, o IP de origem é o do serviço de terceiros, não o do remetente original. O contexto de autenticação mudou.

O mecanismo de ataque em detalhe

O atacante explora essa cadeia da seguinte forma:

Etapa 1: reconhecimento. O atacante consulta o MX do domínio-alvo. Se o MX aponta para um serviço de terceiros em vez de *.mail.protection.outlook.com, o domínio é potencialmente vulnerável.

Etapa 2: verificação da postura de autenticação. O atacante verifica três registros DNS:

• _dmarc.captaindns.com: se a política é p=none, as falhas DMARC não provocam nenhuma ação
• captaindns.com (TXT SPF): se o mecanismo é ~all (softfail) em vez de -all (hardfail), a falha SPF é tolerada
• Seletores DKIM comuns: se nenhuma chave DKIM está publicada, o campo dkim=none não aciona nada

Etapa 3: envio do e-mail falsificado. O atacante envia um e-mail a partir de um servidor que ele controla. Coloca o mesmo endereço nos campos From e To: por exemplo, contabilidade@captaindns.com para contabilidade@captaindns.com. Esse "self-spoofing" dá a impressão de que a mensagem vem de um colega interno.

Etapa 4: trânsito pelo serviço de terceiros. O MX do domínio roteia o e-mail para o serviço de terceiros. Este realiza um primeiro nível de filtragem. O problema: muitos serviços de terceiros não verificam SPF/DKIM/DMARC de forma alguma, ou os verificam mas não propagam os resultados de maneira aproveitável pelo Microsoft 365.

Etapa 5: entrega no Microsoft 365. O Microsoft 365 recebe o e-mail a partir do IP do serviço de terceiros. Sem o mecanismo Enhanced Filtering for Connectors (EFC), o Exchange Online vê o IP do terceiro, não o IP do atacante. O SPF passa (porque o IP do terceiro está no SPF do terceiro) ou falha em softfail. O DKIM está ausente. O DMARC falha, mas a política p=none não provoca nenhum bloqueio. O e-mail chega à caixa de entrada.

Por que "skip authentication" é o ponto de ruptura

O problema fundamental é a configuração do conector de entrada no Exchange Online. Quando uma organização configura um conector para receber e-mails de um serviço de terceiros (Barracuda, Mimecast, Proofpoint, Sophos), o assistente de configuração frequentemente propõe "confiar" nos resultados de autenticação do terceiro, ou "pular a autenticação" para os IPs do conector. Na prática, muitos administradores ativam essa opção para evitar falsos positivos: se o terceiro já verificou SPF/DKIM/DMARC, por que repetir?

O problema: o Exchange Online deixa de verificar a autenticação contra a fonte original. Consome os cabeçalhos Authentication-Results inseridos pelo terceiro, ou pior, avalia o SPF sobre o IP do conector (o do terceiro) em vez do IP do remetente real. O cabeçalho Authentication-Results visível na caixa de entrada reflete os resultados vistos pelo terceiro, não os da fonte real.

A Microsoft introduziu o Enhanced Filtering for Connectors (EFC) para corrigir esse problema. O EFC pede ao Exchange Online para percorrer a cadeia Received de volta para identificar o IP do remetente original, pulando os IPs conhecidos do serviço de terceiros (a "skip list"). Mas o EFC não está ativado por padrão. As organizações que não configuraram o EFC, ou que o configuraram com uma skip list incompleta, continuam vulneráveis.

O self-spoofing: o e-mail interno que não é

O golpe de misericórdia desse ataque é o self-spoofing. O atacante coloca o mesmo domínio nos campos From e To: rh@captaindns.com envia para joao.silva@captaindns.com. Para o destinatário, o e-mail parece vir de um colega. Mas o mecanismo é mais insidioso: muitas organizações configuram regras de transporte do Exchange que tratam os e-mails "internos" de forma diferente. Um e-mail cujo domínio From é um domínio interno pode não receber o banner "Este e-mail é de um remetente externo", não estar sujeito aos mesmos filtros antiphishing e ser exibido sem aviso visual. O atacante explora não apenas a confiança humana, mas também as exceções de segurança configuradas para as comunicações internas.

O papel crítico do serviço de terceiros

O problema central é que o serviço de terceiros age como um "branqueador" involuntário de autenticação. Quando retransmite a mensagem para o Microsoft 365, substitui o contexto de autenticação original:

• O IP de origem muda. O Microsoft 365 vê o IP do serviço de terceiros, não o do atacante. A verificação SPF é feita sobre o IP errado.
• Os cabeçalhos Authentication-Results do terceiro não são confiáveis. O Microsoft 365 não tem motivo para confiar nos resultados de autenticação inseridos pelo terceiro.
• O Return-Path pode ser reescrito. Alguns serviços de terceiros reescrevem o envelope SMTP, confundindo ainda mais as pistas.

A Microsoft documentou que mesmo os serviços de terceiros que verificam corretamente SPF/DKIM/DMARC e inserem os cabeçalhos corretos não resolvem o problema se o Microsoft 365 não sabe olhar além do IP do terceiro para encontrar o IP do remetente original.

É exatamente o problema que o Enhanced Filtering for Connectors resolve: ele permite ao Exchange Online "pular" o IP do terceiro na cadeia Received e avaliar a autenticação sobre o IP real do remetente.

Qual é a dimensão do problema?

O roteamento MX indireto não é uma configuração marginal. Segundo os dados publicados pelas equipes de segurança da Microsoft, uma proporção significativa dos tenants do Microsoft 365 utiliza um serviço de terceiros na frente do Exchange Online. As razões são múltiplas e frequentemente históricas:

• Herança de migração: muitas organizações migraram para o Microsoft 365 a partir de uma hospedagem on-premise. Já tinham um serviço antispam de terceiros (Barracuda, Mimecast, Proofpoint, Sophos) e mantiveram o roteamento existente durante a migração.
• Requisitos regulatórios: certos setores (finanças, saúde, administração pública) exigem um arquivamento ou filtragem de e-mails por um serviço de terceiros certificado. O roteamento MX indireto é o meio técnico habitual para atender a esse requisito.
• Estratégia de defesa em profundidade: algumas equipes de segurança consideram que empilhar duas camadas de filtragem (terceiros + Defender) oferece melhor proteção. Isso é verdade para a filtragem antispam, mas o custo em termos de autenticação raramente é medido.
• Desconhecimento do risco: antes do alerta de janeiro de 2026, a relação entre roteamento MX indireto e enfraquecimento da autenticação de e-mail não era amplamente documentada. A maioria dos guias de implantação de serviços de terceiros não menciona o impacto no SPF/DKIM/DMARC do lado do Microsoft 365.

O resultado: organizações que investem em segurança de e-mail (compra de um serviço antispam premium, implantação de DMARC) acabam paradoxalmente mais vulneráveis do que as que usam apenas o Defender com um MX direto.

Tycoon2FA: a plataforma PhaaS que explora essa falha

Um serviço de phishing pronto para uso

A Tycoon2FA é uma plataforma de phishing-as-a-service (PhaaS) ativa desde agosto de 2023, identificada e documentada pela Sekoia.io e pelo Threat Intelligence Center da Microsoft. Funciona como um SaaS para cibercriminosos: os operadores pagam uma assinatura (cerca de 120 dólares por mês em canais dedicados no Telegram) e recebem em troca uma infraestrutura completa de phishing com painéis de controle, modelos de e-mails, páginas de login clonadas e coleta automatizada de credenciais. A barreira de entrada é quase nula: nenhuma competência técnica é necessária, o kit fornece tudo, do domínio de phishing à página de captura.

A dimensão da operação é massiva. Segundo as estimativas consolidadas das equipes de Threat Intelligence da Microsoft e da Sekoia.io, a Tycoon2FA gera mais de 30 milhões de e-mails de phishing por mês por meio do conjunto dos seus operadores. A Microsoft informou ter bloqueado 62 % dos e-mails de phishing direcionados aos seus usuários no primeiro semestre de 2025, mas o volume restante basta para comprometer milhares de contas. Em março de 2026, a Europol tentou desmantelar a infraestrutura da Tycoon2FA no âmbito de uma operação coordenada. A plataforma voltou a operar em 48 horas, tendo migrado seus servidores para novas jurisdições.

O que distingue a Tycoon2FA dos kits de phishing clássicos é sua capacidade de contornar a autenticação multifator (MFA) por meio de uma técnica de adversary-in-the-middle (AiTM).

O mecanismo AiTM em detalhe

O funcionamento técnico se baseia em um proxy reverso transparente. O ponto crucial: a MFA não protege contra esse ataque porque o proxy não intercepta o segundo fator em si. Ele intercepta o cookie de sessão emitido pelo Microsoft 365 após o usuário ter completado com sucesso toda a cadeia de autenticação, MFA inclusa. A vítima se autentica normalmente, na infraestrutura real da Microsoft, mas o token de sessão é capturado em trânsito.

Aqui está o desenvolvimento completo:

1. A vítima recebe um e-mail de phishing que falsifica um domínio interno por meio do mecanismo de roteamento MX descrito anteriormente.
2. O link no e-mail passa por uma cadeia de redirecionamentos. A Microsoft documentou o uso de redirecionamentos via Google Maps (maps.google.com/url?q=...) para contornar os filtros de reputação. A técnica é devastadora: os filtros de e-mail inspecionam o domínio do link, veem maps.google.com (um domínio confiável com reputação máxima) e deixam passar. O parâmetro q= contém a URL real da página de phishing, mas os filtros não decodificam sistematicamente os redirecionamentos aninhados. A URL final leva a uma página de phishing hospedada em um domínio efêmero.
3. A página de phishing age como um proxy transparente para a verdadeira página de login do Microsoft 365. O servidor Tycoon2FA se posiciona entre o navegador da vítima e login.microsoftonline.com. Visualmente, a vítima vê uma interface de login idêntica à da Microsoft, com o logotipo da organização, as cores personalizadas e o branding do Entra ID.
4. A vítima insere seu identificador e sua senha. O proxy transmite as credenciais para o Microsoft 365 em tempo real. A Microsoft as valida normalmente.
5. O Microsoft 365 solicita o segundo fator (MFA). O proxy retransmite a solicitação MFA para a vítima. A vítima insere seu código TOTP ou aprova a notificação push. Do ponto de vista da Microsoft, a autenticação é legítima.
6. O proxy captura o cookie de sessão. Uma vez completada a autenticação, o Microsoft 365 emite um cookie de sessão. O proxy o intercepta antes de transmiti-lo à vítima. A vítima recebe um cookie válido e acessa seu e-mail normalmente, sem suspeitar de nada.
7. O atacante usa o cookie de sessão roubado para acessar a conta a partir de outro navegador, sem precisar passar novamente pela MFA. O cookie é válido durante a duração da sessão (frequentemente 24 horas ou mais, dependendo da política da organização). O atacante pode ler os e-mails, exfiltrar arquivos do OneDrive, enviar e-mails em nome da vítima e se propagar lateralmente na organização.

Os números documentados pela Microsoft

Os dados publicados pela Microsoft em seu boletim de janeiro de 2026 revelam a dimensão da exploração:

Métrica	Valor
E-mails maliciosos bloqueados pelo Defender (outubro de 2025)	13 milhões
Plataforma PhaaS principal identificada	Tycoon2FA
Técnica de contorno de MFA	Adversary-in-the-middle (AiTM)
Técnica de ofuscação de URL	Redirecionamentos Google Maps
Principais iscas	Redefinição de senha, mensagens do RH, documentos compartilhados
Vetor de entrada	Roteamento MX indireto + SPF ~all + DKIM ausente + DMARC p=none

Esses 13 milhões de e-mails dizem respeito unicamente às mensagens bloqueadas pelo Defender. As organizações sem Defender for Office 365, ou com configurações de filtragem menos rigorosas, não se beneficiaram dessa proteção.

As iscas utilizadas

As campanhas da Tycoon2FA documentadas pela Microsoft exploram cenários com alta urgência percebida:

• Redefinição de senha: "Sua senha expira em 24 horas. Clique aqui para renová-la." O link leva à página AiTM.
• Mensagens do RH: "Novo documento para assinar para a atualização do seu contrato." O anexo ou o link redireciona para a página de phishing.
• Documentos compartilhados: "Maria Silva compartilhou um arquivo com você no OneDrive." O e-mail imita uma notificação legítima do SharePoint.
• Self-spoofing: nos casos mais sofisticados, o endereço From é idêntico ao endereço To. A vítima recebe um e-mail que parece vir dela mesma ou de um colega do mesmo domínio.

O self-spoofing é particularmente eficaz porque os usuários confiam nos e-mails que vêm do seu próprio domínio. Um e-mail de rh@captaindns.com recebido por um funcionário da captaindns.com não aciona nenhum alerta humano.

Análise forense dos cabeçalhos: detectar o ataque

Quando um e-mail suspeito chega a uma caixa de entrada do Microsoft 365, os cabeçalhos contêm as provas do roteamento anormal. Veja a seguir como lê-los com um analisador de cabeçalhos de e-mail.

Exemplo de cabeçalhos de um e-mail falsificado

Este é um exemplo realista anonimizado de cabeçalhos provenientes de um e-mail de phishing que explora o roteamento MX indireto. Todos os sinais de alerta estão presentes simultaneamente:

Return-Path: <bounce@malicious-relay.net>
Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP; Thu, 9 Jan 2026 08:15:23 +0000
Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS; Thu, 9 Jan 2026 08:15:21 +0000
Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP; Thu, 9 Jan 2026 08:15:19 +0000
Authentication-Results: mail-protection.captaindns.com;
 spf=softfail (sender IP is 198.51.100.77) smtp.mailfrom=captaindns.com;
 dkim=none (message not signed);
 dmarc=fail action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 5
From: Direção de RH <rh@captaindns.com>
To: joao.silva@captaindns.com
Subject: Documento de política de RH para assinar - Ação necessária

Análise linha por linha

Return-Path: <bounce@malicious-relay.net>

O Return-Path revela o endereço de retorno real. O domínio malicious-relay.net não tem nenhuma relação com captaindns.com. Essa discrepância entre o Return-Path e o From exibido (rh@captaindns.com) é o primeiro sinal de alerta. Em um e-mail legítimo enviado a partir do Microsoft 365, o Return-Path contém o domínio da organização ou um subdomínio de protection.outlook.com. Aqui, é a infraestrutura do atacante que aparece.

Cadeia Received (lida de baixo para cima):

Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP

Primeiro salto: o e-mail parte de um IP desconhecido (198.51.100.77) identificado como unknown pelo serviço de terceiros. É o servidor do atacante. A ausência de resolução DNS reversa (sem nome de host verificado) é um sinal forte: servidores de e-mail legítimos têm um registro PTR configurado. O uso de SMTP simples (não ESMTPS) confirma que o remetente não suporta criptografia TLS, o que é anormal para um servidor empresarial em 2026.

Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS

Segundo salto: o serviço de terceiros (gateway.thirdparty-filter.com) retransmite para o Exchange Online. É esse IP (203.0.113.50) que o Microsoft 365 vê como origem. O contexto de autenticação é avaliado sobre esse IP, não sobre 198.51.100.77. O serviço de terceiros aceitou a mensagem e a transmitiu.

Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP

Terceiro salto: roteamento interno do Microsoft 365 para a caixa de entrada. Os endereços IP em 10.x.x.x confirmam um roteamento interno. Esse salto é normal.

Authentication-Results: a tripla falha

Essa é a linha mais reveladora, e contém três falhas simultâneas:

• spf=softfail (sender IP is 198.51.100.77): o IP de origem real (198.51.100.77, o servidor do atacante) não está no SPF de captaindns.com. Com um mecanismo ~all, é um softfail, não um reject. O softfail é tratado como um aviso, não como um bloqueio.
• dkim=none (message not signed): nenhuma assinatura DKIM está presente. O atacante não possui a chave privada DKIM de captaindns.com, então não pode assinar. O serviço de terceiros também não adicionou uma assinatura. A ausência de DKIM priva o DMARC de seu segundo vetor de alinhamento.
• dmarc=fail action=none: o DMARC falha (nem SPF nem DKIM passam com alinhamento de domínio). Mas action=none significa que a política DMARC do domínio é p=none, portanto nenhuma ação é tomada apesar da falha. O e-mail é entregue normalmente.

X-MS-Exchange-Organization-SCL: 5

O Spam Confidence Level (SCL) está em 5 em uma escala de 0 a 9. Um SCL de 5 indica um nível de suspeita moderado. Por padrão, o Exchange Online coloca em quarentena as mensagens com SCL de 6 ou mais. Um SCL de 5 passa logo abaixo do limiar de bloqueio padrão. O Defender detectou sinais suspeitos (falhas de autenticação, Return-Path incoerente), mas não o suficiente para bloquear categoricamente com a configuração atual.

From e To no mesmo domínio: self-spoofing

O From exibe Direção de RH <rh@captaindns.com> e o To é joao.silva@captaindns.com. Mesmo domínio. No Outlook, o usuário vê um e-mail da "Direção de RH" com a foto e o cargo associados a rh@captaindns.com na lista de contatos. O banner "Este e-mail é de um remetente externo" pode estar ausente se a organização configurou exceções para os domínios internos.

Subject: Documento de política de RH para assinar - Ação necessária

O assunto combina duas alavancas psicológicas: a autoridade ("Direção de RH", "política de RH") e a urgência ("Ação necessária"). Esse tipo de isca é documentado pela Microsoft como um dos mais eficazes nas campanhas da Tycoon2FA.

Comparação com um e-mail legítimo

Para contrastar, aqui estão os cabeçalhos de um e-mail legítimo enviado a partir da mesma organização:

Return-Path: <rh@captaindns.com>
Authentication-Results: mail-protection.captaindns.com;
 spf=pass (sender IP is 40.107.22.83) smtp.mailfrom=captaindns.com;
 dkim=pass (signature was verified) header.d=captaindns.com;
 dmarc=pass action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 1
From: Direção de RH <rh@captaindns.com>
To: joao.silva@captaindns.com

As diferenças são nítidas: o Return-Path corresponde ao domínio From, o SPF passa com um IP da Microsoft (40.107.x.x), o DKIM passa com uma assinatura verificada, o DMARC passa e o SCL está em 1 (confiança alta). É o perfil típico de um e-mail legítimo.

O que o conjunto revela

Combinando esses elementos, o diagnóstico é claro:

1. O e-mail não provém da infraestrutura de captaindns.com (Return-Path em malicious-relay.net)
2. Ele transitou por um serviço de terceiros que não bloqueou a falsificação
3. Tripla falha de autenticação: SPF softfail, DKIM ausente, DMARC fail sem consequências
4. O SCL moderado indica que o Defender tem dúvidas, mas a configuração atual não permite o bloqueio
5. O self-spoofing (mesmo domínio em From e To) explora a confiança nas comunicações internas

Para detectar sistematicamente esse tipo de e-mail, analise seus cabeçalhos com um analisador de cabeçalhos e procure esses quatro marcadores: cadeia Received com salto inesperado a partir de um IP desconhecido, spf=softfail, dkim=none e dmarc=fail action=none.

Diagnóstico em 5 minutos: seu domínio é vulnerável?

Três comandos DNS são suficientes para avaliar sua exposição. Abra um terminal e execute as seguintes verificações.

Verificação 1: para onde aponta seu MX?

dig MX captaindns.com +short

Resultado seguro:

10 captaindns-com.mail.protection.outlook.com.

O MX aponta diretamente para o Microsoft 365. Os e-mails chegam sem intermediário. A autenticação é avaliada sobre o IP do remetente original.

Resultado em risco:

10 mx.filtro-terceiros.com.
20 mx2.filtro-terceiros.com.

O MX aponta para um serviço de terceiros. Todos os e-mails de entrada passam por esse intermediário antes de chegar ao Microsoft 365. Se o Enhanced Filtering for Connectors não estiver ativado, a autenticação é avaliada sobre o IP do terceiro.

Resultado misto (a verificar):

10 mx.filtro-terceiros.com.
20 captaindns-com.mail.protection.outlook.com.

O MX prioritário é o serviço de terceiros, mas o Microsoft 365 está como backup. Em funcionamento normal, todo o tráfego passa pelo terceiro. O risco é idêntico ao cenário anterior.

Verificação 2: qual é a sua política DMARC?

dig TXT _dmarc.captaindns.com +short

Resultado vulnerável:

"v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"

A política p=none significa que as falhas DMARC são relatadas, mas nenhuma ação é tomada sobre os e-mails. Combinada com um roteamento MX indireto, é uma porta aberta.

Resultado parcialmente protegido:

"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com"

A política p=quarantine envia para spam os e-mails que falham no DMARC, mas pct=50 significa que apenas metade dos e-mails está sujeita a essa política. A outra metade é tratada como se a política fosse p=none.

Resultado protegido:

"v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

A política p=reject solicita aos servidores de recepção que rejeitem os e-mails que falham no DMARC. É a proteção máxima.

Verificação 3: qual é o seu mecanismo SPF terminal?

dig TXT captaindns.com +short | grep spf

Resultado vulnerável:

"v=spf1 include:spf.protection.outlook.com ~all"

O mecanismo ~all (softfail) indica que os IPs não listados provavelmente não deveriam enviar em nome desse domínio, mas o resultado é um softfail, não um reject. Os servidores de recepção são livres para ignorá-lo.

Resultado protegido:

"v=spf1 include:spf.protection.outlook.com -all"

O mecanismo -all (hardfail) indica que qualquer IP não listado está explicitamente não autorizado. Os servidores de recepção que respeitam o SPF rejeitarão esses e-mails.

Matriz de vulnerabilidade

MX	DMARC	SPF	DKIM	Nível de risco
Terceiros	p=none	~all	Ausente	Crítico
Terceiros	p=none	-all	Ausente	Alto
Terceiros	p=quarantine	~all	Ausente	Alto
Terceiros	p=quarantine	-all	Ativo	Moderado
Terceiros	p=reject	-all	Ativo	Baixo (se EFC ativado)
Direto M365	p=reject	-all	Ativo	Mínimo

Se seu domínio se encontra nas linhas "Crítico" ou "Alto", a correção é urgente. Passe para a próxima seção.

Plano de correção em 5 etapas

Etapa 1: DMARC progressivo rumo a p=reject

Nunca passe diretamente de p=none para p=reject. A escalada progressiva evita bloquear e-mails legítimos cuja existência você desconhece (newsletters, SaaS, CRM que enviam em nome do seu domínio).

Fase 1: monitoramento (2 semanas no mínimo)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1"

A opção fo=1 solicita um relatório forense para cada falha individual (SPF ou DKIM), não apenas quando ambos falham. Analise os relatórios agregados (rua) para identificar todas as fontes de envio legítimas.

Fase 2: quarentena progressiva (2 semanas)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@captaindns.com"

Apenas 10 % dos e-mails que falham no DMARC são colocados em quarentena. Monitore os relatórios e as reclamações dos usuários.

Fase 3: quarentena completa (2 semanas)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@captaindns.com"

100 % das falhas são colocadas em quarentena. Se nenhum falso positivo for relatado, passe para a próxima fase.

Fase 4: reject progressivo (1 semana)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@captaindns.com"

10 % das falhas são rejeitadas, o restante permanece em quarentena.

Fase 5: reject completo

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

Proteção máxima. Todo e-mail que falha no DMARC é rejeitado pelo servidor de recepção.

O processo completo leva aproximadamente 7 a 9 semanas. Não encurte as fases: cada período de observação revela fontes de envio que você havia esquecido. Um serviço de faturamento SaaS, uma antiga ferramenta de marketing, um formulário de contato que envia por meio de um ESP não configurado no seu SPF.

Etapa 2: SPF em hardfail (-all)

Substitua ~all por -all no seu registro SPF:

captaindns.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Antes de modificar, verifique se todas as suas fontes de envio legítimas estão incluídas no registro SPF. Um hardfail combinado com uma fonte esquecida bloqueará e-mails legítimos.

Pontos de atenção:

• Número de lookups DNS: o SPF permite um máximo de 10 lookups DNS recursivos. Cada include: conta como um lookup, mais os aninhados. Acima de 10, o resultado é um permerror e a avaliação falha.
• Inclua todas as suas fontes: Microsoft 365, Google Workspace, ESP (Mailgun, SendGrid, Amazon SES), CRM (HubSpot, Salesforce), ferramentas de ticketing.
• Teste antes de publicar: utilize nossa ferramenta de verificação DMARC para validar sua configuração antes de colocá-la em produção.

Etapa 3: ativar o DKIM

O DKIM é a peça que falta na maioria das configurações vulneráveis. Sem DKIM, o DMARC só pode se apoiar no SPF para o alinhamento. Se o SPF falha (o que acontece sistematicamente em um cenário de roteamento indireto), o DMARC também falha.

No Microsoft 365:

1. Acesse o portal Defender (security.microsoft.com)
2. Navegue até Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > DKIM
3. Selecione seu domínio
4. Ative "Sign messages for this domain with DKIM signatures"
5. A Microsoft gera dois registros CNAME para publicar no seu DNS:

selector1._domainkey.captaindns.com.  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com.
selector2._domainkey.captaindns.com.  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com.

6. Publique os CNAMEs, aguarde a propagação DNS (geralmente de 15 a 30 minutos) e depois valide no portal Defender.

Com o DKIM ativo, mesmo que o SPF falhe por causa do roteamento indireto, o DMARC pode passar por meio do alinhamento DKIM, desde que o serviço de terceiros não modifique o corpo da mensagem nem os cabeçalhos assinados.

Etapa 4: auditar os conectores e ativar a filtragem aprimorada

O Enhanced Filtering for Connectors (EFC) é a solução técnica que a Microsoft recomenda para as organizações que precisam manter um roteamento MX indireto. O EFC permite ao Exchange Online "olhar além" do IP do serviço de terceiros para encontrar o IP do remetente original na cadeia Received.

Ativação no Exchange Online:

1. Acesse o Exchange Admin Center (admin.exchange.microsoft.com)
2. Navegue até Mail flow > Connectors
3. Identifique o conector de entrada do seu serviço de terceiros
4. Nas propriedades do conector, ative "Enhanced Filtering for Connectors"
5. Configure os IPs do serviço de terceiros para "pular" (skip listing)

Uma vez ativado o EFC, o Exchange Online percorre a cadeia Received de volta para encontrar o último IP externo antes do serviço de terceiros. A avaliação de SPF, DKIM e DMARC é feita sobre esse IP, restaurando o contexto de autenticação correto.

Pontos de atenção:

• Teste o EFC em modo auditoria antes de aplicá-lo em produção
• Certifique-se de que os IPs do serviço de terceiros na skip list estejam atualizados
• Verifique se o serviço de terceiros não reescreve os cabeçalhos Received de forma a impedir o EFC de encontrar o IP de origem

Etapa 5: considerar um MX direto para o Microsoft 365

A solução mais radical e eficaz é eliminar o intermediário. Se seu serviço de terceiros é usado para filtragem antispam, o Microsoft Defender for Office 365 (plano 1 ou plano 2) oferece capacidades equivalentes ou superiores:

• Exchange Online Protection (EOP): incluído em todas as licenças do Microsoft 365, fornece filtragem antispam e antimalware básica.
• Defender for Office 365 Plano 1: adiciona Safe Links (reescrita e análise de URLs em tempo real), Safe Attachments (detonação em sandbox) e antiphishing.
• Defender for Office 365 Plano 2: adiciona Threat Explorer, Automated Investigation and Response (AIR), Attack Simulation Training e Threat Trackers.

Se o serviço de terceiros é usado para arquivamento ou conformidade, existem soluções de arquivamento que funcionam a jusante (journal rules) sem exigir um roteamento MX indireto.

Para passar para MX direto:

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Remova as entradas MX antigas que apontam para o serviço de terceiros. Atualize seu SPF se necessário. Verifique se seus conectores do Exchange Online estão configurados corretamente.

Além da autenticação de e-mail: a questão da MFA

O roteamento MX indireto abre a porta para o phishing. Mas o alerta da Microsoft lembra que a Tycoon2FA não se limita a roubar senhas. A plataforma rouba sessões autenticadas, contornando a MFA. A correção do roteamento de e-mail não basta se sua MFA continua vulnerável aos ataques AiTM.

Por que a MFA clássica não protege mais

A MFA baseada em códigos TOTP (aplicativos de autenticação como Microsoft Authenticator em modo código, Google Authenticator) ou notificações push é vulnerável aos proxies AiTM. O mecanismo é estrutural: o código TOTP é um segredo compartilhado entre o usuário e o servidor. Se um proxy se posiciona entre os dois, captura o código em trânsito e o reproduz imediatamente. A notificação push é ainda mais fácil de explorar: o proxy aciona a solicitação de autenticação no servidor real, o usuário aprova no seu telefone e o proxy captura o cookie de sessão resultante.

Isso não significa que a MFA seja inútil. Ela continua protegendo contra credential stuffing, ataques de dicionário e vazamentos de bancos de dados. Mas contra o phishing AiTM, é necessária uma solução resistente ao phishing.

FIDO2 e passkeys: a única solução resistente ao phishing

As chaves FIDO2 (YubiKey, Feitian, Google Titan) e as passkeys (implementadas no Windows Hello, Apple iCloud Keychain, Android) oferecem resistência nativa ao phishing. O mecanismo se baseia na vinculação à origem (origin binding):

1. Durante o registro, a chave FIDO2 ou a passkey é vinculada a um domínio específico (por exemplo, login.microsoftonline.com).
2. Durante a autenticação, o navegador verifica automaticamente que o domínio da página corresponde ao domínio registrado. Se a página é um proxy de phishing em login-microsoftonline.attacker.com, o navegador se recusa a enviar as credenciais.
3. Não há segredo compartilhado para interceptar. A autenticação utiliza um mecanismo challenge-response baseado em um par de chaves assimétricas. Mesmo que o atacante intercepte a troca, ele não pode reproduzi-la.

Um proxy AiTM não pode contornar esse mecanismo: o navegador verifica a origem em um nível que o proxy não pode falsificar. É por isso que Microsoft, Google e Apple impulsionam coletivamente a adoção das passkeys desde 2024.

MFA number matching como solução intermediária

Se a implantação de FIDO2/passkeys não é imediata, ative no mínimo o number matching no Microsoft Authenticator. Em vez de um simples "Aprovar / Recusar", o usuário deve inserir um número de dois dígitos exibido na tela de login. Essa medida não protege contra um proxy AiTM sofisticado (o proxy pode exibir o número), mas bloqueia os ataques de MFA fatigue (bombardeio de notificações push) e adiciona uma fricção que reduz a taxa de sucesso dos ataques.

Ativação no Entra ID:

1. Acesse o Microsoft Entra Admin Center (entra.microsoft.com)
2. Navegue até Protection > Authentication methods > Microsoft Authenticator
3. Na aba Configure, ative "Require number matching for push notifications"
4. Aplique a todos os usuários ou a um grupo piloto

A prioridade continua sendo a implantação de FIDO2/passkeys para as contas com privilégios elevados (administradores, diretores, equipes financeiras) e depois a extensão progressiva a todos os usuários.

O papel do ARC nas cadeias de relay

O protocolo ARC (Authenticated Received Chain) foi projetado precisamente para resolver o problema da perda de contexto de autenticação durante o trânsito por intermediários. O ARC permite que cada relay assine os resultados de autenticação que observou, criando uma cadeia de confiança verificável.

Em teoria, se o serviço de terceiros implementa o ARC corretamente:

1. O serviço de terceiros recebe o e-mail e avalia SPF/DKIM/DMARC
2. Adiciona um conjunto de cabeçalhos ARC (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) documentando os resultados observados
3. O Microsoft 365 recebe o e-mail e verifica a cadeia ARC
4. Se a cadeia ARC é válida e provém de um remetente ARC confiável, o Microsoft 365 pode utilizar os resultados de autenticação originais em vez dos seus próprios resultados (que estão distorcidos pelo roteamento indireto)

Na prática, a eficácia do ARC depende de duas condições: o serviço de terceiros deve implementar o ARC (o que não é sistemático) e o Microsoft 365 deve confiar no remetente ARC (configurável no portal Defender). Sem essas duas condições, o ARC não muda nada.

A Microsoft recomenda o ARC como solução complementar, mas não como substituto do Enhanced Filtering for Connectors ou da mudança para MX direto.

Vigilância e resposta em caso de incidente

A proteção do roteamento de e-mail não é um projeto pontual. Os atacantes adaptam suas técnicas, as configurações evoluem e novos serviços de envio são adicionados regularmente. Uma vigilância ativa é necessária para detectar rapidamente qualquer regressão ou tentativa de exploração.

Configurar os alertas no Microsoft Defender

O Microsoft Defender for Office 365 permite criar alertas personalizados que detectam os padrões de ataque descritos neste artigo:

Alerta sobre falhas DMARC recorrentes: No portal Defender (security.microsoft.com), acesse Email & collaboration > Explorer. Filtre por DMARC = fail e action = none para o seu domínio. Se você observar um volume anormal de falhas DMARC sem ação, é o sinal de que sua política p=none está sendo explorada. Configure um alerta automatizado para ser notificado quando o volume ultrapassar um limite (por exemplo, mais de 50 falhas DMARC por dia para um domínio interno).

Alerta sobre self-spoofing: Procure e-mails onde o campo From contenha um domínio interno, mas o Return-Path contenha um domínio externo. Esse padrão é característico do self-spoofing. No Exchange Online, uma regra de fluxo de e-mail (transport rule) pode detectar essa condição e adicionar um aviso visual à mensagem ou colocá-la em quarentena.

Monitoramento de relatórios DMARC agregados: Os relatórios DMARC agregados (enviados ao endereço rua) contêm os resultados de autenticação de todos os e-mails enviados em nome do seu domínio. Analise-os pelo menos uma vez por semana. Um pico repentino de falhas a partir de IPs desconhecidos indica uma campanha de falsificação em andamento. Ferramentas gratuitas como DMARC Analyzer, Postmark DMARC ou os relatórios agregados da Microsoft permitem visualizar esses dados sem processamento manual.

O que fazer se você detectar um ataque em andamento?

Se você identificar e-mails de phishing que exploram o roteamento MX indireto contra seu domínio:

1. Ative imediatamente o EFC se ainda não o fez. É a medida mais rápida para restaurar o contexto de autenticação correto.
2. Passe o DMARC para p=quarantine no mínimo, mesmo sem a escalada progressiva recomendada. Em uma situação de ataque ativo, o risco de falsos positivos é secundário em relação ao risco de comprometimento.
3. Bloqueie os IPs de origem identificados nos cabeçalhos Received por meio das regras de fluxo de e-mail do Exchange Online ou por meio do serviço de terceiros.
4. Informe os usuários afetados. Se e-mails de self-spoofing foram entregues, os usuários devem saber que não devem clicar nos links nem abrir os anexos.
5. Verifique as conexões suspeitas nos logs de auditoria do Entra ID. Se o ataque AiTM conseguiu capturar cookies de sessão, você verá conexões a partir de IPs incomuns pouco depois da entrega dos e-mails de phishing.
6. Revogue as sessões ativas das contas potencialmente comprometidas por meio do Entra ID (Revoke Sessions). Force uma troca de senha e uma reautenticação MFA.

Automatizar a detecção a longo prazo

Para as organizações com um volume significativo de e-mails, a automatização da detecção é indispensável. O Microsoft Sentinel (o SIEM na nuvem da Microsoft) pode ingerir os logs do Exchange Online e acionar playbooks automatizados nas seguintes condições:

• Volume anormal de e-mails com dmarc=fail action=none para um domínio interno
• E-mails de entrada onde o domínio From é um domínio interno, mas o IP de origem não está na lista de IPs autorizados
• Conexões do Entra ID a partir de um IP geograficamente incoerente nos minutos seguintes à entrega de um e-mail suspeito

Essas automatizações transformam uma detecção reativa ("encontramos um e-mail suspeito") em uma detecção proativa ("o sistema isolou o e-mail e bloqueou a conta antes que o usuário clicasse").

Checklist de proteção completa

Aqui está a checklist consolidada para proteger seu domínio contra o vetor de ataque documentado pela Microsoft. Cada item é classificado por prioridade.

Prioridade crítica (semana 1)

• Verificar seu MX: dig MX captaindns.com +short
• Verificar sua política DMARC: dig TXT _dmarc.captaindns.com +short
• Verificar seu mecanismo SPF terminal: dig TXT captaindns.com +short
• Se MX indireto + DMARC p=none: ativar Enhanced Filtering for Connectors imediatamente
• Ativar DKIM para o seu domínio no Microsoft 365

Prioridade alta (semanas 2 a 4)

• Começar a escalada progressiva do DMARC rumo a p=quarantine
• Substituir SPF ~all por -all após inventário das fontes de envio
• Auditar os conectores de entrada no Exchange Online
• Verificar a configuração de IP da skip list para o EFC
• Ativar o number matching no Microsoft Authenticator

Prioridade média (meses 2 a 3)

• Continuar a escalada DMARC rumo a p=reject
• Avaliar a migração para um MX direto para o Microsoft 365
• Começar a implantação de FIDO2/passkeys para contas com privilégios
• Configurar os remetentes ARC confiáveis se o roteamento indireto for mantido
• Estabelecer um acompanhamento regular dos relatórios DMARC agregados

Prioridade baixa (trimestre seguinte)

• Estender FIDO2/passkeys a todos os usuários
• Eliminar o roteamento MX indireto se não for necessário
• Automatizar a análise de relatórios DMARC com uma ferramenta dedicada
• Treinar os usuários para reconhecer e-mails de phishing

O que o alerta da Microsoft muda para a sua organização

O alerta de janeiro de 2026 não revelou um bug. Ele expôs um ponto cego arquitetural que os atacantes exploram em larga escala. A combinação roteamento MX indireto + SPF softfail + DKIM ausente + DMARC p=none é uma configuração que milhares de organizações utilizam sem saber que é vulnerável.

A correção não é um patch de software. É um trabalho de configuração DNS e arquitetura de e-mail. Algumas organizações corrigirão em um dia (ativar DKIM, passar o SPF para hardfail, ativar o EFC). Outras precisarão de vários meses para migrar seu MX e implantar o FIDO2.

As três ações imediatas:

1. Faça o diagnóstico agora. Os três comandos dig da seção de diagnóstico levam 30 segundos. Você saberá imediatamente se seu domínio está na zona crítica.
2. Ative o Enhanced Filtering for Connectors se seu MX aponta para um terceiro. É a correção mais rápida com a melhor relação impacto/esforço.
3. Ative o DKIM. É a peça que falta na maioria das configurações vulneráveis. Com o DKIM ativo, o DMARC pode passar mesmo quando o SPF falha por causa do roteamento indireto.

O objetivo final é simples: seu domínio deve estar protegido por SPF -all, DKIM ativo e DMARC p=reject. Não é um ideal teórico, é a linha de base que Google, Yahoo e Microsoft exigem dos remetentes desde 2024. O alerta de janeiro de 2026 lembra que os e-mails acabam no spam quando essa linha de base não é alcançada e, pior ainda, que os atacantes exploram ativamente os domínios que não a cumprem.