L’alerte arrive souvent d’un responsable informatique ou d’un directeur opérationnel : « Notre logiciel de gestion n’envoie plus ses notifications par email et ça fonctionnait très bien avant. »
Chez Infologo, prestataire IT basé à Genève et Lausanne, on reçoit ce type d’appel régulièrement depuis que Microsoft a durci les règles d’authentification sur Microsoft 365. Le problème n’est pas anodin : une application qui ne peut plus envoyer d’emails, c’est des confirmations de commande qui disparaissent, des alertes critiques qui n’arrivent jamais, des processus métier qui tombent silencieusement. Faisons le point.
Ce que Microsoft 365 accepte et ce qu’il refuse
Le SMTP Relay sur Microsoft 365 désigne la capacité d’un équipement ou d’une application tierce (scanner, ERP, logiciel de facturation, système de ticketing) à envoyer des emails via les serveurs Exchange Online de Microsoft, sans qu’un utilisateur soit directement connecté. Microsoft documente trois méthodes d’envoi : le client SMTP authentifié (AUTH SMTP), le relais SMTP direct, et la connexion via un connecteur entrant.
La méthode AUTH SMTP est la plus utilisée par défaut. Elle fonctionne avec un compte Microsoft 365 et un mot de passe, ce qui la rend accessible. Mais depuis le déploiement de l’authentification moderne et la désactivation progressive de l’authentification basique par Microsoft, beaucoup d’applications configurées avec cette méthode ont simplement cessé de fonctionner, sans message d’erreur clair.
Le relais SMTP direct, lui, ne nécessite pas d’authentification par compte utilisateur. C’est souvent la bonne solution pour les équipements réseau ou les applications qui ne savent pas gérer OAuth. Mais il impose une condition que beaucoup d’entreprises ignorent au départ : l’application ou l’équipement doit pouvoir envoyer depuis une adresse IP publique fixe, déclarée explicitement dans le connecteur Microsoft 365.
Pourquoi l’IP publique fixe est non négociable ?
C’est là que la plupart des configurations échouent. Microsoft utilise l’adresse IP source pour valider les messages entrants sur le connecteur SMTP : si l’IP change, le message est refusé ou silencieusement abandonné. Pas d’erreur explicite dans beaucoup de cas, juste un email qui ne part pas.
Un client dans le canton de Vaud nous a contactés après avoir passé plusieurs semaines à chercher le problème. Leur scanner multifonction envoyait des PDF par email depuis des années. Après un changement d’opérateur internet, l’IP publique avait changé, et les envois avaient cessé du jour au lendemain. Le connecteur Microsoft 365 avait simplement besoin d’être mis à jour avec la nouvelle adresse, mais personne n’avait fait le lien entre les deux événements.
Ce n’est pas un cas isolé. Sur les interventions de ce type que nous avons traitées ces douze derniers mois, l’absence d’IP fixe ou une IP non déclarée dans le connecteur était à l’origine du blocage dans la majorité des situations. L’autre cause fréquente : un connecteur mal configuré, avec un domaine d’expéditeur qui ne correspondait pas aux règles SPF et DKIM de la messagerie.
Les trois questions à poser avant de configurer quoi que ce soit
Avant de toucher à une configuration SMTP, on pose systématiquement les mêmes questions :
- L’application ou l’équipement dispose-t-il d’une IP publique fixe ?
- Si non, peut-on en obtenir une auprès du fournisseur d’accès ?
- Et quel type d’authentification supporte l’application : AUTH SMTP classique, OAuth, ou aucune ?
La réponse à ces trois questions détermine quelle méthode utiliser. Forcer une configuration AUTH SMTP sur une application qui ne gère pas l’authentification moderne va juste créer un blocage supplémentaire après la prochaine mise à jour de sécurité Microsoft. Ce n’est pas une solution robuste, c’est un contournement avec une date d’expiration.
Si l’application ne supporte ni OAuth ni une IP fixe, l’alternative est de passer par un service de relais SMTP tiers (SendGrid, Mailjet, Postmark), qui accepte une authentification par clé API et n’impose pas de contrainte réseau. C’est parfois la solution la moins coûteuse à maintenir sur la durée.
Ce qu’on recommande chez Infologo
La configuration SMTP Relay sur Microsoft 365 n’est pas complexe en soi, mais elle est mal documentée pour des profils non techniques, et les messages d’erreur de Microsoft ne sont pas toujours explicites sur la cause réelle du blocage.
Notre recommandation est directe : si votre organisation utilise Microsoft 365 et que vous avez des applications ou équipements qui envoient des emails automatiques, vérifiez dès maintenant si ces envois passent par un compte AUTH SMTP avec authentification basique. Si c’est le cas, le service peut cesser de fonctionner lors de la prochaine mise à jour de politique de sécurité Microsoft, sans préavis. Anticiper cette migration vaut mieux que la gérer en urgence un lundi matin.
On déconseille de multiplier les comptes de service dédiés à l’envoi SMTP sans les auditer régulièrement. Ces comptes sont souvent créés pour résoudre un problème ponctuel, puis oubliés, tout en maintenant des accès actifs à votre tenant Microsoft 365.
Si votre configuration actuelle vous paraît floue ou si vous avez récemment changé d’opérateur internet, contactez-nous pour un audit de votre relais SMTP. On identifie le problème en quelques heures, sans engagement.
