Publicar um registro DMARC com p=reject deveria ser a linha de chegada. Isso diz por escrito a todo servidor de e-mail receptor que descarte qualquer mensagem que afirme vir do seu domínio e não consiga provar isso. Pesquisadores de segurança e administradores do Microsoft 365 vêm documentando uma brecha nessa promessa: uma marcação de confiança dentro do Exchange Online Protection chamada SCL:-1, capaz de deixar e-mails falsificados passarem direto pela aplicação do DMARC, em domínios que fizeram tudo certo.
O que o SCL:-1 realmente faz
Toda mensagem que chega a uma caixa de entrada do Microsoft 365 recebe um Spam Confidence Level, um cabeçalho que vai de -1 a 9 e que o Exchange Online Protection usa para decidir o que acontece a seguir. A maior parte dessa faixa alimenta o processo normal de pontuação de spam. O SCL:-1 é diferente. Significa “esta mensagem vem de uma fonte confiável”, e uma mensagem que carrega essa marcação pula completamente a filtragem, incluindo as verificações antiphishing que deveriam agir sobre uma avaliação DMARC malsucedida. O resultado da autenticação ainda pode ser calculado e registrado. Ele simplesmente nunca chega a importar, porque a mensagem já foi liberada antes de a aplicação da política entrar em ação.
Por onde a confiança vaza
O SCL:-1 não é algo que um atacante define. Ele é aplicado pela própria configuração do locatário, quase sempre sem que ninguém preveja a consequência. A fonte mais comum é a lista de permissões dentro da política de filtro de conexão: qualquer endereço adicionado ali, muitas vezes anos atrás para desbloquear um fornecedor ou um scanner que tinha problemas de entrega, fica confiável de forma permanente, não importa o que chegue depois a partir dele. Regras de fluxo de e-mail criadas para facilitar a entrega de um aplicativo específico podem produzir o mesmo efeito ao definir explicitamente o SCL como -1. Conectores de entrada configurados para tratar um parceiro ou gateway como totalmente confiável carregam o mesmo risco. Nenhum deles foi criado como uma brecha de segurança. Foram criados como soluções de entrega, empilhadas silenciosamente umas sobre as outras ao longo de anos de administração do locatário, cada uma invisível até que alguém mapeie toda a cadeia e descubra que uma política DMARC estrita está posicionada rio abaixo de uma dúzia de formas de contorná-la.
Não é a mesma brecha do Direct Send
Vale a pena ser preciso sobre o que isso não é. O Direct Send, o caminho de retransmissão anônima que já cobrimos antes, permite que e-mails não autenticados cheguem a um locatário conectando-se diretamente ao seu endpoint MX pela porta 25, e a configuração RejectDirectSend da Microsoft fecha especificamente essa porta. O SCL:-1 é um mecanismo completamente diferente. Ele afeta e-mails que chegam por caminhos totalmente normais e com aparência autenticada, remetentes externos, conectores reais, roteamento real, mas que são marcados como confiáveis antes mesmo de a política antiphishing avaliá-los. Ativar o RejectDirectSend não faz nada para corrigir um IP na lista de permissões ou uma regra de transporte esquecida. Uma organização pode fechar completamente a porta do Direct Send e ainda assim ter o SCL:-1 anulando silenciosamente a aplicação do seu DMARC por uma rota diferente até as mesmas caixas de entrada.
O que isso significa para o seu programa
Audite primeiro a lista de permissões do filtro de conexão. Todo endereço IP nela deve ter um motivo documentado e atual para estar lá. Entradas adicionadas para resolver um problema de entrega pontual anos atrás são a fonte mais comum dessa brecha, e ninguém se lembra de tê-las adicionado.
Procure nas regras de fluxo de e-mail por ações explícitas de SCL:-1. Regras de transporte que definem diretamente o nível de confiança de spam são fáceis de escrever e fáceis de esquecer. Cada uma delas é uma exceção permanente ao que a sua política DMARC declara.
Ative a filtragem aprimorada para conectores em todo conector de entrada, incluindo os que roteiam por um gateway de terceiros. Isso permite que a Microsoft avalie SPF, DKIM e DMARC contra o IP de origem real em vez do IP do gateway, o que mantém a autenticação relevante mesmo quando o e-mail não chega de forma direta.
Não presuma que o RejectDirectSend resolve isso. Ele soluciona o abuso de retransmissão anônima. Não tem nenhum efeito sobre fluxos de e-mail em lista de permissões ou marcados explicitamente como confiáveis, o que é uma auditoria totalmente diferente.
Revise as ações da política antiphishing no portal do Defender em comparação com o que seu registro DMARC realmente declara. Uma política estrita publicada no DNS e uma ação permissiva configurada no locatário podem coexistir indefinidamente, sem que nada exponha o conflito a menos que alguém verifique as duas coisas.
A conclusão
Um registro DMARC é uma promessa feita no DNS, mas a própria configuração do Microsoft 365 decide se essa promessa é cumprida. O SCL:-1 não é uma falha do DMARC nem uma falha do mecanismo de filtragem da Microsoft. É o que acontece quando anos de pequenas soluções de entrega, cada uma razoável em seu momento, se acumulam até virar uma exceção permanente que ninguém audita em relação à política de autenticação atual do domínio. Aplicação não é algo que se configura uma vez em um registro DNS e depois se esquece. Ela precisa sobreviver ao contato com cada lista de permissões, cada regra de transporte e cada conector que uma organização já tenha adicionado.
A Excello Mail oferece visibilidade contínua sobre seus relatórios DMARC, para que você veja exatamente quais fontes estão se autenticando sob o seu domínio e identifique a brecha entre o que sua política declara e o que sua plataforma de e-mail realmente aplica. Cadastre-se gratuitamente na Excello Mail e sustente com monitoramento real a aplicação que você acredita já ter.