Copiez le texte exact de l’échec (code SMTP, “authentification échouée”, “TLS requis”), puis testez la chaîne : client mail (Outlook/Thunderbird), DNS/SMTP, authentification (identifiant + mot de passe ou OAuth) et blocages (pare-feu, antivirus, liste noire). La plupart des pannes se règlent en ajustant SMTP/port/SSL ou en débloquant l’accès sortant.
Copiez le message exact : code SMTP, “authentification échouée”, “TLS requis”.
Vérifiez hôte SMTP, port (465/587) et chiffrement (SSL/TLS vs STARTTLS) selon le fournisseur.
Testez sur un autre réseau pour isoler pare-feu/antivirus/proxy.
Comparez webmail vs client, puis contrôlez quota, file d’envoi et réputation.
| Étape prioritaire | Relever le code SMTP exact dans les détails |
| Ports à vérifier | 465 (SSL/TLS implicite) et 587 (STARTTLS) |
| Signal fréquent 2024-2026 | “authentification échouée” et “TLS requis” après durcissement |
| Isolation rapide | Tester webmail vs client, puis changer de réseau |
| Derniers suspects | Quota, file d’envoi, blacklist/reputation |
Lire le message d’erreur : codes SMTP, “échec de livraison” et journaux
Copiez le texte exact de l’échec (code SMTP, “impossible d’envoyer”, “connexion refusée”, “authentification échouée”). Ensuite, ouvrez les journaux du client mail (ou le journal de l’application) : vous cherchez l’étape qui casse, pas juste le libellé affiché.
Les clients résument parfois tout en “impossible d’envoyer”. Les détails, eux, donnent la clé : un code 4xx ou 5xx, un motif “TLS requis”, ou un refus d’authentification. Entre 2024 et 2026, “authentification échouée” et “TLS requis” reviennent souvent après des changements côté fournisseurs.
Regardez aussi la chronologie : quel réglage a changé juste avant (mot de passe, migration de boîte, mise à jour du client, changement Wi‑Fi) ? Après chaque modification, comparez l’erreur avant/après. Le code dans les détails compte (même si le message paraît identique).
- Échec de connexion : “connexion refusée”, “timeout”, serveur injoignable.
- Échec TLS/SSL : “TLS requis”, “handshake échoué”, “certificat non valide”.
- Échec d’authentification : “authentification échouée”, identifiant refusé, OAuth refusé.
- Refus politique : rejet destinataire, erreur de réputation, blocage d’expéditeur.
Vérifier l’adresse et la configuration du serveur SMTP (ports, SSL/TLS, nom d’hôte)
Un hôte SMTP erroné, un port incorrect ou un chiffrement incompatible suffit à bloquer l’envoi. Vérifiez l’hôte SMTP, le port (souvent 465 ou 587) et le mode de chiffrement (SSL/TLS implicite ou STARTTLS). Contrôlez aussi l’identifiant (adresse complète) et la méthode d’authentification attendue par le fournisseur.
Commencez par les paramètres officiels du fournisseur (pas un “profil par défaut” trouvé au hasard). Ports courants : 465 pour SSL/TLS implicite et 587 pour STARTTLS. Si votre configuration est “sans chiffrement” alors que le fournisseur impose TLS, l’envoi échoue immédiatement.
Après une migration ou un durcissement sécurité, les paramètres SMTP changent parfois sans prévenir. Vérifiez donc : nom d’hôte SMTP, port, chiffrement, identifiant exact (souvent l’adresse complète). Si le fournisseur impose OAuth, un mot de passe classique peut être rejeté.
Pour les bases, voyez aussi la RFC 5321 (spécification SMTP) et la table IANA (ports usuels).
Repères rapides à contrôler
- Hôte SMTP : même domaine que celui indiqué par le fournisseur.
- Port : 465 (SSL/TLS implicite) ou 587 (STARTTLS).
- Chiffrement : SSL/TLS vs STARTTLS (ne pas confondre).
- Identifiant : adresse complète, sans alias manquant.
- Authentification : méthode attendue (mot de passe ou OAuth).
Diagnostiquer le blocage réseau : pare-feu, antivirus, proxy, Wi‑Fi et sortie SMTP
Si le serveur SMTP n’est pas joignable, l’envoi échoue même avec une configuration correcte. Vérifiez si un pare-feu, un antivirus, un proxy d’entreprise ou un contrôle parental bloque le trafic sortant. Testez en changeant de réseau (4G/5G ou autre Wi‑Fi), puis désactivez temporairement les protections pour isoler la cause. Si ça passe ailleurs, le problème vient du réseau (pas de la messagerie).
Un diagnostic propre commence par la connectivité : changez de réseau, puis relancez l’envoi du même message. Si le code passe de “timeout” à un autre stade (TLS puis auth), vous tenez une piste solide. (Et oui, c’est souvent plus rapide que de “tout retoucher”.)
En entreprise, les politiques réseau peuvent empêcher l’accès aux ports SMTP sortants. Les VPN/proxy peuvent aussi modifier la résolution DNS et provoquer des erreurs de connexion. Pour comparer, testez depuis un autre appareil sur le même réseau, ou depuis votre téléphone en partage de connexion.
- Pare-feu/antivirus : règles de filtrage du trafic sortant.
- Proxy : paramètres HTTP/HTTPS qui perturbent la résolution.
- Wi‑Fi : filtrage du routeur ou DNS interne.
- Sortie SMTP : blocage des ports 465/587.
Résoudre les problèmes d’authentification : mot de passe, OAuth et “compte désactivé”
Les erreurs d’authentification viennent d’un identifiant invalide, d’un mot de passe expiré, d’une méthode non compatible (mot de passe vs OAuth) ou d’un compte temporairement restreint. Vérifiez l’état du compte chez le fournisseur, réactivez l’accès à l’application si besoin, puis mettez à jour l’authentification dans le client mail.
Entre 2024 et 2026, l’adoption d’OAuth et la limitation des “mots de passe d’application” augmentent les erreurs. Après un changement de mot de passe, l’envoi échoue souvent tant que le client n’a pas été mis à jour : il garde parfois un ancien secret (ou une méthode différente).
Contrôlez la cohérence : si le fournisseur exige OAuth, un simple mot de passe peut être rejeté. Certains fournisseurs restreignent aussi l’accès des clients non conformes pendant une période (sécurité renforcée, détection d’activité inhabituelle). Dans ce cas, vérifiez le statut du compte et les sessions/applications autorisées.
Procédure rapide (sans réinstaller)
- Connectez-vous au webmail et vérifiez l’état du compte (sécurité, accès applications).
- Mettez à jour le client : méthode (OAuth ou mot de passe), identifiant, secret.
- Supprimez puis recréez le compte dans le client si les paramètres restent “figés”.
- Refaites un test avec un message court (sans pièces jointes).
Pour les réglages officiels : le centre d’aide Microsoft et le centre d’aide Google.
Contournement et tests rapides : envoyer via un autre client, “mode brouillon”, test SMTP
Pour isoler la cause, faites un test minimal : envoyez le même message depuis le webmail (interface du fournisseur) et depuis un autre client (Thunderbird/Outlook) ou un autre appareil. Si le webmail envoie, le problème est local (profil SMTP, port, chiffrement, auth). Si le webmail échoue aussi, c’est serveur/compte ou blocage réseau côté fournisseur.
Utilisez un petit message sans pièces jointes. Les pièces jointes déclenchent parfois des filtres anti‑spam ou des limites de taille. Résultat : vous perdez moins de temps à chercher une cause SMTP qui n’en est pas une.
Si votre client n’envoie pas mais que “brouillon” fonctionne, sauvegardez en brouillon puis réessayez après chaque modification (port/chiffrement/auth). Vous gardez un test reproductible. Quel est le piège ? Changer deux paramètres à la fois.
Plan de test en 5 minutes
- Envoyer depuis le webmail vers une adresse test.
- Envoyer depuis le client actuel (même message).
- Changer de réseau (Wi‑Fi → 4G/5G) et retenter.
- Changer de client (Thunderbird/Outlook) ou d’appareil.
- Relire le code SMTP et comparer avec la première tentative.
Cas fréquents : boîte d’envoi bloquée, quota, expéditeur en liste noire et réputation
Quand l’envoi échoue, la cause peut être une boîte d’envoi saturée (quota), un expéditeur blacklisté récemment, ou une réputation dégradée. Vérifiez l’espace disponible, la file d’envoi et les messages en échec. Contrôlez aussi si votre adresse ou votre domaine a été signalé.
Dans certains clients, la boîte d’envoi se remplit et la file d’attente n’avance plus : vous voyez alors “impossible d’envoyer” alors que le SMTP n’est pas le seul coupable. Ouvrez la file d’envoi, supprimez les tentatives en échec si nécessaire, puis testez un nouvel envoi après libération du quota.
La réputation joue aussi : volume soudain, nouvel expéditeur, ou changement de comportement. Les blocages peuvent durer de quelques heures à plusieurs jours selon les systèmes. Si vous suspectez une liste noire, vérifiez les outils de diagnostic du fournisseur et notez l’heure exacte du premier échec (utile pour la traçabilité).
- Quota : réception OK, envoi KO (boîtes/stockage saturés).
- File d’envoi : messages “bloqués” en attente.
- Blacklist : réputation ou domaine signalé.
- Propagation : délai après levée du blocage.
L’essentiel à retenir
- Relevez le texte exact de l’erreur : le code SMTP oriente la cause.
- Vérifiez hôte SMTP, port et mode de chiffrement (SSL/TLS vs STARTTLS) avec les paramètres officiels.
- Si la configuration est correcte, testez un autre réseau pour isoler un blocage pare-feu/antivirus/proxy.
- Traitez l’authentification en priorité : mot de passe changé, méthode non compatible (OAuth), compte restreint.
- Comparez webmail vs client : si webmail marche, le problème est côté client.
- Contrôlez quota et file d’envoi, puis examinez réputation/blacklist si l’échec persiste.
- Après chaque ajustement, refaites un test court et notez l’évolution du message d’erreur.
Pour résoudre “impossible d’envoyer des mails” vite : erreur exacte → SMTP (hôte/port/chiffrement) → réseau → auth → tests webmail/client → quota et réputation. Vous saurez où agir en moins de 10 minutes, sans réinstaller votre messagerie.
FAQ
Comment savoir si le problème vient du serveur SMTP ou de mon client mail ?
Envoyez le même message depuis le webmail du fournisseur et depuis votre client (ou un autre appareil). Si le webmail envoie, le problème est local (profil SMTP, port, chiffrement, auth). Si le webmail échoue aussi, la cause est serveur/compte ou blocage réseau côté fournisseur.
Pourquoi “impossible d’envoyer des mails” apparaît-il alors que je reçois mes messages ?
La réception peut fonctionner alors que l’envoi échoue : mauvais réglage SMTP sortant (port/SSL/TLS), authentification refusée, blocage du trafic sortant par pare-feu/antivirus, ou réputation/blacklist de l’expéditeur. Le code SMTP dans les détails permet de trier la cause.
Quel port SMTP et quel chiffrement (SSL/TLS ou STARTTLS) dois-je utiliser pour envoyer des mails ?
Vérifiez les paramètres officiels du fournisseur : 465 correspond souvent à SSL/TLS implicite, tandis que 587 est généralement associé à STARTTLS. Une configuration “sans chiffrement” déclenche fréquemment un échec immédiat si le fournisseur impose TLS.
Que faire si l’authentification échoue après un changement de mot de passe ou de sécurité du compte ?
Mettez à jour la méthode d’authentification dans le client (mot de passe vs OAuth), vérifiez l’identifiant exact, puis réactivez l’accès à l’application depuis le webmail si nécessaire. Si le compte est verrouillé ou restreint, suivez les règles du fournisseur (attente ou réinitialisation).
Est-ce que mon pare-feu ou mon antivirus peut empêcher l’envoi de mails ?
Oui. Un pare-feu/antivirus, un proxy d’entreprise ou un contrôle parental peut filtrer les ports sortants (souvent 465/587) et provoquer des timeouts ou des “connexion refusée”. Testez en changeant de réseau (Wi‑Fi → 4G/5G) pour isoler la cause.
Combien de temps faut-il pour qu’une liste noire ou un blocage de réputation soit levé ?
De quelques heures à plusieurs jours, selon les systèmes et la cause du signalement. Après une levée, la réputation se met à jour progressivement. Notez l’heure du premier échec et suivez les diagnostics du fournisseur.
Sources utiles : Centre d’aide Outlook (erreurs d’envoi et paramètres serveur), Centre d’aide Gmail (SMTP, sécurité du compte), IANA : ports et services, RFC 5321 : spécification SMTP.