Dépannage de la messagerie Dolibarr × Microsoft 365

Configurer la messagerie Dolibarr × Microsoft 365 — Guide de référence
01 / 15
— Guide de référence

Configurer la
messagerie
Dolibarr ×
Microsoft 365.

Prérequis, méthodes d’authentification, procédure pas à pas et résolution des incidents d’envoi entre Dolibarr et Microsoft 365.

Édition Avril 2026
Audience IT client + utilisateurs métier
Format Slides + Livre blanc
02 / 15
Sommaire

Ce qu’on va couvrir.

Un parcours structuré pour passer de « pourquoi ça ne marche pas ? » à « tout est sous contrôle ». Les 4 premières sections cadrent le problème, les 4 suivantes donnent la solution opérationnelle.

  1. Pourquoi ce document existe2 min
  2. Le parcours d’un e-mail — schéma2 min
  3. Glossaire des termes essentiels3 min
  4. Qui fait quoi : Microsoft, Dolibarr, vous3 min
  5. La fin de Basic Auth — calendrier officiel2 min
  6. Les deux méthodes possibles aujourd’hui3 min
  7. Prérequis Microsoft 365 / Azure4 min
  8. Recette OAuth2 pas à pas6 min
  9. Configuration SMTP basique (transition)3 min
  10. Erreurs fréquentes & traduction5 min
  11. Cas pratique : lire une erreur réelle4 min
  12. Checklist de mise en service2 min
  13. Répartition des rôles2 min
03 / 15
Le problème, sans détour

Localiser la cause réelle.

L’envoi d’e-mails ne fonctionne pas, l’erreur d’authentification revient — c’est forcément Dolibarr. — L’hypothèse la plus fréquente, rarement la bonne

Dans la majorité des cas où l’envoi d’e-mails échoue avec un message d’authentification, la cause se trouve dans la configuration Microsoft 365 / Azure, pas dans Dolibarr.

Côté Dolibarr, la configuration tient en cinq champs : un hôte SMTP, un port, un identifiant, un mot de passe (ou un jeton OAuth2), et un mode TLS. C’est tout.

Côté Microsoft, c’est une autre histoire : politiques de sécurité par défaut, MFA, conditional access, scopes OAuth qui changent, app registration mal calibrée, SMTP AUTH désactivé au niveau du tenant ou de l’utilisateur…

Côté Dolibarr — surface d’erreur

5 champs. Pas plus.

Hôte SMTP, port, identifiant, mot de passe ou jeton, mode chiffrement. Si ces 5 valeurs sont bonnes, Dolibarr envoie.

Côté Microsoft — surface d’erreur

15+ paramètres répartis sur 4 consoles.

Entra, Exchange Online, paramètres utilisateur, Conditional Access, scopes API, app permissions, redirect URI, secrets qui expirent…

L’objectif de ce document est de localiser précisément la responsabilité.
04 / 15
Comment un e-mail voyage

Le parcours d’un
e-mail Dolibarr.

Avant de plonger dans la technique, voici ce qui se passe vraiment quand vous cliquez sur « Envoyer un devis » dans Dolibarr. Le trajet en 5 étapes, et où chaque acteur intervient.

Schéma de principe : parcours d’un e-mail Dolibarr vers un destinataire Diagramme en cinq étapes montrant comment Dolibarr envoie un e-mail à travers Microsoft 365 jusqu’au destinataire, avec les zones de responsabilité. — ZONE DOLIBARR — ZONE MICROSOFT 365 — ZONE DESTINATAIRE ÉTAPE 1 Dolibarr prépare le message (devis, facture…) SMTP ÉTAPE 2 Authentification « Qui êtes-vous ? » ÉTAPE 3 Vérifications SPF, DKIM, droits d’envoi ÉTAPE 4 Routage vers le bon serveur Internet ÉTAPE 5 Boîte mail du destinataire (reçu ou en spam) Configuration locale 5 champs côté Dolibarr 95 % des erreurs viennent d’ici tenant, utilisateur, app registration, scopes, MFA, conditional access… DNS & filtrage anti-spam si reçu mais en spam

