CEVIU Logo
Voltar

Segurança de E-mail: Por Que 74% das Organizações Travam no Meio do Caminho

Aprofundamento CEVIU

Aprofundamento

O dado-chave não é que 57,1% dos domínios publicam DMARC, mas que 74% das organizações travam exatamente no ponto mais crítico: deixam a política em p=none, mesmo com registros ativos. Isso transforma o DMARC em um relatório de diagnóstico inútil, não bloqueia nada, só gera dados. A pesquisa web confirma: em fevereiro de 2026, 525.996 dos 937.931 domínios com DMARC estavam nessa armadilha, e globalmente 69,1% ainda não têm proteção efetiva. O p=reject não é um luxo técnico: é a única política que impede spoofing de domínio por completo, e sua adoção real (11,3% em junho de 2026) está muito abaixo do exigido por Google, Yahoo e PCI DSS v4.0 desde 2025.

As notícias recentes da CEVIU mostram por que essa falha é explosiva: golpistas já exploram contas internas da Microsoft para enviar spam com credibilidade de alerta legítimo (25/05), e ataques via device code e OAuth (04/06 e 20/05) contornam autenticação de usuário, mas não autenticação de domínio. Um DMARC com p=reject teria barrado o spoofing do remetente nesses casos, se o domínio da Microsoft ou o da vítima tivesse aplicado a política corretamente. Ainda assim, há limites reais: configurações específicas do Microsoft 365, como SCL:-1 ou listas de permissão, podem ignorar o DMARC mesmo com p=reject ativado. Isso não invalida o protocolo, mas mostra que ele é uma camada, não uma solução única.

O que mudou

Em maio de 2026, a CEVIU já havia reportado dois vetores concretos de ataque que dependem diretamente da ausência de DMARC efetivo: o abuso de conta interna da Microsoft para phishing (25/05) e os ataques BEC via device code (04/06). A nova análise do Majestic Million confirma que esses ataques não são exceções, mas consequências previsíveis de uma falha sistêmica, a estagnação em p=none. Antes, tínhamos evidências pontuais de exploração; agora, temos dados estruturais que mostram que 74% das organizações estão vulneráveis ao mesmo vetor, em escala massiva. Também houve mudança regulatória concreta: o PCI DSS v4.0 passou de recomendação para fiscalização obrigatória em 2026, e o Google intensificou rejeições permanentes em novembro de 2025, o que explica o salto na adoção (de 27,2% em 2023 para 52,1% em 2026), mas não na imposição.

Por que isso importa

Perdas por BEC somaram US$ 3,05 bilhões em 2025, e phishing foi o crime cibernético mais relatado, 191.561 reclamações. Um DMARC mal configurado não protege contra isso. Mas um p=reject bem implantado reduz o spoofing de domínio em até 85%, segundo dados do Majestic Million. Mais do que evitar fraudes, isso evita multas: o PCI DSS v4.0 e a diretiva europeia NIS2 tratam a autenticação de e-mail como controle obrigatório, não opcional. Para empresas que lidam com dados sensíveis ou processam pagamentos, deixar o DMARC em modo observação é equivalente a manter a porta da frente destrancada enquanto instala câmeras no jardim.

Linha do tempo

  1. CEVIU reporta exploração de conta interna da Microsoft para phishing com alto grau de credibilidade

  2. CEVIU detalha escalada de ataques BEC via device code na Microsoft, explorando fluxos de autenticação

  3. Dados do Majestic Million revelam que 74% das organizações têm DMARC ativo, mas não aplicam p=reject ou p=quarantine

Perguntas frequentes

Por que meu DMARC com p=none não me protege, mesmo tendo SPF e DKIM configurados?

O p=none só habilita relatórios, não bloqueia e-mails falsificados. SPF e DKIM validam remetentes, mas sem uma política de ação (quarantine ou reject), servidores de destino ignoram falhas. É como ter uma câmera de segurança que grava, mas não dispara alarme nem trava a porta.

Posso pular direto para p=reject, ou preciso de um período de teste?

Não pule. Comece com p=none por 7–14 dias, analise os relatórios DMARC para identificar remetentes legítimos mal configurados (como newsletters ou sistemas de RH). Depois vá para p=quarantine, e só então para p=reject. Empresas da Fortune 500 seguem esse ciclo, 80% já estão em p=reject em 2026, mas quase todas passaram por testes rigorosos antes.

MTA-STS e TLS-RPT valem a pena se meu DMARC já está em p=reject?

Sim, porque o DMARC protege contra spoofing do remetente, mas não contra interceptação de tráfego SMTP. MTA-STS força TLS criptografado entre servidores de e-mail, e TLS-RPT mostra falhas de entrega por problemas de certificado ou downgrade. Sem eles, um atacante pode ler ou alterar mensagens em trânsito, mesmo que o remetente seja legítimo.

DNSSEC e DANE são necessários para segurança de e-mail hoje?

Não. DNSSEC tem adoção de apenas 0,596% em maio de 2026, e DANE depende dele. São tecnologias importantes para cenários de alta ameaça (governos, setor financeiro), mas praticamente inexistentes na prática. Priorize o que funciona: DMARC p=reject, MTA-STS e CAA, este último obrigatório para certificados S/MIME desde março de 2025.

Avalie este artigo:
Compartilhar:
Categoria
CEVIU Segurança da Informação
Publicado
08 de junho de 2026
Fonte
CEVIU Segurança da Informação

Quer receber mais sobre CEVIU Segurança da Informação?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser
Segurança de E-mail: Por Que 74% das Organizações Travam no Meio do Caminho — CEVIU News