Dans l’écosystème Microsoft Cloud, le sujet Azure SMTP apparaît dès qu’une application, une VM ou un site doit envoyer des notifications sans dépendre d’un serveur mail bricolé. Je vais aller droit au but: ce qui fonctionne réellement, les réglages à utiliser, les limites de débit et les cas où Microsoft 365 reste pertinent. Le point important, c’est d’éviter un montage fragile qui marche en test puis casse en production.
En pratique, il faut d’abord choisir le bon chemin d’envoi, puis seulement la configuration
- Azure Communication Services est aujourd’hui le choix le plus propre pour une application Azure qui envoie des mails transactionnels.
- Le couple
smtp.azurecomm.net+ port587est la base la plus solide, avecTLS 1.2+. - Le port
25reste le point de friction le plus fréquent dans Azure, surtout si vous voulez faire du relais direct. - Les quotas par défaut sont modestes: 30 envois par minute, 100 par heure, 50 destinataires par message et 10 MB de taille totale.
- Si vous venez de Microsoft 365, la Basic Auth de SMTP AUTH n’est plus une base saine en 2026.
Le vrai sens d’Azure SMTP aujourd’hui
Je le formule simplement: il ne s’agit pas d’un “serveur SMTP Azure” universel, mais d’un ensemble de chemins possibles pour faire sortir un email depuis une application hébergée dans le cloud. On distingue toujours le transport, l’authentification et la politique réseau. Si l’un de ces trois étages est mal choisi, l’envoi devient instable, lent ou impossible.
Dans la pratique, je regarde d’abord le type d’email. Pour des confirmations, alertes, réinitialisations de mot de passe ou reçus, l’envoi est transactionnel et doit être fiable, rapide et traçable. Pour des campagnes marketing, on ne devrait pas partir du même design, car les volumes, les quotas et la réputation de domaine ne se gèrent pas de la même façon.
Cette distinction aide aussi à éviter un réflexe courant: vouloir faire parler une application Azure comme si elle était un vieux serveur de messagerie interne. C’est souvent là que les problèmes commencent, et c’est précisément ce qui mène à la question du bon relais. La suite consiste donc à comparer les options vraiment utiles.
Le bon choix entre Azure Communication Services et Microsoft 365
La voie officielle pour envoyer des emails via SMTP dans Azure passe le plus souvent par Azure Communication Services. La documentation Microsoft montre un schéma clair: un domaine vérifié, une application Microsoft Entra, un nom d’hôte dédié et une authentification moderne basée sur un secret d’application. C’est ce que je privilégie pour une application qui vit déjà dans Azure.
| Solution | Quand je la choisis | Points forts | Limites |
|---|---|---|---|
| Azure Communication Services Email | Application Azure, mails transactionnels, besoin d’un relais moderne | Hôte dédié, authentification moderne, domaine vérifié, montée en charge possible | Quotas initiaux, domaine à configurer, pièces jointes et destinataires limités |
| SMTP AUTH Microsoft 365 | Vous avez déjà des boîtes mail Microsoft 365 et un besoin simple | Facile à comprendre, intégré au tenant | Basic Auth retirée en 2026, limites de boîte aux lettres, moins adapté à une appli Azure |
| SMTP relay Microsoft 365 | Scanners ou applis on-prem avec IP statique | Pas besoin de boîte aux lettres, limites plus hautes | Je ne le retiens pas pour un service hébergé dans Azure |
Mon repère simple: si le code tourne dans Azure, je pars sur ACS; si l’organisation est déjà centrée sur Microsoft 365 et que le besoin reste modeste, j’évalue SMTP AUTH avec OAuth; si l’on me parle de relais Microsoft 365 depuis une appli Azure, je décline d’emblée. Avant de configurer quoi que ce soit, il faut justement clarifier ce qui se passe sur le réseau.
Pourquoi le port 25 complique les choses
Le port 25 n’est pas un simple détail technique. Dans Azure, il est souvent bloqué par défaut sur les VM, et quand il ne l’est pas, il reste tributaire du type de souscription, des politiques réseau et de la réputation de sortie. En clair, compter sur lui pour un nouveau projet revient souvent à construire sur du sable.
Je conseille donc de traiter le port 25 comme une exception, pas comme une stratégie. Même lorsqu’une exemption existe pour certains environnements Enterprise Dev/Test, ce n’est pas une promesse universelle, et surtout ce n’est pas la voie la plus propre pour un service applicatif moderne. Le port 587, lui, s’aligne bien mieux avec un envoi authentifié et chiffré.
Le vrai test est simple: si votre application ne sait fonctionner qu’en port 25 sans TLS solide, le problème n’est pas Azure, c’est le modèle d’envoi lui-même. C’est à partir de là qu’il devient logique de passer à une configuration plus explicite.
Configurer l’envoi SMTP avec Azure Communication Services
La mise en place est plus simple qu’elle n’en a l’air, mais elle exige de l’ordre. L’authentification repose sur smtp.azurecomm.net, le port 587 recommandé, TLS 1.2+ et une application Microsoft Entra. Pour un test de base, le coût reste de l’ordre de quelques centimes de dollar, ce qui permet de valider la chaîne sans gros budget.
| Paramètre | Valeur | Pourquoi c’est important |
|---|---|---|
| Serveur | smtp.azurecomm.net |
Point d’entrée du service |
| Port | 587 |
Recommandé pour l’envoi authentifié |
| Chiffrement | TLS 1.2+ |
Évite l’envoi en clair |
| Authentification | Nom SMTP + secret de l’application Entra | Sécurise la soumission |
| Adresse d’expédition | Domaine vérifié | Réduit les rejets et les alertes antispam |
- Créer la ressource Azure Communication Services et la ressource Email associée.
- Relier un domaine vérifié ou un sous-domaine dédié à l’envoi.
- Enregistrer une application Microsoft Entra et créer un secret client.
- Créer le nom d’utilisateur SMTP associé à cette application.
- Configurer votre application avec l’hôte, le port, TLS et les identifiants.
- Envoyer un premier test vers une seule adresse et vérifier le statut de livraison.
Si vous en êtes encore au premier déploiement, je recommande de tester avec un expéditeur neutre, puis de valider SPF et DKIM, c’est-à-dire l’authentification du domaine et la signature du message, avant d’ouvrir la charge. Les petites erreurs de domaine coûtent beaucoup plus cher que la configuration elle-même. Et c’est là que la section suivante devient utile, car les quotas et la taille des messages changent vite la donne.
Les limites qui comptent vraiment en production
Sur un service neuf, les quotas initiaux sont souvent le vrai sujet. Pour les domaines personnalisés, Azure Communication Services autorise par défaut 30 envois par minute et 100 par heure. Le service accepte aussi jusqu’à 50 destinataires par email et une taille totale de requête de 10 MB. Comme les pièces jointes sont encodées en Base64, la taille utile réelle est plus basse d’environ 33 %.
| Limite | Valeur | Conséquence pratique |
|---|---|---|
| Envois par minute | 30 | Batch à découper |
| Envois par heure | 100 | Inadéquat pour gros lots sans montée de quota |
| Destinataires par message | 50 | Évite les listes trop larges |
| Taille totale | 10 MB | Les pièces jointes grossissent à cause du Base64 |
| Pièces jointes étendues | Jusqu’à 30 MB avec demande | Au-delà, mieux vaut passer par Azure Blob Storage |
Le service peut monter bien plus haut, jusqu’à 1 à 2 millions de messages par heure, mais seulement après augmentation de quota et avec une réputation de domaine maîtrisée. Mon approche est simple: j’augmente le volume sur deux à quatre semaines, je surveille le taux d’échec et je n’essaie pas de forcer la cadence tant que les rejets dépassent 1 %.
Les demandes d’augmentation peuvent prendre jusqu’à 72 heures pour être évaluées, et les quotas plus élevés ne sont disponibles que pour les domaines personnalisés vérifiés, pas pour les domaines gérés par Azure. Si vous dépassez les limites, ne contournez pas le problème avec des scripts parallèles. Demandez l’augmentation de quota et nettoyez d’abord la qualité d’envoi; sinon vous allez surtout accélérer vos échecs. C’est ce cadrage qui prépare bien la comparaison avec Microsoft 365.
Quand SMTP AUTH Microsoft 365 reste pertinent
Je garde SMTP AUTH Microsoft 365 surtout pour des scénarios où tout est déjà centré sur des boîtes aux lettres Microsoft 365 et où le besoin d’envoi reste simple. La documentation Microsoft rappelle toutefois qu’en 2026, l’ancien modèle en Basic Auth a été retiré; autrement dit, si vous suivez encore un vieux script avec login et mot de passe, il faut le considérer comme obsolète.
La différence clé, c’est qu’un relais SMTP Microsoft 365 n’est pas un bon plan pour une application hébergée dans Azure. Microsoft précise que ce type de relais ne doit pas servir depuis un service tiers comme Azure. Pour un poste de travail, un périphérique ou une infrastructure avec IP statique bien maîtrisée, le raisonnement peut être différent; pour une appli cloud, je préfère une architecture qui n’essaie pas de contourner ses propres contraintes.
Si le besoin s’écarte du SMTP pur, l’API Microsoft Graph devient souvent une alternative plus propre. On quitte alors le monde des ports et des relais pour aller vers une intégration plus directe, ce qui simplifie beaucoup de choses à moyen terme.
Le bon réflexe avant la mise en production
Si je devais résumer la bonne trajectoire, je dirais ceci: choisissez d’abord le service d’envoi, puis seulement le port, puis seulement les identifiants. Pour un projet Azure moderne, le trio gagnant reste généralement un domaine vérifié, un relais SMTP authentifié sur587 et une surveillance sérieuse des bounces et du taux d’échec.
Je ne construirais pas un nouveau flux d’emails autour d’un port 25 fragilisé ou d’un ancien mot de passe SMTP. En pratique, c’est presque toujours plus coûteux à maintenir, plus difficile à déboguer et moins fiable au moment où la charge monte. Une fois ces bases en place, le reste devient surtout une affaire de réputation de domaine, de quotas et de suivi opérationnel.