Lecture du schéma : Dolibarr ne fait que présenter un message à Microsoft 365 avec ses identifiants. Tout ce qui se passe ensuite — vérifier l’identité, contrôler les droits, autoriser ou refuser, router le mail — se passe entièrement dans Microsoft. Si une erreur d’authentification survient, c’est dans la zone bleue centrale qu’il faut aller chercher, pas dans la zone Dolibarr.

05 / 15
Glossaire

Les mots qu’on entend,
expliqués simplement.

Quelques termes techniques reviennent dans toutes les conversations. Voici de quoi suivre une discussion sans se sentir perdu.

Microsoft

Tenant

L’espace Microsoft 365 de votre entreprise. Chaque société a son propre tenant, identifié par un code unique. C’est l’équivalent d’un immeuble dont vous êtes propriétaire : vous décidez qui entre, qui a quelles clés, et quelles règles s’appliquent.

Microsoft

Microsoft Entra (ex-Azure AD)

Le service qui gère les identités dans votre tenant : utilisateurs, mots de passe, applications autorisées, règles d’accès. C’est le concierge de l’immeuble — il sait qui peut entrer où.

Authentification

SMTP AUTH

La méthode traditionnelle par laquelle Dolibarr (ou tout autre logiciel) prouve son identité avant d’envoyer un mail : « voici mon login et mon mot de passe ». Microsoft prévoit son retrait.

Authentification

Basic Auth

Synonyme courant de l’authentification SMTP par login + mot de passe. Méthode historique en voie de retrait chez Microsoft (fin 2026 sur la plupart des comptes).

Microsoft

OAuth2 (« Modern Auth »)

La méthode moderne. Au lieu d’un mot de passe, Dolibarr reçoit un jeton de Microsoft, valable un temps limité. Plus sûr, compatible avec MFA, et c’est l’avenir imposé.

Authentification

Token / Jeton

Une chaîne de caractères que Microsoft délivre à Dolibarr après authentification. Comme un badge temporaire : valide pendant quelques heures, renouvelable automatiquement tant que tout va bien.

Authentification

Scope

Le périmètre d’action autorisé par un token. Quand Dolibarr demande un jeton, il précise « j’ai besoin du droit d’envoyer des mails ». Si Microsoft modifie ses scopes (ce qui arrive), il faut adapter Dolibarr.

Sécurité

MFA / Conditional Access

MFA = double authentification (mot de passe + code SMS/app). Conditional Access = règles automatiques de Microsoft (« bloquer les connexions hors France »). Ces deux mécanismes peuvent bloquer Dolibarr s’ils ne sont pas correctement configurés.

06 / 15
Cartographie des responsabilités

Qui paramètre quoi, et où.

Avant de chercher d’où vient une erreur, il faut savoir qui détient le levier. Voici la répartition réelle entre les deux côtés du tunnel.

Sujet
Microsoft / Azure / Entra
Dolibarr
Identité et mot de passe
Crée le compte, applique MFA, gère politiques de mot de passe et accès conditionnel.
Stocke uniquement la chaîne fournie (mot de passe ou jeton). Aucune capacité de modification.
Activation SMTP AUTH
Doit être activé au niveau du tenant et du compte utilisateur dans le centre d’administration Exchange.
N/A. Si Microsoft refuse, Dolibarr reçoit un refus et le rapporte.
App Registration (OAuth2)
Création de l’application dans Microsoft Entra, génération de l’ID client et du secret, configuration du redirect URI.
Saisit Client ID, Secret, Tenant ID, Scope dans le module OAuth.
Permissions API / Scopes
Accorde les permissions SMTP.Send, offline_access, etc. + consentement administrateur.
Demande les scopes lors de la génération du token. Si Microsoft refuse, le token n’est pas délivré.
Renouvellement du jeton
Définit la durée de vie des tokens et des refresh tokens, peut les invalider à tout moment (changement de mot de passe, révocation admin).
Utilise le refresh token pour obtenir un nouveau access token. Si le refresh token est révoqué, il faut re-générer.
DNS, SPF, DKIM, DMARC
Hébergement du domaine et entrées DNS — souvent gérés par l’IT du client ou le bureau d’enregistrement.
Aucun rôle. Mais un mail sans SPF/DKIM finit en spam, ce qui est attribué à tort à Dolibarr.
Logs d’envoi & rebonds
Message Trace dans le centre d’administration Exchange — la source de vérité.
Logs de connexion SMTP uniquement (succès/échec auth). Pas de visibilité après remise au serveur Microsoft.

