Si vos e-mails “ne partent pas”, commencez par le symptôme : boîte d’envoi bloquée, erreur SMTP, ou message affiché “envoyé” sans jamais arriver.
Ensuite, passez à la configuration SMTP (serveur, port, chiffrement, authentification), puis isolez le côté client (Outlook/PST/OST, règles, cache).
Si l’envoi semble bon, il reste la remise : SPF/DKIM/DMARC et filtres anti-spam.
table class=”bf-info-table”>

Vous cherchez pourquoi mes mails ne partent pas et vous tournez en rond ? Le point de départ n’est pas “réparer Outlook” ou “changer un mot de passe” au hasard. Regardez d’abord ce que fait l’e-mail : reste-t-il bloqué, affiche-t-il une erreur SMTP, ou apparaît-il comme envoyé alors que le destinataire ne reçoit rien. Ensuite seulement, vous appliquez le bon plan d’action.
Ce guide vise une mise en œuvre rapide : vous isolez la cause la plus probable en 2 à 6 semaines, avec des tests courts après chaque changement. Pas de promesse de “classement” ici. On suit la logique d’envoi et de remise, côté client puis côté serveur (et ça, ça change tout).
Identifier le symptôme exact : boîte d’envoi bloquée, erreur SMTP, ou message “envoyé” mais non reçu
Avant de dépanner, distinguez le comportement : e-mail bloqué dans la boîte d’envoi, message d’erreur (SMTP/port/authentification), ou “envoyé” côté client mais non reçu côté destinataire. Chaque cas renvoie à une cause différente : fichier de données corrompu, problème réseau/serveur, ou rejet côté destinataire (SPF/DKIM).
Suivez le flux “préparation → envoi → acceptation serveur → remise”. Si l’e-mail n’atteint jamais l’étape d’acceptation, il reste souvent dans la boîte d’envoi ou déclenche une erreur immédiate. Si l’acceptation a lieu mais que la remise échoue, vous verrez plutôt un “envoyé” côté client et un silence côté destinataire.
Test rapide (2 minutes) : copiez/photographiez le message d’erreur exact quand il apparaît, puis notez son code (s’il existe). Ensuite, regardez le statut : “envoi en cours”, “bloqué”, “envoyé”, ou “non remis (bounce)”. (Ce détail oriente vraiment la suite.)
Le classement par étape : ce que vous devez observer
- Préparation côté client : le message est prêt à partir, mais le blocage arrive juste après “envoyer” (souvent règles/composants, ou fichier PST/OST).
- Envoi vers le serveur : erreurs typiques “connexion impossible”, “timeout”, “port”, “SSL/STARTTLS”.
- Acceptation serveur SMTP : si le serveur refuse l’authentification, vous verrez souvent des erreurs liées à “AUTH” ou “mot de passe refusé”.
- Remise au destinataire : si l’envoi semble validé mais que le destinataire ne reçoit rien, le filtrage (SPF/DKIM/DMARC, réputation) devient la piste principale.
Micro-résumé : votre première décision dépend du statut exact du message, pas de l’application que vous utilisez.
- Notez le statut : bloqué en boîte d’envoi, erreur SMTP, ou “envoyé”.
- Copiez le texte d’erreur + code (si présent).
- Testez un e-mail court (sans pièces jointes, 1 phrase).
- Essayez un destinataire externe (Gmail vers Outlook, ou l’inverse).
- Regardez si un retour de non-remise (bounce) apparaît.
- Vérifiez si le problème a commencé après un changement (mot de passe, mise à jour, réseau).
- Chronométrez : combien de temps le message reste “bloqué” (minutes vs heures).
Erreurs qui coûtent cher
- Modifier 3 paramètres SMTP d’un coup (vous perdez la cause).
- Réinitialiser le profil Outlook sans vérifier la taille de boîte (vous rallongez le temps de retour).
- Supposer que “envoyé” = “remis” (les rejets anti-spam arrivent après acceptation).
Vérifier la configuration d’envoi : SMTP, ports, chiffrement (STARTTLS/SSL) et identifiants
Une configuration SMTP incomplète ou obsolète revient souvent : mauvais port, chiffrement non compatible (SSL vs STARTTLS), identifiants refusés, ou serveur sortant différent de celui attendu. Contrôlez les paramètres “Serveur SMTP sortant”, “Port”, “Exiger une connexion chiffrée” et “Authentification”, puis testez l’envoi avec un message court.
Avant de bricoler, comparez les paramètres du client (Outlook/Gmail/Orange ou autre) avec ceux fournis par votre fournisseur. Les fournisseurs utilisent souvent des ports dédiés pour SMTP sortant : 587 pour STARTTLS et 465 pour SSL, mais l’opérateur peut varier selon votre offre. Si le couple port + chiffrement ne correspond pas, vous verrez des erreurs réseau ou d’authentification.
Après un changement de mot de passe ou un durcissement du compte (sécurité, 2FA), certains clients doivent être reconfigurés : suppression/reconnexion du compte, ou mise à jour des identifiants. L’erreur “SMTP AUTH” ou “mot de passe refusé” signale généralement un souci d’authentification, pas un simple retard.
Ce que vous devez vérifier dans l’interface (checklist actionnable)
- Serveur SMTP sortant : même domaine/serveur que celui recommandé par votre fournisseur.
- Port : testez la valeur officielle (souvent 587 ou 465).
- Chiffrement : “Exiger une connexion chiffrée” doit correspondre au mode attendu (SSL vs STARTTLS).
- Authentification : activez “utiliser l’authentification” si c’est requis ; vérifiez le type (normal/secure).
- Identifiants : adresse complète et mot de passe/jeton (selon le fournisseur).
Micro-résumé : un SMTP mal aligné (port + chiffrement + AUTH) suffit à bloquer l’envoi avant même la remise.
Quand tester un e-mail “court” change tout
Si le message court part, mais que vos e-mails “réels” échouent, le problème peut venir du contenu (pièces jointes, liens, taille, encodage). En revanche, si même un envoi simple bloque, vous revenez à la configuration SMTP ou au côté client.
Pour vous appuyer sur des repères techniques, consultez la documentation officielle sur les paramètres liés au courrier : références techniques IANA sur les paramètres mail. Et pour les cas Outlook, gardez sous la main le centre d’aide : assistance Microsoft Outlook (envoi, PST/OST, dépannage).
Erreurs qui coûtent cher
- Activer SSL sur un port 587 (ou l’inverse) sans test.
- Utiliser une adresse “affichage” au lieu de l’identifiant de connexion SMTP.
- Changer le serveur sortant sans vérifier que le compte utilise bien le bon mode d’authentification.
Diagnostiquer le blocage côté client : Outlook (fichier PST/OST), cache, taille de boîte et règles
Quand les e-mails restent coincés dans la boîte d’envoi, le problème est souvent côté client : fichier PST/OST saturé ou corrompu, cache de l’application, ou règles qui déplacent/retiennent les messages. Dans Outlook, vérifiez la taille de la boîte aux lettres, désactivez temporairement les compléments/règles, puis testez après redémarrage pour isoler la cause.
Le symptôme “boîte d’envoi qui ne se vide pas” pendant plusieurs minutes/heures est un signal fort : soit le client ne termine pas la tâche d’envoi, soit il échoue à une étape de préparation/acceptation. Commencez par ce qui se voit : capacité de stockage et état des fichiers de données.
Puis isolez les causes “silencieuses”. Les règles automatiques peuvent retenir un message, et certains compléments (anti-spam, archivage, CRM) perturbent le processus. Objectif : créer un environnement de test propre, sans tout casser d’un coup.
Outlook : plan d’action en 4 étapes (réellement faisable)
- Contrôlez la taille : si la boîte est pleine, l’envoi et/ou la réception peuvent être bloqués.
- Test sans règles : désactivez temporairement les règles qui déplacent, archivent ou marquent des messages.
- Test sans compléments : démarrez Outlook en mode minimal (ou désactivez les compléments un par un).
- Réparation/actualisation : si le comportement persiste, envisagez une réparation du fichier de données (PST/OST) et/ou la mise à jour du profil.
Micro-résumé : cherchez un conflit local (règles, cache, PST/OST) avant d’accuser le serveur. (Sinon, vous tournez en rond.)
Quand lancer une réparation devient pertinent
Si le problème a commencé après une coupure réseau, une mise à jour incomplète, ou un incident autour du fichier PST/OST, une réparation peut aider. Le raisonnement est simple : un fichier corrompu peut empêcher la finalisation des tâches d’envoi.
Pour les étapes officielles (réparation, vérification de l’état, gestion des fichiers de données), utilisez la base Microsoft : centre d’aide Outlook.
Erreurs qui coûtent cher
- Ignorer la taille de boîte : vous réparez un fichier alors que le stockage bloque.
- Répéter des tentatives d’envoi avec plusieurs messages : vous compliquez la trace et multipliez les échecs.
- Ne pas tester après redémarrage : certains changements ne se reflètent qu’après un cycle complet.
Gmail et comptes web : vérifier l’état de l’envoi, la connectivité, et les restrictions du compte
Sur Gmail, un e-mail peut rester en attente si la session n’est pas stable, si des paramètres de sécurité bloquent l’envoi, ou si l’expéditeur subit des restrictions (activité inhabituelle, quotas, configuration d’accès). Vérifiez la connexion, testez en mode navigateur, contrôlez les paramètres d’envoi (SMTP/IMAP si vous utilisez un client), et examinez les notifications de sécurité du compte.
Le réflexe utile : distinguer interface web et client. Si l’envoi échoue dans l’interface web, vous êtes plus proche d’un problème de compte/sécurité ou de connectivité. Si l’interface web fonctionne mais pas le client (via IMAP/SMTP), le réglage côté application redevient prioritaire.
Les comptes peuvent appliquer des restrictions temporaires après des changements de connexion ou des tentatives répétées. C’est souvent discret dans la “boîte d’envoi”, mais visible via notifications sécurité et journaux de session.
Tests à faire cette semaine (sans perdre de temps)
- Test navigateur : envoyez un e-mail court depuis un autre navigateur (ou une fenêtre privée) pour écarter cache/extension.
- Test d’un autre réseau : basculez sur 4G ou changez de Wi‑Fi pour repérer un filtrage local.
- Client externe : si vous utilisez un client (Apple Mail, Outlook, Thunderbird), vérifiez les paramètres SMTP/IMAP et le chiffrement.
- Quotas : si vous envoyez beaucoup, vérifiez si des limites d’envoi/activité inhabituelle s’appliquent.
Micro-résumé : sur Gmail, le test via navigateur sert de “bascule” pour séparer problème de client et restriction/sécurité du compte.
Pour le dépannage côté Gmail (envoi, sécurité, traces), consultez : assistance Gmail.
Erreurs qui coûtent cher
- Modifier le client alors que l’envoi échoue aussi dans le navigateur.
- Ignorer les alertes sécurité : elles expliquent souvent pourquoi l’expéditeur est restreint.
- Multiplier les essais avec des messages identiques : vous augmentez le risque de blocage temporaire.
Orange et opérateurs : vérifier le serveur sortant, l’authentification et les erreurs de réseau
Avec un fournisseur comme Orange, l’envoi dépend du bon serveur sortant et d’une authentification valide. Si vos messages échouent, vérifiez le serveur SMTP sortant, le port, le chiffrement, et l’option “authentification requise”. Côté réseau, testez en changeant de connexion (Wi‑Fi/4G) pour éliminer un blocage par pare-feu ou filtrage.
Les paramètres d’envoi peuvent différer de ceux utilisés pour l’accès webmail. C’est un piège classique : sur le web, tout semble fonctionner, donc on suppose que le SMTP du client est bon. Or, le SMTP sortant du client peut être mal configuré ou filtré par votre réseau actuel.
Les erreurs du type “connexion impossible” ou “timeout” orientent souvent vers un problème réseau plutôt que vers le contenu. Dans ce cas, le test “changer de réseau” est votre meilleur accélérateur. (Et oui, c’est parfois aussi simple que ça.)
Plan de test opérateur (orienté preuve)
- Reprendre les paramètres officiels du serveur SMTP sortant dans la documentation Orange.
- Vérifier l’authentification : “authentification requise” doit être cohérente avec l’offre.
- Tester deux réseaux : Wi‑Fi puis 4G (ou l’inverse) pour confirmer un filtrage local.
- Test court : 1 e-mail, sans pièce jointe, vers une adresse externe.
Micro-résumé : quand le réseau bloque, le bon SMTP ne suffit pas. Quand le SMTP est faux, changer de réseau ne résout pas.
Pour les paramètres et la configuration messagerie, utilisez la page d’assistance : assistance Orange.
Erreurs qui coûtent cher
- Utiliser un serveur sortant “par défaut” (tiers) sans vérifier qu’il est autorisé pour votre compte.
- Tester uniquement sur le même Wi‑Fi : vous risquez de confondre filtrage local et configuration SMTP.
- Oublier de vérifier le chiffrement : STARTTLS/SSL mal aligné = échec d’authentification ou connexion refusée.
Quand l’envoi “réussit” mais que le destinataire ne reçoit pas : réputation, SPF/DKIM/DMARC et anti-spam
Si l’e-mail apparaît comme envoyé mais n’arrive pas, le blocage est souvent côté destinataire : filtrage anti-spam, rejet par politiques d’authentification (SPF, DKIM, DMARC) ou réputation d’expéditeur. Vérifiez vos en-têtes (retour de non-remise si disponible), assurez l’alignement SPF/DKIM/DMARC pour votre domaine, et évitez les pratiques qui déclenchent les filtres (pièces jointes suspectes, liens multiples).
Dans ce scénario, le serveur a probablement accepté le message, puis la remise a été stoppée ou mise en quarantaine. Les rejets peuvent être immédiats (bounce) ou différés (délai de traitement). C’est pour ça qu’un “envoyé” côté client ne suffit pas : cherchez des preuves côté destinataire ou via retours de non-remise.
Le test le plus utile : envoyez vers une adresse externe (un autre fournisseur) après chaque changement. Si la remise marche vers un fournisseur mais pas l’autre, vous avez un indice fort sur le filtrage et la réputation. Et si vous n’avez rien côté destinataire, vous faites quoi ? Vous demandez des en-têtes.
SPF/DKIM/DMARC : quoi regarder concrètement
- SPF : votre domaine autorise-t-il l’IP/serveur d’envoi ?
- DKIM : la signature est-elle présente et valide ?
- DMARC : la politique (quarantaine/refus) s’applique-t-elle correctement ?
Micro-résumé : quand l’envoi semble bon, l’anti-spam du destinataire décide souvent de la suite.
Interpréter les retours de non-distribution
Quand un bounce apparaît, lisez-le comme un diagnostic : il indique si le rejet est lié à l’adresse, au serveur, ou à l’authentification. S’il n’y a aucun bounce, le message peut être filtré sans retour. Dans ce cas, demandez au destinataire de vérifier “Spam / Promotions / Quarantaine” et de fournir des en-têtes si possible.
Pour les repères techniques sur les paramètres liés au courrier, gardez IANA sous la main : références mail parameters IANA.
Erreurs qui coûtent cher
- Accuser l’application alors que l’authentification de domaine est incohérente.
- Changer des réglages SMTP sans vérifier SPF/DKIM/DMARC : vous déplacez le problème sans le résoudre.
- Envoyer des messages “lourds” (pièces jointes, liens) pendant le test : vous mélangez cause et effet.
FAQ : pourquoi mes mails ne partent pas
Pourquoi mes e-mails restent-ils bloqués dans la boîte d’envoi ?
Souvent, le blocage vient du client : fichier PST/OST saturé ou corrompu, règles qui retiennent les messages, ou compléments qui perturbent l’envoi. Plus rarement, l’acceptation serveur échoue (SMTP auth, port/chiffrement incompatibles). Le test “message court” et le relevé de l’erreur (ou du statut) permettent d’orienter rapidement.
Comment savoir si le problème vient du SMTP ou de mon application (Outlook/Gmail) ?
Faites une bascule : envoyez le même e-mail court via l’interface web (si possible) et comparez avec le client. Si l’envoi échoue partout, la configuration SMTP/compte est la piste la plus probable. Si l’envoi web fonctionne mais pas le client, regardez port, chiffrement (SSL vs STARTTLS), authentification et paramètres du serveur sortant dans l’application.
Quel port SMTP et quel chiffrement utiliser pour que mes mails partent ?
Les repères courants sont 587 avec STARTTLS et 465 avec SSL, mais ils dépendent de votre fournisseur. L’important est l’alignement : port + chiffrement + option “connexion chiffrée” doivent correspondre aux paramètres officiels. Si vous voyez des erreurs liées à “AUTH” ou “connexion refusée”, c’est un indice fort que le couple n’est pas compatible.
Pourquoi mes mails sont “envoyés” mais ne sont jamais reçus par le destinataire ?
Le message a probablement été accepté, puis bloqué à la remise : anti-spam, réputation, ou rejet SPF/DKIM/DMARC. Vérifiez s’il existe un retour de non-remise (bounce) et demandez au destinataire de contrôler “Spam/Quarantaine”. Un test vers une adresse externe aide à confirmer si le problème est spécifique à un fournisseur.
Quand dois-je vérifier la taille de ma boîte aux lettres pour résoudre un échec d’envoi ?
Dès que vous observez un e-mail bloqué dans la boîte d’envoi depuis plusieurs minutes/heures. Une boîte pleine peut empêcher la finalisation des tâches d’envoi et/ou déclencher des erreurs silencieuses. Sur Outlook, vérifiez aussi l’état des fichiers PST/OST, surtout après une coupure réseau ou une mise à jour.
Est-ce que je peux résoudre un problème d’envoi en changeant de connexion Internet (Wi‑Fi/4G) ?
Oui, si le symptôme ressemble à un problème réseau : “timeout”, “connexion impossible”, échec au moment de joindre le serveur SMTP. En changeant de réseau (Wi‑Fi ↔ 4G), vous testez immédiatement si un pare-feu, un proxy ou un filtrage local bloque la connexion. Si ça marche sur 4G, le SMTP peut être correct et le réseau est la cause.
L’essentiel à retenir
- Commencez par classer le symptôme : blocage dans la boîte d’envoi, erreur SMTP, ou non-réception malgré “envoyé”.
- Vérifiez d’abord la configuration SMTP : serveur sortant, port, chiffrement et authentification.
- Sur Outlook, contrôlez la capacité de la boîte et testez sans règles/composants pour isoler un conflit.
- Sur Gmail, testez via navigateur pour distinguer problème de client vs restriction/sécurité du compte.
- Avec Orange, reprenez les paramètres officiels du SMTP et testez en changeant de réseau pour écarter un filtrage local.
- Si l’envoi semble réussir mais que la remise échoue, examinez SPF/DKIM/DMARC et les signaux anti-spam du destinataire.
- Faites un test court vers une adresse externe après chaque changement pour confirmer rapidement la cause la plus probable.
Si vous revenez à la question “pourquoi mes mails ne partent pas” en suivant ces étapes, vous réduisez le temps perdu. Vous identifiez la cause la plus probable, vous validez avec un test court, puis vous passez à l’étape suivante. Sur le long terme, ce sont les traces (statut, code, bounce, en-têtes) qui tranchent.
