Dépannage

WordPress n’envoie pas d’emails.

Le formulaire dit merci, la commande passe, et rien n’atterrit dans aucune boîte. Avant d’essayer des correctifs au hasard, répondez à une question : vos emails échouent-ils à partir du site, ou partent-ils sans jamais arriver ? Le correctif est différent dans chaque cas, et cette page les prend dans l’ordre.

Diagnostic · dans l'ordre 10 minutes

01 · La mécanique

Pourquoi l’email WordPress casse
sans message d’erreur.

Rien n’a rebondi, rien ne vous a prévenu, et le site lui-même a annoncé un succès. Ce silence est inscrit dans la façon dont WordPress envoie ses emails.

Chaque email produit par votre site, du formulaire de contact à la réinitialisation de mot de passe, passe par une seule fonction, wp_mail(). Par défaut, elle remet le message à la fonction PHP mail() du serveur web : aucune authentification, aucun mot de passe, une expédition depuis l’adresse que le serveur veut bien choisir. Les spammeurs ont adoré ce dispositif, alors la plupart des hébergeurs le brident, le filtrent ou le coupent, et les serveurs destinataires se méfient de ce qui passe encore.

Deux propriétés de ce montage comptent pour le diagnostic. WordPress n’enregistre pas ce qu’il envoie, il n’y a donc aucune liste intégrée à consulter. Et quand le destinataire écarte le message comme non authentifié, rien ne revient : l’échec est invisible depuis chez vous. Voilà pourquoi la première étape n’est pas un correctif, mais de la visibilité.

02 · Triage

Une question d’abord :
l’email part-il seulement ?

Dix minutes avec un journal d’emails suffisent à répondre. N’importe quel plugin de log convient ; Custom SMTP enregistre dès l’activation, avant toute configuration.

ÉTAPE 01

Installer un journal

Installez et activez Custom SMTP, ou tout plugin qui journalise les emails. À partir de là, chaque message que votre site tente d’envoyer reçoit une ligne avec son issue.

ÉTAPE 02

Déclencher l’email

Soumettez le formulaire, demandez une réinitialisation de mot de passe, ou utilisez le bouton Envoyer un email de test. Puis ouvrez le journal et retrouvez la ligne créée.

ÉTAPE 03

Lire la ligne

Échec, avec un message d’erreur : l’email n’est jamais parti, direction le 03. Envoyé, mais rien n’arrive : le problème est côté réception, direction le 04.

Logs d'emailsune ligne en échec nomme sa cause
L’écran Logs d’emails dans wp-admin : messages envoyés et échoués listés avec leur statut, et une ligne en échec portant l’erreur SMTP exacte renvoyée par le serveur.

03 · Non envoyé

L’email
ne part jamais.

Une ligne en échec porte l’erreur renvoyée par le serveur, et cette phrase nomme la cause. Voici celles qui expliquent presque tous les « rien ne part ».

  • Votre hébergeur a restreint la fonction PHP mail(). Courant sur l’hébergement moderne, et l’hébergeur n’a pas tort. Ne demandez pas son retour : le mail non authentifié finit en spam de toute façon. Le correctif est d’envoyer par un serveur SMTP authentifié, c’est la section 05.
  • « Could not authenticate ». Le serveur SMTP a refusé l’identifiant ou le mot de passe. Les fournisseurs avec double authentification attendent un mot de passe d’application plutôt que celui du compte, et les fournisseurs transactionnels attendent une clé API. Votre guide fournisseur dit lequel et où le créer.
  • Connection timed out, ou refused. La requête n’a jamais atteint le serveur de mail. Vérifiez l’hôte à la faute de frappe près, puis essayez le port alternatif du fournisseur. Si rien ne passe sur aucun port, votre hébergeur bloque peut-être les connexions SMTP sortantes ; son support peut confirmer quels ports sont ouverts.
  • Deux plugins se disputent l’envoi. Deux plugins SMTP actifs en même temps reconfigurent le même PHPMailer, et les réglages du perdant disparaissent en silence. N’en gardez qu’un.
  • Le plugin de formulaire n’a jamais créé l’email. Les plugins de formulaires ont leurs propres réglages de notification, distincts de WordPress. Si le journal ne montre aucune ligne quand vous soumettez le formulaire, la notification du formulaire est désactivée ou mal adressée ; cela se corrige dans le plugin de formulaire, pas dans WordPress.

La section échecs de la documentation fait correspondre les messages d’erreur exacts, mot pour mot, à leurs causes.

04 · Non remis

« Envoyé », mais
jamais reçu.