Règle d’or : si l’authentification échoue avant l’envoi, c’est Microsoft. Si l’authentification réussit mais le destinataire ne reçoit rien, c’est DNS / réputation / filtrage côté Microsoft. Dolibarr n’est en cause que si la configuration des 5 champs côté Dolibarr est incorrecte.

07 / 15
Calendrier officiel Microsoft

La fin de Basic Auth :
une cible mouvante.

Microsoft a repoussé plusieurs fois la date de retrait de l’authentification basique pour SMTP AUTH. Voici la dernière timeline officielle (révisée fin janvier 2026) et ce qu’elle implique.

2019 → 2022
Retrait progressif de Basic Auth sur tous les protocoles Exchange

IMAP, POP, EWS, ActiveSync… Tous migrés vers OAuth2 fin 2022. Seul SMTP AUTH a obtenu un sursis.

Aujourd’hui
Basic Auth pour SMTP AUTH : encore actif, mais en sursis

Comportement inchangé jusqu’à fin 2026 selon la dernière annonce Microsoft. Reste fonctionnel pour les tenants qui l’ont activé.

Fin 2026
Basic Auth désactivé par défaut sur les tenants existants

Les administrateurs pourront encore le réactiver manuellement. Les nouveaux tenants créés après cette date n’auront plus du tout l’option.

2027
Annonce de la date de suppression définitive

Microsoft communiquera dans la seconde moitié de 2027 la date finale de retrait. Plus aucune dérogation possible.

Conclusion opérationnelle : tous les déploiements Dolibarr neufs doivent partir directement en OAuth2. Les déploiements existants en SMTP basique doivent planifier leur migration en 2026, sans attendre.

08 / 15
Les deux options qui restent

SMTP basique ou OAuth2.

Dolibarr supporte les deux méthodes nativement. Choisir, c’est arbitrer entre simplicité immédiate et pérennité.

SMTP Basic Auth

Hôte + identifiant + mot de passe
  • Configuration en 2 minutes côté Dolibarr
  • Aucune intervention dans Azure / Entra
  • Compatible avec tout client SMTP standard
  • Nécessite SMTP AUTH activé sur le tenant ET sur l’utilisateur
  • Incompatible avec MFA strict — un mot de passe d’application est nécessaire (encore possible sur M365 pro si l’admin l’a activé, déjà impossible sur les comptes grand public)
  • Désactivé par défaut fin 2026
  • App passwords retirés en même temps que Basic Auth

OAuth2 (Modern Auth)

App registration + jeton
  • Pérenne au-delà de 2026
  • Compatible avec MFA et Conditional Access
  • Jeton d’accès à durée limitée, refresh token automatique
  • Configuration initiale plus longue : ~30 min côté Azure + 5 min côté Dolibarr
  • Doit être refait à chaque changement de mot de passe utilisateur ou révocation admin
  • Sensible aux changements de scope côté Microsoft
  • Recommandé par Microsoft et par Dolibarr

Notre recommandation : OAuth2 par défaut sur tous les nouveaux déploiements. SMTP basique uniquement comme solution de transition courte (≤ 6 mois) ou pour des installations isolées sans MFA.

09 / 15
Avant même de toucher Dolibarr

Prérequis côté Microsoft.

Cette liste, validée avant toute configuration, élimine 80 % des allers-retours. C’est la responsabilité de l’IT du client — pas la nôtre.

Compte de service

Boîte mail dédiée

Compte utilisateur ou boîte partagée avec licence Exchange Online valide. Pas un compte personnel. Idéalement noreply@domaine ou contact@domaine.

Tenant

SMTP AUTH activé (si basique)

Centre d’admin Exchange → Paramètres → Courrier → autoriser SMTP authentifié au niveau du tenant. Puis : utilisateur → Courrier → Autoriser SMTP authentifié.

MFA

App password (cas restreint)

