Aprenda a bloquear remetentes que se passam por funcionários e reduza drasticamente o spam no Exchange Online (Microsoft 365) usando políticas anti‑spam (Inbound) no Microsoft Defender — com passos claros, dicas contra “personificação” e um checklist prático.
Visão geral e objetivo
Quando atacantes personificam colaboradores (por exemplo, “Maria do Financeiro” com um endereço externo parecido), o resultado é um aumento de golpes, perda de produtividade e risco de fraude. A forma mais segura e gerenciável de interromper esses envios é criar uma política Anti‑spam (Inbound) no Microsoft Defender e adicionar os remetentes/domínios fraudulentos à lista de bloqueio dessa política. Assim, as mensagens passam a ser rejeitadas ou encaminhadas para quarentena, de acordo com as ações da própria política.
Por que não usar o Tenant Allow/Block List para bloquear remetentes?
Entradas de bloqueio no Tenant Allow/Block List (TABL) também afetam o fluxo de saída, impedindo que seus usuários enviem e‑mails para esses endereços/domínios. Isso costuma ser indesejado. Prefira bloquear via Anti‑spam policy (Inbound) conforme o passo a passo abaixo.
O caminho recomendado (resumo rápido)
- Acesse Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti‑spam.
- Clique em Create policy → Inbound.
- Na etapa Create block entries for domains and email addresses, adicione os endereços/domínios a bloquear.
- Defina o escopo da política (toda a organização ou grupos específicos) e salve.
- Monitore o resultado: mensagens de remetentes/domínios bloqueados passam a ser rejeitadas ou quarentenadas, conforme configurado na política.
Passo a passo detalhado no Microsoft Defender
Pré‑requisitos
- Permissões adequadas (por exemplo, Security Administrator, Security Reader ou equivalentes).
- Exchange Online (EOP já incluso) e, idealmente, Defender for Office 365 para recursos avançados.
Criação da política Anti‑spam (Inbound)
- Navegue até o portal de segurança do Microsoft 365. Em Email & Collaboration → Policies & Rules → Threat policies, selecione Anti‑spam.
- Clique em Create policy e escolha Inbound.
- Preencha as opções básicas (nome e descrição que facilitem auditoria, por exemplo: “Bloqueio — Personificação Funcionários”).
- Na etapa Create block entries for domains and email addresses:
- Adicione endereços exatos (ex.:
contas@exemplo-spoof.com) e/ou domínios (ex.:exemplo-spoof.com). - Evite curingas (
*); se necessário, inclua subdomínios relevantes explicitamente (ex.:mail.exemplo-spoof.com). - Use comentários internos (onde possível) para registrar o motivo do bloqueio e o ticket associado.
- Adicione endereços exatos (ex.:
- Configure as ações para spam e níveis de confiança (por exemplo, quarentena para “High confidence spam”). Em muitos ambientes, o bloqueio por remetente/domínio já rotula essas mensagens para reject ou quarantine com alta confiança — ajuste conforme sua política de risco.
- Defina o escopo (recipients): toda a organização ou grupos/unidades (ex.: All users, ou um grupo de alto risco como “Financeiro”).
- Revise a prioridade da política. Em geral, políticas mais específicas (ex.: VIP/Financeiro) ficam com prioridade superior às políticas amplas.
- Salve e acompanhe a propagação (pode levar alguns minutos).
Como confirmar que funcionou
- Realize um message trace para o remetente/domínio bloqueado e verifique a action (Rejected ou Quarantined), além do motivo.
- Revise a quarentena por categoria (Spam/High confidence spam/Policy) e confirme o bloqueio.
- Peça a um grupo‑piloto que reporte qualquer mensagem suspeita via add‑in Report Message.
Dicas complementares contra “personificação de funcionário”
Anti‑phishing / Impersonation
- Ative políticas anti‑phishing no Defender.
- Configure proteção por personificação para:
- Usuários VIP (CEO, CFO, RH, TI, Financeiro).
- Seu domínio (domain impersonation).
- Habilite Mailbox Intelligence (quando disponível) para reforçar detecções baseadas em relacionamento.
Autenticação de e‑mail (SPF, DKIM e DMARC)
Uma boa higiene de autenticação eleva a taxa de detecção de spoofing e reduz falsos positivos.
| Componente | O que fazer | Observações |
|---|---|---|
| SPF | Publicar um registro TXT com todos os provedores autorizados. | Evite mais de 10 DNS lookups; minimize include:. |
| DKIM | Assinar saídas com chaves rotacionadas periodicamente. | Verifique se todos os domínios de envio têm DKIM ativo. |
| DMARC | Publicar política com alinhamento e monitorar relatórios. | Evolua de p=none para p=quarantine ou p=reject quando maduro. |
Spoof intelligence
- Use as listas de allowed/denied de spoof para lidar com remetentes legítimos que “parecem” falsos (ex.: fornecedores que enviam em nome de).
- Avalie minuciosamente antes de permitir; registre a justificativa e prazo de revisão.
Regras de fluxo de e‑mail (Exchange mail flow rules)
Para bloqueios temporários ou granulares, crie regras no Exchange Admin Center enquanto ajusta as políticas definitivas. Exemplos:
- Condição por domínio do remetente ou padrões de assunto/cabeçalhos.
- Ação: reject com explicação, quarantine ou set SCL=9.
- Escopo: unidades sensíveis enquanto a política global é preparada.
Quarentena e relatórios
- Reveja a quarentena regularmente (por categoria e motivo de detecção).
- Ative e incentive o uso do add‑in Report Message para feedback de 1 clique.
Proteções adicionais
- Safe Links: reescrita/inspeção de URLs em tempo real.
- Safe Attachments: análise dinâmica de anexos.
Boas práticas de escopo e prioridade
- Específico vence o geral: políticas direcionadas (ex.: VIP/Financeiro) devem ter prioridade mais alta.
- Documente o motivo do bloqueio e o grupo impactado, além de responsáveis e data de revisão.
- Evite sobreposição confusa: mantenha poucas políticas bem nomeadas e com objetivos claros.
Comparativo: Anti‑spam policy vs Tenant Allow/Block List
| Recurso | Anti‑spam (Inbound) | Tenant Allow/Block List |
|---|---|---|
| Objetivo | Bloquear/ajustar tratativa do que entra. | Exceções globais de allow/block em nível de locatário. |
| Efeito no envio (saída) | Não bloqueia saída. | Bloqueia saída para endereços/domínios em block. |
| Granularidade | Políticas por grupo/unidade com prioridade. | Âmbito global; difícil segmentar por área. |
| Recomendação | Usar para bloquear remetentes/domínios de spam/phishing. | Preferir para allow excepcionais e bem auditados; evitar block para casos do dia a dia. |
Modelo de processo (do alerta à contenção)
- Detecção (usuário reporta, alerta do Defender, anomalia no message trace).
- Validação (confirmar personificação e impacto).
- Bloqueio via política Anti‑spam (Inbound) — adicionar remetente/domínio.
- Monitorar quarentena e telemetria por 3–5 dias úteis.
- Comunicar os usuários afetados (ver exemplo abaixo).
- Revisar se há outros vetores (URLs, anexos, novas contas).
Exemplo de comunicação aos usuários
Implementamos um bloqueio para remetentes externos que se passam por funcionários. Se receber algo semelhante, use o botão “Report Message”. Caso um e‑mail legítimo seja afetado, abra um chamado informando data/hora, remetente e assunto.
Como testar sem risco
- Crie uma caixa de teste e uma política de bloqueio com escopo restrito a ela.
- Envie mensagens de um domínio externo de laboratório e valide o comportamento (Reject ou Quarantine).
- Use message trace para confirmar a ação aplicada e o motivo (sender/domain blocked).
Erros comuns (e como evitar)
- Usar o Tenant Allow/Block List para bloquear remetentes do dia a dia: gera bloqueio de saída indesejado. Solução: mover o bloqueio para a Anti‑spam policy (Inbound).
- Confiar apenas em nomes de exibição (“CEO”, “Financeiro”): não bloqueia o verdadeiro endereço. Solução: bloquear endereço real e domínios envolvidos.
- Falhas de escopo: política criada, mas sem incluir todos os destinatários. Solução: revisar grupos e prioridade.
- Bypass involuntário por regra de fluxo antiga: reavalie regras que bypassam antispam para parceiros.
- Curvas de falsos positivos após endurecimento: acompanhe a quarentena e ajuste ações (ex.: quarentena em vez de rejeição inicialmente).
Perguntas frequentes
Bloqueio por domínio ou por endereço — qual usar?
Se o atacante variar endereços num mesmo domínio malicioso, bloqueie o domínio. Se o domínio for compartilhado por remetentes legítimos, prefira endereços específicos.
Quanto tempo leva para a política surtir efeito?
Geralmente a replicação é rápida, mas considere alguns minutos para propagação em todo o serviço.
É melhor rejeitar ou quarentenar?
Quarentena dá margem para correção de falsos positivos e auditoria. Rejeição reduz armazenamento e envia NDR ao remetente (que pode não ser legítimo). Comece com quarentena em ambientes com baixa maturidade de reporte.
Bloquear na Anti‑spam (Inbound) impede que meus usuários respondam para o remetente?
Não. A Anti‑spam (Inbound) trata mensagens entrantes. Quem bloqueia também a saída é o Tenant Allow/Block List (por isso evitamos usá‑lo para block no dia a dia).
E se os atacantes trocarem de domínio?
Amplie a proteção com Impersonation (anti‑phishing), SPF/DKIM/DMARC e Spoof intelligence. Isso reduz as brechas quando os domínios mudam.
Checklist rápido
- ☑ Política Anti‑spam (Inbound) criada no Defender.
- ☑ Endereços/domínios problemáticos adicionados à lista de bloqueio da política.
- ☑ Escopo da política definido (toda a org. ou grupos).
- ☑ Anti‑phishing/Impersonation configurado.
- ☑ SPF/DKIM/DMARC verificados.
- ☑ Processo de quarentena e report pelos usuários ativo.
Tabela de ações e impactos
| Decisão na política | Impacto nas mensagens | Quando usar |
|---|---|---|
| Quarentenar | Mensagem retida para revisão/administração. | Fase inicial de endurecimento ou alto risco de falsos positivos. |
| Rejeitar (NDR) | Mensagem barrada; remetente recebe NDR. | Fontes claramente maliciosas e já estabilizadas. |
| Mover para Junk | Entrega ao usuário, porém na caixa de lixo eletrônico. | Casos de menor risco, com monitoramento. |
Governança e auditoria
- Padronize nomes de políticas (ex.: “AS‑INB‑Block‑Impersonation‑Financeiro”).
- Registre decisões (motivo, ticket, aprovador, data de revisão).
- Revise periodicamente os blocos para remover entradas obsoletas.
Fluxo de decisão recomendado
- Recebeu amostra suspeita? → Validar (headers, domínio, origem).
- Confirma personificação? → Bloquear remetente/domínio na Anti‑spam (Inbound).
- Precisa conter rapidamente um padrão específico (assunto/cabeçalho/IP)? → Regra de fluxo temporária.
- Há remetente legítimo afetado? → Avaliar allow bem justificado (fora do escopo deste guia).
Resolução de problemas
- “Bloqueei o domínio, mas e‑mails ainda chegam”:
- Verifique subdomínios (adicione explicitamente).
- Reveja regras de fluxo que possam estar dando bypass.
- Confirme a prioridade e o escopo da política.
- “Parceiro legítimo foi impactado”:
- Valide SPF/DKIM/DMARC do parceiro.
- Trate como exceção formal, documentando o motivo e prazo de revisão.
- “Quarentena está cheia de falsos positivos”:
- Refine as listas (remova domínios genéricos; foque nos maliciosos).
- Ajuste ações (por exemplo, Junk em vez de Reject) enquanto calibra.
Passos complementares (opcionais e avançados)
Auditoria via PowerShell (message trace)
Para auditorias e automações, o message trace ajuda a validar ações:
# Exemplo (Exchange Online PowerShell)
Connect-ExchangeOnline
Get-MessageTrace -SenderAddress atacante@exemplo-spoof.com -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
Format-Table Received, SenderAddress, RecipientAddress, Subject, Status
Procure por Status coerente com a política (por exemplo, FilteredAsSpam, Quarantined ou Failed com NDR).
Conclusão
Bloquear remetentes e domínios suspeitos diretamente na Anti‑spam policy (Inbound) do Microsoft Defender oferece controle, governança e segurança superiores — sem efeitos colaterais no envio de e‑mails da sua organização. Combine esse bloqueio com Impersonation, autenticação (SPF/DKIM/DMARC), Spoof intelligence, regras de fluxo temporárias e uma rotina de quarentena/reportes ativa. O resultado esperado é claro: mensagens de remetentes/domínios listados deixam de chegar às caixas de entrada (rejeitadas ou quarentenadas), reduzindo spam e mitigando tentativas de personificação.
Resumo executivo
- Problema: spam por personificação de funcionários.
- Solução: Anti‑spam (Inbound) no Defender com bloqueio por remetente/domínio.
- Evitar: bloquear via Tenant Allow/Block List (afeta saída).
- Complementos: Impersonation, SPF/DKIM/DMARC, Spoof Intelligence, Safe Links/Attachments.
- Governança: escopo, prioridade, documentação e revisão periódica.