Dolibarr n'envoie pas les e-mails : configurer le SMTP

Une facture envoyée depuis Dolibarr qui n’arrive jamais, ou un bandeau rouge avec un message en anglais incompréhensible : l’envoi d’e-mails est l’une des pannes les plus fréquentes sur le forum. La bonne nouvelle, c’est que Dolibarr affiche presque toujours la réponse exacte du serveur. Il suffit de savoir la lire.

Tout ce qui suit a été testé le 16 octobre 2026 sur une installation neuve de Dolibarr 24.0.2, avec trois serveurs d’envoi de test : un sur le port 587 qui exige STARTTLS, un sur le port 465 en SSL direct, et un dont le certificat est auto-signé. Chaque message d’erreur cité a été obtenu en provoquant l’erreur.

Où se règle l’envoi

Accueil › Configuration › E-mails, onglet E-mails sortants, bouton Modifier. Le premier choix est la méthode d’envoi :

• PHP mail function (le réglage par défaut) : Dolibarr confie l’e-mail au programme d’envoi du serveur web. Dans l’image Docker officielle, il n’y en a pas : l’envoi échoue avec Failed to send mail with php mail. Sur un hébergement mutualisé, il peut fonctionner, mais les e-mails partent alors du serveur web et non de votre messagerie : ils risquent davantage de finir en indésirables, comme le rappellent régulièrement les habitués du forum.
• SMTP/SMTPS socket library : Dolibarr se connecte lui-même au serveur d’envoi de votre messagerie (celui de votre hébergeur, de Gmail, de Microsoft 365, de Brevo…), avec un identifiant et un mot de passe. C’est le réglage à choisir.
• Swift Mailer socket library : même principe, autre bibliothèque. Les deux ont fonctionné dans nos tests ; leurs messages d’erreur diffèrent (voir le tableau plus bas).

Les bons réglages

La règle à retenir : 587 = STARTTLS, 465 = TLS (SSL), jamais les deux à la fois. Les deux mélanges inverses produisent des erreurs différentes, détaillées dans le tableau.

Deux pièges d’affichage en français : le libellé dit « TTS » au lieu de « TLS » pour STARTTLS, et sur la page de consultation (hors modification), la ligne du port est intitulée par erreur « Nom d’hôte ou adresse IP du serveur SMTP/SMTPS (Par défaut dans php.ini: 25) ». C’est bien le port.