Encore générable sur les comptes Microsoft 365 professionnels, à condition que l’admin ait activé la fonction dans Entra → Méthodes d’authentification. Déjà supprimé sur les comptes grand public (Outlook.com, Hotmail, Live) depuis septembre 2024. Cessera de fonctionner pour SMTP en même temps que Basic Auth (fin 2026 et au-delà).

Azure

App Registration (OAuth2)

Microsoft Entra → Inscriptions d’applications → Nouvelle inscription. Type Web. URI de redirection = URL Dolibarr générée par le module OAuth.

Azure

Secret client + Permissions

Générer un secret client (noter sa date d’expiration). Ajouter les permissions API : offline_access, SMTP.Send. Consentement admin requis.

DNS

SPF, DKIM, DMARC

Domaine d’envoi vérifié dans M365. Enregistrement SPF incluant spf.protection.outlook.com. DKIM activé. DMARC en p=quarantine minimum.

10 / 15
Procédure complète

OAuth2 : la recette
qui marche.

Suivez l’ordre. Chaque étape produit une valeur utilisée à l’étape suivante. Les deux derniers blocs récapitulent ce qui doit être saisi côté Dolibarr.

  1. Microsoft Entra
    Inscrire une application

    Portail Entra → Applications → Inscriptions d’applications → Nouvelle inscription. Nom : Dolibarr-SMTP. Type de compte : organisation uniquement (single-tenant). Type Web + URI de redirection = celle affichée par Dolibarr (Configuration → Module OAuth → Microsoft).

    Récupérer : Application (client) ID + Directory (tenant) ID.

  2. Microsoft Entra
    Générer un secret client

    Application créée → Certificats & secrets → Nouveau secret client. Durée recommandée : 24 mois. Copier la valeur immédiatement — elle ne sera plus jamais affichée.

    Noter la date d’expiration dans le calendrier IT : il faudra la renouveler.

  3. Microsoft Entra
    Ajouter les permissions API

    Autorisations API → Ajouter une autorisation → Microsoft Graph → Autorisations déléguées. Sélectionner : offline_access + SMTP.Send.

    Cliquer sur Accorder un consentement administrateur. Sans ce clic, le token sera refusé même si la configuration est correcte.

  4. Dolibarr
    Activer et configurer le module OAuth

    Configuration → Modules → OAuth (activer si inactif) → engrenage. Choisir Microsoft dans la liste, donner un nom, valider.

    Saisir : Client ID, Secret ID, Tenant ID, Scope.

    CLIENT_ID = [depuis Entra] CLIENT_SECRET = [valeur du secret] TENANT_ID = [Directory ID] SCOPE = offline_access https://outlook.office365.com/SMTP.Send # L’URL exacte du scope est sensible à toute évolution Microsoft. # Vérifier la documentation Dolibarr en cas de changement.
  5. Dolibarr
    Générer le jeton

    Sur la fiche OAuth, deuxième onglet : Cliquez ici pour obtenir un token. Une fenêtre Microsoft s’ouvre — se connecter avec le compte qui enverra les e-mails, valider les permissions.

    Si une erreur s’affiche à ce stade, c’est presque toujours un scope manquant ou un consentement admin oublié à l’étape 3.

  6. Dolibarr
    Configurer l’envoi SMTP

    Accueil → Configuration → Emails → Modifier.

    Méthode = SMTP/SMTPS Hôte SMTP = smtp.office365.com Port = 587 Chiffrement = STARTTLS Authentification = OAuth2 Service OAuth = [le nom de l’entrée OAuth créée] Identifiant SMTP = [le compte qui a généré le token] Expéditeur From = le même compte (sinon refus 5.7.x)

    Test envoi en bas de la page. Si le test passe, c’est gagné.

11 / 15
Solution de transition

SMTP basique :
5 minutes, 5 champs.

À utiliser uniquement comme solution courte avant migration OAuth2. Sera désactivé par défaut fin 2026.

Côté Microsoft

1. Centre d’administration Microsoft 365 → Utilisateurs actifs → utilisateur concerné → onglet Courrier → Gérer les applications de messagerie → cocher SMTP authentifié.

