A Microsoft criou o RejectDirectSend para fechar uma brecha específica: e-mails não autenticados que dizem vir do próprio domínio interno de uma organização. Pesquisadores da ReliaQuest descobriram que o controle pode ser totalmente contornado deixando um único campo SMTP vazio. Sem credenciais roubadas. Sem uma vulnerabilidade de software no sentido tradicional. Apenas uma mensagem enviada sem nada no remetente do envelope.
O Que o RejectDirectSend Deveria Resolver
Direct Send é o recurso do Microsoft 365 que permite que impressoras, scanners, aplicações de negócio e outros dispositivos enviem e-mail através da própria infraestrutura de um tenant sem se autenticar primeiro. É conveniente, e também tem sido um vetor de falsificação bem documentado: um atacante externo que encontra o endpoint de envio previsível de um tenant pode enviar e-mails que parecem gerados internamente. A resposta da Microsoft foi o RejectDirectSend, uma configuração que bloqueia mensagens de Direct Send não autenticadas quando o domínio no remetente do envelope SMTP corresponde a um domínio que a organização possui.
Essa descrição contém a brecha. O RejectDirectSend verifica um domínio. Ele nunca leva em conta o que acontece quando não há domínio nenhum para verificar.
O Contorno: MAIL FROM Sem Nada Depois
Cada transação SMTP carrega duas identidades de remetente. A que os destinatários veem é o cabeçalho From visível. A que os servidores de e-mail usam para roteamento e autenticação é o remetente do envelope, definido pelo comando MAIL FROM durante a conversa SMTP. Uma mensagem pode ser legitimamente enviada com um remetente de envelope vazio, escrito como MAIL FROM:<>, um caminho de retorno nulo usado mais comumente para mensagens de devolução, para que elas próprias não gerem novas devoluções.
A ReliaQuest encontrou atacantes reaproveitando esse mecanismo legítimo. Enviar uma mensagem com MAIL FROM:<>, um remetente de envelope vazio, enquanto o cabeçalho From visível continua exibindo um endereço interno falsificado, deixa o RejectDirectSend sem nada para avaliar. O controle foi construído para comparar um domínio com uma lista de domínios aceitos. Um campo vazio não é um domínio que falha na comparação. É a ausência de uma comparação. A própria documentação do Direct Send da Microsoft descreve que a configuração se aplica quando o domínio do remetente do envelope é um domínio aceito; ela não diz nada sobre o que acontece quando esse campo está vazio, porque o controle nunca foi construído pensando nesse caso.
O Que os Cabeçalhos de Autenticação Realmente Mostram
Esta não é uma mensagem que passa despercebida silenciosamente. SPF e DKIM retornam sem resultado, já que não há domínio de remetente de envelope para o SPF avaliar em primeiro lugar, e o DMARC falha diretamente. No papel, todo sinal que um defensor gostaria de ter está presente e apontando para phishing. Em um caso documentado pela ReliaQuest, uma mensagem falhou em todas as verificações de autenticação de remetente e ainda assim foi classificada como phishing de alta confiança pela filtragem posterior, mas chegou à caixa de entrada mesmo assim, porque o endereço executivo falsificado estava, por acaso, em uma lista de remetentes permitidos. O RejectDirectSend já havia deixado a mensagem entrar no fluxo de e-mail do tenant antes que qualquer uma dessas avaliações ocorresse. A falha de autenticação foi real, ficou registrada e foi correta. Ela simplesmente chegou depois que a decisão que importava já havia sido tomada.
Quem Está Realmente Sendo Alvo
A ReliaQuest revisou casos de setembro de 2025 a agosto de 2026 e encontrou um padrão claro de quem recebe essas mensagens de envelope vazio. Quarenta por cento foram direcionadas a altos executivos. Vinte e cinco por cento foram para gerentes e equipes de vendas. Vinte por cento chegaram a colaboradores individuais, e os quinze por cento restantes caíram em caixas de entrada de contas compartilhadas ou de serviço. Os iscas se inclinavam para processos de negócio, não para teatro de urgência: avisos de compartilhamento de arquivos foram o modelo individual mais comum, seguidos por solicitações de pagamento e remessa, convites de aquisição, ofertas de empréstimo ou investimento, e convites de reunião. Nenhum deles precisa de um clique em pânico. Precisam apenas de uma interação de negócio comum que pareça plausível, vinda de um endereço que parece pertencer ao interior da empresa.
Por Que Isso Está Exatamente no Ponto Cego do DMARC, Não Fora Dele
A maioria das campanhas que vale a pena documentar passa pelo DMARC de forma limpa e não deixa nada para o protocolo dizer. Esta é diferente, e mais desconfortável, porque aqui o DMARC diz algo, sim. Ele falha, corretamente, exatamente como foi projetado. A brecha não está no que o DMARC avalia. Está em um controle posterior que deveria impor uma consequência a essa falha e, em vez disso, nunca chegou a ser acionado, porque foi construído para verificar um campo que os atacantes aprenderam que podiam simplesmente deixar vazio. Uma política DMARC rigorosa protege um domínio de ser falsificado na internet aberta. Ela faz muito pouco por um controle do lado do tenant, com sua própria definição separada e mais estreita do que conta como um domínio que merece ser verificado.
O Que Isso Significa Para o Seu Programa
Não presuma que um controle antifalsificação com nome cobre todas as entradas desse vetor de falsificação. O RejectDirectSend faz um trabalho real contra o abuso de Direct Send para o qual foi projetado. Ele não foi projetado contra um remetente de envelope vazio, e controles com lógica estreita e específica tendem a ter exatamente esse tipo de caso limite bem fora do seu escopo.
Audite suas listas de remetentes permitidos para endereços executivos e financeiros. O caso que chegou à caixa de entrada aqui aconteceu porque um endereço interno falsificado já estava em uma lista de permitidos. Uma lista construída para reduzir falsos positivos em remetentes internos legítimos é também, silenciosamente, um contorno para quem conseguir falsificar esses mesmos endereços.
Alerte sobre a combinação, não apenas sobre a falha isolada. Uma mensagem com SPF sem resultado, DKIM ausente e DMARC falhando, chegando com um nome de exibição que corresponde ao de um executivo, é um padrão específico e detectável, independentemente de qual mecanismo de entrega a deixou passar. Construa a regra em torno dessa combinação em vez de confiar que algum controle anterior já a tenha detectado.
Pergunte ao seu fornecedor, e à Microsoft, como o RejectDirectSend se comporta hoje diante de um remetente de envelope nulo. Este é o tipo de brecha que é corrigida assim que se torna pública. Confirme o comportamento atual do seu tenant em vez de presumir que a mitigação do trimestre passado ainda vale.
A Conclusão
O RejectDirectSend foi uma solução genuína para um problema real de falsificação, e continua sendo, para o caso específico que foi construído para verificar. O que a ReliaQuest documentou não é uma falha do DMARC. É um lembrete de que os controles que as organizações sobrepõem ao DMARC para fazer cumprir seus vereditos podem ter suas próprias brechas, brechas sobre as quais uma política DMARC rigorosa não tem nenhuma visibilidade nem capacidade de fechar. A mensagem falhou na autenticação exatamente como deveria. Algo mais deveria agir sobre essa falha, e um único campo vazio foi suficiente para garantir que isso nunca acontecesse.
O DMARC disse a verdade em cada mensagem desta campanha. A falha aconteceu uma camada abaixo, em um controle que a maioria das equipes de segurança nunca pensa em testar contra um campo vazio. A Excello Mail oferece visibilidade contínua e em linguagem clara sobre sua postura de autenticação real, para que brechas como essa apareçam antes que um atacante as encontre primeiro. Cadastre-se gratuitamente na Excello Mail e veja hoje o seu panorama real de autenticação.