Envoyé signifie qu’un serveur a accepté le message. Ce que le destinataire en a fait ensuite est un jugement sur votre domaine, et il se joue dans trois enregistrements DNS.

  • Vérifiez d’abord le dossier spam. Évident, et pourtant encore assez souvent la réponse pour rester en tête de liste.
  • L’adresse d’expéditeur ne vous appartient pas. Un message expédié « depuis » une adresse d’un domaine qui n’a jamais autorisé votre serveur se lit comme une contrefaçon. Utilisez une adresse de votre propre domaine, ou envoyez par le fournisseur qui possède l’adresse.
  • SPF, DKIM et DMARC manquent ou pointent ailleurs. Ces trois enregistrements DNS sont ce qui permet à un serveur destinataire de juger votre message authentique. Ils se posent chez votre hébergeur DNS, prennent quelques minutes chacun, et la section délivrabilité explique les trois simplement.
  • La suite est dans le tableau de bord du fournisseur. Une fois le message accepté, le journal d’activité du fournisseur montre les rebonds et blocages que le plugin ne peut pas voir. Un compte Amazon SES neuf en mode bac à sable, par exemple, ne remet silencieusement qu’aux destinataires vérifiés.

05 · Le correctif durable

Le correctif : du SMTP authentifié,
journal allumé.

Toutes les causes ci-dessus mènent au même endroit : cesser de dépendre du mail serveur non authentifié, envoyer par un fournisseur qui se porte garant de vous, et garder le journal pour que le prochain échec ait une cause visible.

Vous avez presque certainement déjà ce fournisseur : votre offre d’hébergement comprend un serveur SMTP, et Gmail, Outlook, Brevo, SendGrid et les autres acceptent tous du mail authentifié depuis WordPress. Choisissez le vôtre dans la liste ci-dessous ; chaque guide montre où vivent les identifiants, les réglages exacts que le preset remplit, et les pièges propres à ce fournisseur.

Tout ce sur quoi cette page s’appuie, l’envoi SMTP, le journal, les boutons de test et les alertes d’échec, est dans le plugin gratuit. Aucun étage payant ne retient la partie utile.

Choisissez votre fournisseur

Douze guides pas à pas : Gmail, Outlook, Amazon SES, SendGrid, Mailgun, Brevo, Postmark, Mailjet, Zoho, Yahoo, iCloud et Scaleway, plus tout serveur SMTP fourni par votre hébergeur.

Les guides fournisseurs

06 · FAQ

Les questions
qui reviennent.

Les versions courtes, avec les versions longues à un lien de distance.

C’est la faute de mon hébergeur ou de WordPress ?

Des deux, par construction. WordPress remet l’email à la fonction mail() du serveur ; l’hébergeur restreint cette fonction parce que les spammeurs en ont abusé. Aucun des deux ne changera, et c’est pourquoi le correctif durable est le SMTP authentifié plutôt qu’un ticket au support.

Mon formulaire de contact dit que le message est parti.

Le plugin de formulaire indique qu’il a remis le message à WordPress, rien de plus. Savoir si un serveur de mail l’a accepté, et ce que le destinataire en a fait ensuite, est précisément ce qu’il ne peut pas voir. Un journal d’emails montre la différence d’un coup d’œil : une ligne en échec avec son erreur, ou une ligne envoyée que la réception a ensuite écartée.

Faut-il un plugin payant pour corriger ça ?

Non. Le SMTP authentifié, le journal d’emails, l’aperçu, le renvoi et les alertes d’échec sont tous dans le plugin gratuit Custom SMTP, sans compte à créer et sans version pro. D’autres plugins SMTP placent le journal ou les alertes derrière un étage payant ; c’est un choix tarifaire, pas une nécessité technique.

Désactiver des plugins ou changer de thème va-t-il corriger le problème ?

Seulement quand la cause est deux plugins d’envoi qui se disputent, ou un formulaire aux notifications coupées. Le problème de fond, un mail serveur non authentifié dont les destinataires se méfient, reste le même quel que soit le thème. Diagnostiquez avec le journal d’abord ; c’est plus rapide que l’élimination.

Ça marchait depuis des années et ça s’est arrêté sans rien changer.

Quelque chose a changé hors de votre site : l’hébergeur a durci sa politique de mail, ou un fournisseur de boîtes a relevé ses exigences d’authentification, comme les grands le font périodiquement. Vos emails survivaient par tolérance, et la tolérance a pris fin. Le correctif est le même correctif durable, et il survivra aussi au prochain durcissement.

Déjà installé, toujours bloqué ?

La documentation fait correspondre chaque message d’erreur exact à sa cause, écran par écran, et le forum de support est lu et répondu.

Lire la documentation