2. Si MFA actif sur un compte M365 professionnel : un admin doit avoir activé les mots de passe d’application dans Microsoft Entra → Méthodes d’authentification (désactivé par défaut sur les tenants récents). L’utilisateur peut ensuite en générer un via Mon compte → Sécurité.

3. Vérifier que la stratégie de sécurité par défaut ou un Conditional Access n’écrase pas ce paramètre.

⚠ Comptes grand public (outlook.com, hotmail, live) : les app passwords ne fonctionnent plus pour SMTP/IMAP depuis septembre 2024. OAuth2 est obligatoire.

Côté Dolibarr

Hôte SMTP = smtp.office365.com Port = 587 Chiffrement = STARTTLS Identifiant = user@domaine.com Mot de passe = [mdp ou app password] Expéditeur = user@domaine.com # L’expéditeur DOIT être identique à l’identifiant. # Sinon : erreur 5.7.60 ou 5.7.708.

Test envoi. Si échec → consultez le tableau d’erreurs page suivante.

12 / 15
Décodeur d’erreurs

Les messages les plus fréquents,
traduits en clair.

Chaque erreur ci-dessous indique précisément où chercher. Aucune n’est imputable à Dolibarr seul.

5.7.139
Authentication unsuccessful — SMTP AUTH disabled for the tenant
Localisation : Microsoft 365 — paramètres tenant

Cause : SMTP AUTH n’est pas activé au niveau du tenant. Solution : Centre Exchange → Paramètres → Courrier → activer SMTP authentifié.

5.7.139
Authentication unsuccessful — SMTP AUTH disabled for the user
Localisation : Microsoft 365 — paramètres utilisateur

Cause : SMTP AUTH désactivé sur le compte spécifique. Solution : Utilisateur → Courrier → Gérer les applications de messagerie → cocher SMTP authentifié.

5.7.30
Basic authentication is not supported for Client Submission
Localisation : Microsoft — politique tenant

Cause : Basic Auth déjà désactivé sur ce tenant. Solution : migrer vers OAuth2. Pas de retour en arrière possible.

5.7.60
SMTP; Client does not have permissions to send as this sender
Localisation : Dolibarr — configuration emails

Cause : L’adresse From ne correspond pas au compte authentifié. Solution : mettre la même adresse en From et en identifiant SMTP, ou accorder « Send As » dans Exchange.

invalid_grant
AADSTS70008 — The refresh token has expired or been revoked
Localisation : Microsoft — token revoqué

Cause : Mot de passe du compte changé, admin a révoqué les tokens, ou refresh token de plus de 90 jours sans usage. Solution : Dolibarr → Module OAuth → re-générer le token.

invalid_scope
AADSTS65001 — The user or administrator has not consented
Localisation : Microsoft — App registration

Cause : Permissions API non accordées par l’admin, ou scope mal écrit dans Dolibarr. Solution : Entra → Autorisations API → Accorder un consentement administrateur. Vérifier que le scope dans Dolibarr est exactement offline_access https://outlook.office365.com/SMTP.Send.

invalid_client
AADSTS7000215 — Invalid client secret provided
Localisation : Microsoft — App registration

Cause : Secret client expiré ou mal copié (espaces, troncature). Solution : Entra → Certificats & secrets → générer un nouveau secret → mettre à jour Dolibarr.

PHPMAILER
Failed to authenticate on SMTP server using 2 possible authenticators
Localisation : Dolibarr — phase d’authentification, avant réponse Microsoft

Lecture du message : ce message vient de PHPMailer (la librairie d’envoi de Dolibarr), pas de Microsoft. PHPMailer a essayé deux mécanismes d’authentification (LOGIN puis PLAIN) et les deux ont été refusés. Aucun code 5.x.x = Microsoft n’a pas eu l’occasion de répondre clairement.

Causes les plus fréquentes, dans l’ordre : (1) mot de passe incorrect ou changé récemment côté Microsoft sans mise à jour Dolibarr ; (2) MFA activé sur le compte sans app password configuré ; (3) SMTP AUTH désactivé sur le compte spécifique ; (4) compte verrouillé après trop de tentatives ratées ; (5) module OAuth2 configuré mais token expiré ou révoqué.