Le champ E-mail de l’expéditeur pour les e-mails automatiques, plus bas sur la même page, doit être une adresse de la boîte utilisée pour s’identifier : beaucoup de serveurs refusent d’envoyer au nom d’une autre adresse (Microsoft 365 renvoie alors l’erreur 5.7.60 … Client doesn't have permissions to send as this sender).

Tester : le bon bouton

Après avoir enregistré, la page propose trois boutons de test.

• Tester envoi : envoie vraiment un e-mail. C’est le seul test qui prouve que tout marche, mot de passe compris. Le message vert « accepté pour expédition » veut dire que le serveur d’envoi l’a accepté ; vérifiez quand même qu’il arrive (et pas dans les indésirables).
• Tester envoi HTML : pareil, avec un message mis en forme.
• Tester disponibilité serveur : vérifie seulement que le port répond. D’après le code, il ne teste pas le mot de passe. Il refuse aussi, volontairement, les adresses privées ou locales : si votre serveur d’envoi est sur votre réseau (localhost, 192.168.…, un conteneur voisin), il répondra toujours « Serveur non disponible… Error bad hostname IP (private or reserved range) » même quand l’envoi fonctionne. Il ne teste que les ports 25, 465, 587 et 2525.

Ce que veut dire chaque message d’erreur

Messages relevés avec la bibliothèque SMTP/SMTPS socket library. Ils commencent tous par « Échec de l’envoi de l’email (émetteur=…, destinataire=…) ».

Avec Swift Mailer, les mêmes erreurs s’écrivent autrement : Failed to authenticate on SMTP server … 535 (mot de passe), SSL operation failed … wrong version number (TLS sur le 587), Connection to tcp://…:465 Timed Out après 30 secondes (STARTTLS sur le 465), Unable to connect with TLS encryption (certificat), getaddrinfo … failed: Name or service not known (hôte), Connection refused (port).

Deux réponses ne viennent pas d’un mauvais réglage mais du fournisseur : un 221 … please refrain from sending too many mails (cas réel d’OVH sur le forum) signale un quota d’envoi dépassé, et un 550 5.7.30 Basic authentication is not supported signifie que Microsoft refuse l’identification par mot de passe (voir plus bas).

Le mot de passe ne marche plus après une migration

Cas typique : vous déplacez Dolibarr sur un nouveau serveur en réinstallant puis en reprenant la base, et l’envoi échoue avec l’erreur 535, alors que le mot de passe est juste et que la page de configuration affiche bien des étoiles.

Explication : Dolibarr enregistre le mot de passe SMTP chiffré dans la base (il commence par dolcrypt:), avec une clé tirée de la ligne $dolibarr_main_instance_unique_id de conf.php. Une nouvelle installation crée une nouvelle clé. Dolibarr n’arrive plus à déchiffrer le mot de passe et envoie la chaîne chiffrée telle quelle au serveur, qui la refuse.

Nous l’avons reproduit en changeant seulement cette clé dans conf.php : erreur 535 immédiate, étoiles toujours affichées. Deux solutions, testées toutes les deux :

• ressaisir le mot de passe dans Configuration › E-mails, puis enregistrer : il est chiffré avec la nouvelle clé et l’envoi repart ;
• ou, avant de migrer, reprendre l’ancien conf.php (ou au moins sa ligne $dolibarr_main_instance_unique_id). C’est la seule façon de garder aussi les autres données chiffrées avec cette clé (voir le guide Sauvegarder et restaurer Dolibarr).

Les mots de passe contenant des accents posaient un problème en 23.0 (fil 51640 du forum) : il est corrigé en 24.0.2. Nous avons vérifié le code et envoyé avec un mot de passe contenant « àéü ».

« Envoyé », mais jamais reçu

Si Dolibarr affiche le message vert et que rien n’arrive, regardez d’abord ces réglages de la même page :

• Envoyer tous les emails à (au lieu des vrais destinataires, à des fins de test) : s’il est rempli, tous les e-mails partent à cette adresse. Le piège : le message de confirmation affiche toujours le vrai destinataire. Dans notre test, Dolibarr a écrit « vers client@destinataire.test » alors que l’e-mail est arrivé à l’adresse de test. Un petit triangle orange signale ce réglage sur la page de configuration.
• Désactiver globalement tout envoi d’emails : quand il est actif, les boutons de test disparaissent de la page et plus rien ne part.

Ensuite seulement, la délivrabilité : sans enregistrements SPF, DKIM et DMARC corrects pour votre domaine, Gmail et Outlook classent volontiers les e-mails en indésirables, surtout avec la méthode PHP mail. Le lien « Obtenir un résumé de la configuration SPF et DMARC de tous les domaines… », en bas de la page, affiche ce qui est publié pour vos domaines. Ce point dépend de votre domaine et de votre messagerie : il n’est pas couvert par nos tests.

Gmail et Microsoft 365

Réglages tirés de la documentation officielle de chaque fournisseur, non testés avec un vrai compte.

• Gmail / Google Workspace : hôte smtp.gmail.com, port 587 avec STARTTLS (ou 465 avec TLS), identifiant = adresse complète. Avec la validation en deux étapes, il faut un mot de passe d’application : le mot de passe habituel est refusé. Pour un compte Google Workspace, Google indique une limite de 2 000 messages par jour pour ce mode d’envoi.
• Microsoft 365 : hôte smtp.office365.com, port 587 avec STARTTLS ; Microsoft précise que le port 465 n’est pas pris en charge. L’envoi SMTP authentifié (« SMTP AUTH ») est désactivé par défaut sur les organisations créées depuis 2020 et doit être activé pour la boîte. Surtout, Microsoft a annoncé la désactivation par défaut de l’identification par mot de passe fin décembre 2026 pour les organisations existantes (un administrateur pourra encore la réactiver, la date de suppression définitive n’est pas fixée). La solution durable est la méthode Utiliser un token OAUTH, qui demande d’activer le module OAuth de Dolibarr ; nous ne l’avons pas testée.

Et les images dans la signature ?

En 22.0.3, une signature contenant une image collée (encodée dans le texte) produisait des lignes trop longues, refusées par certains serveurs (« message has lines too long for transport », fil 50371 du forum). En 24.0.2, nous n’avons pas reproduit le problème : les deux bibliothèques transforment l’image en pièce jointe intégrée, et la plus longue ligne de l’e-mail faisait 109 caractères (la limite est de 998). Une image hébergée sur votre site, appelée par son adresse, reste la solution la plus sûre sur les versions plus anciennes.

Si ça ne part toujours pas

Si le message d’erreur ne figure pas dans le tableau, ou si l’envoi fonctionne depuis votre messagerie mais pas depuis Dolibarr, le diagnostic à 90 € consiste justement à regarder votre instance avec vous pendant une heure, puis à vous remettre par écrit la cause et ce que coûterait la correction.

À lire aussi

• Sécuriser une instance Dolibarr hébergée
• Installer Dolibarr sur Ubuntu ou Debian
• Installer Dolibarr avec Docker Compose