Sécurisez vos Emails et Améliorez votre Délivrabilité.
Blog
Microsoft annule la limitation “bulk email” d’Exchange Online : bonne nouvelle… mais faux signal pour les campagnes email
La “bonne nouvelle” qui peut coûter cher
Début janvier 2026, Microsoft a annoncé un revirement : la Mailbox External Recipient Rate Limit d’Exchange Online — la limite qui devait plafonner l’envoi à 2 000 destinataires externes sur 24 heures, par boîte aux lettres — est annulée indéfiniment.
Sur le papier, beaucoup d’IT managers et de dirigeants de PME y verront un soulagement : “On pourra continuer à envoyer nos newsletters depuis Microsoft 365.” Dans la pratique, c’est précisément le mauvais réflexe à éviter.
Pourquoi ? Parce que Microsoft n’a pas changé sa position de fond : Exchange Online n’est pas conçu pour le bulk email ni pour le high-volume transactionnel, et il reste d’autres limites (par boîte, par tenant) qui peuvent bloquer vos envois — sans compter l’impact plus insidieux : la réputation d’envoi qui se dégrade et finit par faire tomber vos emails critiques (factures, relances, devis, notifications applicatives) en spam, voire en rejet.
Dans cet article, on va clarifier :
- Ce que Microsoft a annulé (et ce que c’était vraiment).
- Ce qui ne change pas (et ce qui peut toujours vous bloquer).
- Pourquoi M365 ne doit pas devenir votre outil marketing.
- Comment structurer une architecture email propre : transactionnel vs marketing, sous-domaines, authentification, monitoring.
- Un plan d’action pragmatique pour une PME (et pour les environnements plus gros).
1) Ce que Microsoft vient d’annuler : la limite “ERR” par boîte aux lettres
1.1 La mesure annulée : 2 000 destinataires externes / 24h / mailbox
Microsoft a confirmé le 6 janvier 2026 que la Mailbox External Recipient Rate Limit est canceled indefinitely.
Cette limite (appelée “ERR” dans les communications précédentes) visait à restreindre, par boîte aux lettres, le nombre de destinataires externes joignables sur une fenêtre glissante de 24 heures — avec un plafond de 2 000.
1.2 Pourquoi Microsoft l’avait annoncée à l’origine
Microsoft expliquait vouloir :
- Limiter l’abus des ressources Exchange Online (bulk émis via M365 au lieu d’outils dédiés) ;
- Réduire le spam et les usages malveillants (y compris via comptes compromis) ;
- Empêcher certains scénarios (ex. applications métiers envoyant en masse via Exchange Online).
1.3 Le mécanisme prévu : un sous-plafond “externe” à l’intérieur d’un plafond global
Le point clé (souvent mal compris) : la limite ERR devait fonctionner comme un sous-plafond à l’intérieur de la Recipient Rate Limit (RRL). Microsoft rappelait qu’Exchange Online applique un plafond global de 10 000 destinataires sur 24 heures (fenêtre glissante), et que les 2 000 externes devaient devenir un sous-ensemble de ces 10 000.
En clair, le message était :
Vous pouvez envoyer jusqu’à 10 000 destinataires au total sur 24h,
mais au plus 2 000 externes sur la même période (si la règle avait été appliquée).
Ce dispositif précis est désormais annulé indéfiniment.
2) Ce qui ne change pas : les limites qui existent déjà (et qui comptent vraiment)
L’annonce de Microsoft est explicite :
- l’annulation de l’ERR ne change pas :
- la Recipient Rate Limit (RRL)
- la Tenant-level External Recipient Rate Limit (TERRL)
C’est ici que beaucoup d’organisations se trompent : elles retiennent “Microsoft a annulé la limite” et oublient que d’autres plafonds restent actifs et peuvent provoquer des blocages ou des restrictions.
2.1 La Recipient Rate Limit (RRL) : plafond par boîte aux lettres
Microsoft décrit la RRL comme un mécanisme de limitation de service (plafonds) appliqué à Exchange Online.
À retenir :
La RRL reste en place.
Les limites exactes et leurs modalités (24h glissantes, etc.) doivent être lues comme des service limits : ce n’est pas un “droit à faire du bulk”, c’est un plafond technique.
2.2 La TERRL : plafond tenant-wide sur les destinataires externes
Depuis 2025, Microsoft a introduit des Tenant Outbound Email Limits, et notamment la Tenant External Recipient Rate Limit (TERRL), qui limite le nombre total de destinataires externes qu’un tenant peut joindre sur une fenêtre glissante de 24 heures.
Points structurants :
- Définition : la TERRL est le maximum de destinataires externes joignables par le tenant (sur 24h glissantes).
- Externe : un destinataire est externe si son domaine n’est pas un “accepted domain” du tenant (y compris vers d’autres tenants M365).
- Comptage : c’est du “par destinataire”, pas du “par destinataire unique” (100 mails vers 5 personnes = 500).
- Blocage : au dépassement, Exchange Online peut bloquer les envois externes avec des NDR spécifiques (550 5.7.232 / 550 5.7.233).
- Les seuils TERRL : trial vs non-trial
Microsoft donne des seuils très concrets :
- Trial tenants : 5 000 destinataires externes / jour
- Non-trial tenants : seuil basé sur le nombre de licences email, avec une formule :
- 500 × (Nombre de licences email non-trial ^ 0.7) + 9 500
- Microsoft fournit aussi des exemples (1 licence = 10 000 externes/jour, 100 licences ≈ 22 059, 1 000 licences ≈ 72 446).
2.3 Les politiques de spam sortant (Defender) : restrictions “humaines” et sanctions
Au-delà des limites “service”, Microsoft Defender for Office 365 permet de configurer des outbound spam policies avec des message limits (externes par heure, internes par heure, total par jour) et des actions de restriction (blocage jusqu’au lendemain, blocage administrateur, alerting). Microsoft Learn
Ces mécanismes sont importants car ils expliquent un scénario courant : ce n’est pas seulement un quota dépassé, c’est aussi un compte restreint parce que le comportement ressemble à du spam (volume, taux de plainte, listes non propres, contenu).
3) ERR, RRL, TERRL : tableau de lecture simple (pour éviter les confusions)
Les deux informations “à emporter” :
Microsoft a retiré un garde-fou (ERR) mais laisse les autres.
Microsoft rappelle que l’objectif reste de combattre l’abus et d’empêcher l’usage d’Exchange Online comme plateforme de bulk.
4) Pourquoi Microsoft a reculé (et ce que ça révèle sur le marché)
Dans son annonce, Microsoft indique que les clients ont remonté des “significant operational challenges”, notamment parce que les offres alternatives de bulk sending sont perçues comme insuffisantes ou difficiles à absorber (outillage, coûts, complexité).
Cela met en évidence une réalité :
- Des entreprises utilisent M365 pour des volumes qui ressemblent déjà à du marketing ou du transactionnel.
- Elles le font souvent “parce que c’est là”, sans gouvernance des flux.
- Et l’industrie email durcit les exigences (authentification, plainte spam, désinscription, etc.), ce qui rend ces pratiques plus risquées.
Ce recul ne signifie pas que Microsoft valide le bulk via M365 ; il signifie surtout qu’ils cherchent un moyen moins disruptif de traiter la même problématique.
5) Le piège classique : newsletter depuis M365 → réputation dégradée → emails critiques impactés
5.1 Le scénario (très fréquent en PME)
“On a déjà Microsoft 365, on va envoyer la newsletter depuis Outlook.”
On exporte une liste (parfois ancienne, partiellement opt-in, peu nettoyée).
On envoie à plusieurs milliers de contacts (souvent en Cci, ou via un groupe).
Résultat :
- bounces (hard/soft)
- plaintes (signalements spam)
- désengagement (faible interaction)
Les signaux réputationnels se dégradent, parfois progressivement.
Quelques jours plus tard : “Nos devis arrivent en spam chez Gmail / Outlook / Orange.”
5.2 Pourquoi c’est dangereux : M365 mélange vos usages
Le problème structurel n’est pas seulement le volume. C’est le mélange des flux :
- Emails “humains” (dirigeant, équipe commerciale, ADV)
- Emails opérationnels (factures, relances, confirmations)
- Éventuelles automatisations (applications, CRM, notifications)
- Et, par-dessus, une “campagne” envoyée à froid
Si vous dégradez la réputation, ce ne sont pas seulement vos newsletters qui souffrent : ce sont vos emails métier.
5.3 Et quand Microsoft juge que le comportement est “spammy”
Dans certains cas, la mécanique devient punitive :
- restrictions automatiques,
- alertes,
- impossibilité d’envoyer jusqu’au lendemain,
- ajout dans des listes de “restricted users” selon les politiques.
Là encore, l’annulation de l’ERR ne protège pas contre ces garde-fous.
6) Pourquoi M365 n’est pas un ESP marketing (même si “ça marche” parfois)
Microsoft est très clair dans ses communications : Exchange Online ne supporte pas le bulk/high-volume transactional, et si vous avez un besoin de volume externe, Microsoft recommande des offres dédiées (ex. Azure Communication Services Email, selon les cas).
Au-delà de l’argument d’autorité, il y a un vrai sujet technique et opérationnel :
6.1 Un ESP marketing, ce n’est pas “juste un SMTP”
Un ESP sérieux fournit :
- gestion de bounces et suppression automatique,
- traitement des plaintes (feedback loops, mécanismes de conformité),
- désinscription robuste (one-click, headers, pages),
- segmentation et pression marketing,
- warm-up / ramp-up,
- analytics, et surtout une infrastructure conçue pour absorber du volume.
M365, lui, est conçu pour la messagerie d’entreprise, pas la délivrabilité marketing à grande échelle.*
6.2 Gouvernance : consentement, hygiène, fréquence
Les campagnes email ont une exigence de gouvernance :
- preuve de consentement / collecte propre,
- hygiène de base (suppression des inactifs, invalides, pièges),
- pilotage par lots,
- maîtrise de la fréquence,
- scénarios de réactivation.
Sans cela, vous payez en réputation.
7) La bonne approche : séparer les flux (transactionnel vs marketing) et isoler la réputation
Si vous deviez retenir une recommandation opérationnelle :
séparez les flux et isolez les risques.
7.1 Le modèle le plus simple (et efficace)
- Domaine principal (ex. entreprise.fr) : échanges humains, emails critiques (factures, devis), faible volume, exigence forte de réputation.
- Sous-domaine marketing (ex. news.entreprise.fr ou mail.entreprise.fr) : newsletters, nurturing, événements.
- Sous-domaine applicatif (ex. notify.entreprise.fr) : notifications techniques / transactionnel.
Pourquoi ? Parce que les filtres anti-spam raisonnent fortement par réputation de domaine (et parfois de sous-domaine), et parce que vous devez pouvoir “casser” un flux sans détruire les autres.
7.2 Authentification : SPF/DKIM/DMARC, mais surtout alignement
L’authentification seule ne “garantit” pas l’inbox, mais elle est la base :
- SPF valide l’IP/serveur autorisé,
- DKIM signe le message,
- DMARC impose l’alignement et la politique.
Sur un flux marketing, vous devez viser :
- DKIM actif et stable,
- DMARC au minimum en p=none puis montée progressive selon maturité,
- et une gouvernance stricte sur les expéditeurs autorisés.
7.3 Pilotage par lots et monitoring
Pour le marketing, l’envoi “en un gros blast” est un anti-pattern. Préférez :
envois par segments,
ramp-up maîtrisé,
analyse des signaux (bounces, plaintes, engagement),
et une boucle de correction.
8) “OK, mais concrètement : puis-je envoyer une campagne depuis M365 ?”
Réponse professionnelle : possible, mais à cadrer très strictement. L’annulation de l’ERR ne change pas cette posture.
8.1 Cas où M365 peut convenir (tolérable)
Communication interne (ou quasi interne)
Petites communications externes : partenaires, clients actifs, volume faible
Invitations ciblées (liste très propre, faible fréquence)
Messages transactionnels très limités (et idéalement via mécanisme adapté)
8.2 Cas où c’est une mauvaise idée
Newsletter récurrente à plusieurs milliers de contacts
Base ancienne/non nettoyée
Prospection email “semi-automatisée”
Envois applicatifs (ERP/CRM) via une mailbox partagée
Toute stratégie où la réputation du domaine principal est un actif critique
8.3 La règle simple
Si l’email est marketing (ou ressemble à du marketing), utilisez un canal marketing.
Si l’email est applicatif (volume, événements, notifications), utilisez un canal applicatif.
Réservez M365 au humain et aux communications critiques à faible volume.
9) Ce que Microsoft recommande quand vous avez besoin de volume
Dans ses communications sur les limites tenant-wide, Microsoft indique que si vous avez besoin d’envoyer plus d’emails à des destinataires externes que votre limite ne le permet, il faut envisager une solution dédiée ; Microsoft cite notamment Azure Communication Services Email pour le bulk/high-volume vers l’externe.
Même si vous ne choisissez pas cette option précise, le principe est important : découpler l’email “service/volume” de votre messagerie collaborative.
10) Comment surveiller et éviter les mauvaises surprises (quota, blocage, réputation)
10.1 Suivre la TERRL : reporting EAC
Microsoft décrit un rapport dans l’Exchange Admin Center permettant de suivre la consommation et l’état d’enforcement (EAC > Reports > Mail flow > Tenant Outbound External Recipients).
Même si votre usage “normal” n’approche pas le plafond, ce rapport sert à détecter :
- des envois applicatifs mal gouvernés,
- une fuite (compte compromis),
- un outil tiers mal configuré,
- une campagne “improvisée”.
10.2 Vérifier l’état via PowerShell
Microsoft indique la possibilité de récupérer des informations relatives à l’enforcement via des cmdlets Exchange Online (ex. Get-LimitsEnforcementStatus).
Objectif : intégrer un contrôle périodique et déclencher un diagnostic avant que le blocage ne touche l’activité.
10.3 Côté Defender : politiques et alerting
Les outbound spam policies permettent de définir des limites additionnelles et des actions de restriction, avec alertes aux admins. Microsoft Learn
Recommandation opérationnelle : ne laissez pas “service defaults” sans gouvernance si vous avez déjà eu des incidents (compte compromis, campagnes mal envoyées, applications bruyantes).
11) Plan d’action pragmatique (PME) : en 7 étapes
Étape 1 — Cartographier vos sources d’envoi (1–2 h)
Listez :
utilisateurs humains,
boîtes partagées,
applications (ERP, CRM, site web, formulaires),
prestataires (facturation, support, marketing),
et “scripts maison”.
Étape 2 — Classer les emails en 3 flux
Humain (conversation)
Marketing (campagnes, newsletters, invitations)
Applicatif/transactionnel (événements, confirmations, alertes)
Étape 3 — Décider l’architecture cible
Humain : M365 (domaine principal)
Marketing : ESP + sous-domaine dédié
Applicatif : ESP transactionnel / SMTP relay / service dédié (selon cas)
Étape 4 — Mettre en place l’authentification et l’alignement
SPF/DKIM/DMARC par flux, en gardant une gouvernance stricte.
Étape 5 — Mettre en place un monitoring minimal
suivi quotas / rapports (TERRL)
suivi réputation (Gmail Postmaster, Microsoft SNDS si applicable, etc.)
suivi plaintes et bounces côté ESP
Étape 6 — Définir des règles “anti-dérapage”
Exemples :
interdiction d’envoyer une newsletter depuis Outlook,
processus de validation (liste, contenu, volume),
envois par lots,
nettoyage périodique des listes.
Étape 7 — Documenter et former (courte formation interne)
Le plus gros risque en PME est rarement “technique” : c’est une décision improvisée (“je fais un envoi à toute la base”) sans comprendre l’impact.
Conclusion : oui, Microsoft a reculé… non, ce n’est pas un feu vert
L’annulation de la limite “2 000 externes par mailbox” est un signal important, mais il ne doit pas être interprété comme une autorisation implicite de faire du marketing depuis Exchange Online. Microsoft maintient les autres plafonds (par boîte, par tenant) et continue d’affirmer qu’Exchange Online n’est pas une plateforme de bulk/high-volume.
Le bon choix, surtout en PME, est rarement “comment contourner une limite”. C’est :
- séparer les flux,
- isoler la réputation,
- utiliser le bon outil pour le bon usage,
- et monitorer avant l’incident.