Diagnostic : reproduire avec swaks (cf. slide cas pratique) pour faire dire à Microsoft pourquoi il refuse. Si swaks renvoie un code 5.7.x clair, c’est une politique côté tenant. Si swaks renvoie aussi une erreur générique, c’est un mot de passe ou un compte verrouillé.

CONNECTION
Connection timeout sur smtp.office365.com:587
Localisation : réseau / pare-feu serveur Dolibarr

Cause : Sortie SMTP bloquée par le pare-feu de l’hébergeur ou du client. Solution : ouvrir le port 587 sortant vers smtp.office365.com. Tester avec telnet smtp.office365.com 587 depuis le serveur.

13 / 15
Cas pratique

Lire une erreur réelle,
du début à la fin.

Reproduction d’un message d’échec authentique. Six étapes de diagnostic, dans l’ordre où elles éliminent le plus de causes possibles, et un test décisif qui tranche la responsabilité.

535 5.7.139
Le message tel qu’il apparaît dans Dolibarr
Localisation : log d’envoi Dolibarr 
Échec de l'envoi de l'email
(émetteur=Société Exemple <contact@exemple.fr>,
 destinataire=destinataire@partenaire.fr)

Error [120]: Ran into problems sending Mail.
Response: 535 5.7.139 Authentication unsuccessful, the request did not
meet the criteria to be authenticated successfully. Contact your
administrator. [XX0XXX0XX0000.XXXX000.PROD.OUTLOOK.COM
2026-04-30T09:54:31.972Z 0000XX00X0XXX0X0]

Error [130]: Invalid Authentication Credentials.

Lecture du message

Code clé : 5.7.139 — Microsoft refuse l’authentification SMTP. Ce code spécifique signale presque toujours une politique côté tenant ou utilisateur, pas un mauvais mot de passe.

Phrase à retenir : « the request did not meet the criteria to be authenticated successfully ». Microsoft ne dit pas « identifiants invalides » — il dit que la requête, telle qu’elle se présente, n’a pas le droit de s’authentifier ainsi.

Datacenter : le préfixe (ici XX0XXX) indique la région du serveur Microsoft qui a traité la requête — utile pour identifier rapidement si la zone géographique a déjà basculé dans une phase de dépréciation.

Identifiant de session : la chaîne hexadécimale en fin de message est à conserver. C’est ce que Microsoft demande si l’IT client doit ouvrir un ticket auprès de leur support.

Procédure de diagnostic — dans l’ordre

  1. Dolibarr
    Quelle méthode d’authentification est configurée ?

    Configuration → Emails. Si le champ Authentification indique « Login + mot de passe » et non « OAuth2 », le compte est encore en Basic Auth. Vu le timestamp et le datacenter, c’est la cause la plus probable. Migration OAuth2 nécessaire.

  2. Microsoft 365 — tenant
    SMTP AUTH activé au niveau de l’organisation ?

    Centre d’administration Exchange → Paramètres → Courrier → vérifier que « Désactiver SMTP AUTH pour l’organisation » est décoché. Sur les tenants créés récemment, ce paramètre est désactivé par défaut.

  3. Microsoft 365 — utilisateur
    SMTP AUTH activé sur le compte expéditeur ?

    Centre M365 admin → Utilisateurs actifs → ouvrir le compte (ici contact@exemple.fr) → onglet Courrier → Gérer les applications de messagerie → cocher SMTP authentifié. Piège classique : tenant autorisé mais compte spécifique bloqué.

  4. Microsoft 365 — utilisateur
    Le mot de passe a-t-il changé récemment ?

    Demander au client si le mot de passe du compte expéditeur a été réinitialisé, ou si MFA a été activé récemment. Toute modification côté Microsoft invalide immédiatement la configuration côté Dolibarr.

  5. Microsoft Entra
    Politique d’accès conditionnel ?

    Si une politique Conditional Access bloque les « clients legacy » ou impose MFA sur toutes les connexions, Basic Auth pour SMTP est rejeté même quand SMTP AUTH est techniquement coché. Microsoft Entra → Protection → Accès conditionnel → vérifier les règles actives.

  6. Test décisif
    Reproduire l’erreur depuis une autre machine

    Faire exécuter par l’IT client, ou directement depuis le serveur Dolibarr (ou n’importe quel poste Linux/macOS), un test SMTP isolé avec swaks. C’est l’outil de référence pour ce diagnostic — il affiche tout le dialogue SMTP, ligne par ligne.

    # Installation (une fois) : # Debian/Ubuntu : apt install swaks # RHEL/Fedora : dnf install swaks # Alpine : apk add swaks # Test SMTP isolé de Dolibarr : swaks –to test@externe.com \ –from contact@exemple.fr \ –server smtp.office365.com \ –port 587 \ –auth LOGIN \ –auth-user contact@exemple.fr \ –auth-password ‘MOT_DE_PASSE’ \ –tls

    Lecture du résultat : swaks affiche chaque ligne avec un préfixe <- (réponse Microsoft) ou -> (envoi du client). Le code 535 5.7.139 apparaîtra clairement après la ligne AUTH LOGIN si l’authentification est rejetée.

    Si la même erreur 5.7.139 apparaît avec swaks : la cause est définitivement côté Microsoft. La trace complète swaks est à joindre au ticket retourné au client — Microsoft ne peut plus dire « c’est votre application ». Si swaks passe : le problème est dans la configuration Dolibarr (cas rare mais possible — vérifier scope, encodage, ou conflit de version PHPMailer).

    Alternative légère sans installation : openssl s_client -connect smtp.office365.com:587 -starttls smtp permet un dialogue SMTP manuel, mais swaks reste plus lisible et explicite pour communiquer le résultat au client.

