Un email signé « Support IT », envoyé depuis une adresse de votre propre domaine, qui vous demande de valider un document partagé : c’est le scénario type des campagnes qui abusent de Direct Send, une fonction d’Exchange Online. Aucun compte n’est volé, aucun mot de passe n’est compromis. L’attaquant se contente d’envoyer directement vers le serveur de réception de votre tenant Microsoft 365.
Microsoft a ajouté en 2025 un réglage pour bloquer cet usage, RejectDirectSend. Mais le 4 septembre 2026, des chercheurs de ReliaQuest ont décrit une technique qui le contourne avec un expéditeur d’enveloppe vide. Voici comment fonctionne l’attaque, ce que bloque réellement le réglage et la configuration qui ferme vraiment la porte.
À retenir : RejectDirectSend seul ne suffit pas. La parade la plus solide observée est un connecteur entrant limité aux IP ou au certificat de vos appareils légitimes, combiné à RejectDirectSend et au retrait des exceptions de filtrage.
Qu’est-ce que Direct Send ?
Direct Send permet à un appareil ou à une application d’envoyer un email vers les boîtes de votre propre tenant, sans authentification. L’envoi se fait en SMTP sur le port 25, vers le point de terminaison MX du tenant, de la forme example-fr.mail.protection.outlook.com. L’adresse d’expédition doit appartenir à un domaine accepté du tenant, mais n’a pas besoin de boîte aux lettres.
Microsoft documente cet usage pour les copieurs multifonctions, les scanners et les applications métier qui n’envoient qu’en interne. Les destinataires externes sont refusés. C’est pratique : pas de mot de passe stocké dans un appareil. C’est aussi le problème : le serveur ne vérifie pas qui envoie.
Comment l’attaque fonctionne
Les campagnes documentées depuis mai 2025 (Varonis, relayé par BleepingComputer, puis Rapid7) suivent toutes le même schéma :
- L’attaquant trouve le point de terminaison MX de la cible, publié dans le DNS.
- Il envoie un message en SMTP, sans authentification, avec une adresse de l’entreprise dans le champ From : direction, support IT, comptabilité.
- Le message arrive dans les boîtes des salariés avec l’apparence d’un email interne.
Les prétextes sont classiques : messagerie vocale ou fax en pièce jointe, partage de fichier, demande de paiement, invitation à une réunion. Le lien mène le plus souvent à une fausse page de connexion Microsoft. Selon BleepingComputer, la campagne observée par Varonis a visé plus de 70 organisations, principalement aux États-Unis.
Le message échoue normalement à SPF et à DMARC, puisqu’il ne part pas d’un serveur autorisé. Microsoft indique que Direct Send ne contourne pas l’anti-spam et que les messages suspects peuvent être filtrés. En pratique, plusieurs analyses montrent que des exceptions locales, comme des expéditeurs autorisés ou des règles qui abaissent le score de spam, laissent passer une partie de ces messages. ReliaQuest cite le cas d’un message d’hameçonnage arrivé en boîte de réception parce que le dirigeant usurpé figurait parmi les expéditeurs autorisés.
RejectDirectSend : ce que fait le réglage
Microsoft a présenté le 28 avril 2025 un réglage à l’échelle du tenant, toujours en préversion publique d’après la mise à jour de son billet en mai 2026 :
Set-OrganizationConfig -RejectDirectSend $trueIl est désactivé par défaut et prend effet en une trentaine de minutes. Un message anonyme, c’est-à-dire non rattaché à un connecteur, dont l’expéditeur d’enveloppe (MAIL FROM) appartient à un domaine accepté, est alors refusé :
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sourcesMicrosoft précise les limites de ce contrôle. Il ne regarde que le domaine de l’enveloppe, pas l’adresse affichée dans le champ From. Il ne concerne que les messages qui ne passent par aucun connecteur. Et il ne protège pas contre l’usurpation d’autres domaines, qui reste du ressort des protections habituelles.
Le contournement : un expéditeur d’enveloppe vide
Le 4 septembre 2026, ReliaQuest a publié le résultat de deux envois de test. Le premier, avec un expéditeur d’enveloppe appartenant au domaine du tenant, a été refusé comme prévu. Le second utilisait une enveloppe vide :
MAIL FROM:<>
From: Support IT <support@example.fr>Il a été accepté. Le contrôle n’a rien à comparer : une enveloppe vide n’a pas de domaine. L’adresse visible, elle, reste celle de l’entreprise. Une enveloppe vide est normalement réservée aux messages de non-remise (bounces), ce qui la rend légitime au niveau du protocole.
ReliaQuest précise qu’il ne s’agit pas d’une faille logicielle de Microsoft et qu’aucun compte compromis n’est nécessaire. Ses exemples couvrent des campagnes de septembre 2025 à août 2026. Point important : selon le même rapport, un connecteur entrant limité par adresse IP a bloqué toutes les tentatives Direct Send, y compris celles à enveloppe vide.
La configuration qui ferme la porte
1. Inventorier les vrais usages de Direct Send
Avant de bloquer, il faut savoir qui utilise Direct Send légitimement : copieurs, scanners, logiciels de facturation, supervision. Microsoft propose un rapport de suivi des changements dans le centre d’administration Exchange (en préversion) qui fait apparaître ce trafic. Notre article sur SMTP AUTH Basic et les imprimantes détaille cet inventaire.
2. Rattacher les sources légitimes à un connecteur
Microsoft recommande de créer un connecteur entrant de type partenaire, de préférence fondé sur un certificat, sinon sur les adresses IP publiques de vos sites. Les messages de ces sources sont alors attribués au connecteur et ne sont plus anonymes. Pour un fournisseur sans IP fixe ni certificat, Microsoft évoque une règle de transport fondée sur un en-tête spécifique.
3. Activer RejectDirectSend
Une fois les sources légitimes rattachées, activez le réglage. Vérifiez ensuite dans les traces de messages (Get-MessageTraceV2, puis Get-MessageTraceDetailV2) que les flux des appareils passent bien par le connecteur.
4. Retirer les exceptions qui désactivent le filtrage
Supprimez les expéditeurs et domaines autorisés qui portent sur votre propre domaine, ainsi que les règles de transport qui forcent un score de spam faible. Ce sont elles qui transforment un message usurpé en message « de confiance ».
5. Publier DMARC en application
Une politique p=reject sur votre domaine ne remplace pas les mesures ci-dessus, mais elle renforce le verdict des filtres sur les messages non authentifiés. Voir notre méthode pour configurer SPF, DKIM et DMARC sans casser vos envois.
6. Surveiller les enveloppes vides
ReliaQuest recommande de rechercher les messages dont l’expéditeur d’enveloppe est vide alors que l’adresse affichée appartient à votre domaine, en les distinguant des vrais avis de non-remise.
Un point de vigilance sur SPF
Les recommandations divergent. Rapid7 et Varonis conseillent un SPF strict (-all) pour faire échouer nettement les messages usurpés. Microsoft recommande plutôt ~all dans certains contextes pour éviter des rejets lors de routages complexes. Le bon choix dépend de vos flux : il se décide après inventaire, pas par réflexe. Notre article sur la syntaxe SPF explique la différence entre ces qualificatifs.
FAQ
Direct Send est-il une faille de Microsoft 365 ?
Non. C’est une fonction prévue pour des appareils internes. Le risque vient de son ouverture par défaut et des exceptions de filtrage ajoutées localement.
RejectDirectSend suffit-il à bloquer l’usurpation interne ?
Non. Il ne contrôle que le domaine de l’expéditeur d’enveloppe. Un message à enveloppe vide n’est pas concerné, d’après les tests publiés par ReliaQuest en septembre 2026.
Mes imprimantes vont-elles cesser d’envoyer si j’active le réglage ?
Oui, si elles envoient en Direct Send sans être rattachées à un connecteur. Il faut d’abord créer un connecteur partenaire par IP ou par certificat.
Quel code d’erreur signale un rejet RejectDirectSend ?
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources.
DMARC p=reject protège-t-il contre Direct Send ?
Il aide, mais il ne suffit pas si des exceptions locales abaissent le filtrage. Il doit être combiné au connecteur et à RejectDirectSend.
Conclusion
Direct Send illustre un risque fréquent : une fonction pratique, ouverte par défaut, que personne n’a inventoriée. Le réglage RejectDirectSend est utile, mais il ne ferme pas toutes les portes. La configuration robuste combine un connecteur entrant limité à vos sources, RejectDirectSend, le retrait des exceptions de filtrage et DMARC en application. Notre prestation de protection contre l’usurpation de domaine inclut cette vérification pour les tenants Microsoft 365.
Sources et références
- Microsoft Exchange Team — Introducing more control over Direct Send in Exchange Online (avril 2025, mis à jour en mai 2026)
- Microsoft Learn — Configurer un appareil ou une application pour envoyer des emails avec Microsoft 365
- Cyber Security News — ReliaQuest : un champ vide contourne le contrôle Direct Send (4 septembre 2026)
- ReliaQuest — One blank field bypasses Direct Send control
- BleepingComputer — Microsoft 365 Direct Send abused to send phishing as internal users (juin 2025)
- Rapid7 — Microsoft 365 Direct Send abuse