Conclusion sur ce cas type

Probabilité élevée : compte en Basic Auth sur un tenant qui vient de basculer dans la phase de rejet Microsoft entamée le 1er mars 2026. La résolution durable est la migration vers OAuth2 (slide 8). Une réactivation manuelle de SMTP AUTH peut faire passer temporairement, mais la fenêtre se referme rapidement.

14 / 15
Checklist & rôles

À cocher avant
d’ouvrir un ticket.

Checklist de mise en service

Préalables Microsoft (IT client) :

☐ Compte de service avec licence Exchange Online active
☐ Domaine d’envoi vérifié dans M365
☐ SPF, DKIM, DMARC configurés et validés
☐ App Registration créée dans Entra (si OAuth2)
☐ Secret client généré (durée notée au calendrier)
☐ Permissions API offline_access + SMTP.Send ajoutées
☐ Consentement administrateur accordé
☐ SMTP AUTH activé tenant + utilisateur (si basique)
☐ Port 587 sortant ouvert depuis le serveur Dolibarr

Configuration Dolibarr :

☐ Module OAuth activé et configuré (si OAuth2)
☐ Token généré avec succès
☐ Configuration emails saisie
☐ Identifiant SMTP = adresse From
☐ Test envoi réussi vers une adresse externe
☐ Test envoi vérifié dans Message Trace côté Microsoft

Répartition des rôles

Pour chaque tâche, qui agit, qui valide, qui est tenu informé. Cela permet d’éviter les zones grises où chacun pense que c’est l’autre qui s’en occupe.

Tâche
IT client
Intégrateur Dolibarr
Préalables M365
Réalise & valide
Consulté
App Registration Entra
Réalise & valide
Consulté
Configuration module OAuth Dolibarr
Informé
Réalise & valide
Génération du token initial
Réalise
Valide
Renouvellement secret client
Réalise & valide
Informé
Re-génération token après révocation
Réalise
Valide
Diagnostic erreur envoi
Consulté
Réalise & valide
Lecture Message Trace
Réalise
Consulté

Réalise = agit concrètement · Valide = a le dernier mot · Consulté = donne un avis avant action · Informé = mis au courant après coup

15 / 15
— Fin du document

Une responsabilité
partagée,
clairement répartie.

L’envoi d’e-mails repose sur une chaîne où chaque maillon est identifié. Avec ce guide, chaque intervenant — IT client, intégrateur, support métier — sait où regarder en cas d’incident, et le diagnostic devient une question de quelques minutes.

Document maintenu en regard des évolutions Microsoft.
Dernière revue : avril 2026 · Prochaine revue : selon annonces Microsoft (décembre 2026)