WordPress n’envoie pas d’e-mails : guide SMTP débutant

Si vos formulaires fonctionnent, que WordPress affiche “E-mail envoyé”, mais que rien n’arrive (ou que tout finit en spam), vous êtes pile dans le cas le plus courant : WordPress tente d’envoyer, mais le serveur ou la configuration ne suit pas.

Le problème

Le symptôme typique : WordPress (6.9.4 en avril 2026) n’envoie pas les e-mails de réinitialisation de mot de passe, de commandes WooCommerce, de formulaires (Contact Form 7, WPForms, Gravity Forms), ou d’alertes (sauvegardes, sécurité, cron).

Quand WordPress détecte un échec au niveau de wp_mail(), vous pouvez voir ce message (souvent dans les logs, parfois affiché par un plugin) :

WP Mail SMTP: mail() a échoué.
wp_mail() was called incorrectly. 
The following From address failed: [email protected]

Ou côté PHP (logs serveur) :

PHP Warning:  mail(): Failed to connect to mailserver at "localhost" port 25, verify your "SMTP" and "smtp_port" setting in php.ini

Ou, avec certains plugins de formulaire, un message plus vague :

Une erreur est survenue lors de l'envoi de votre message. Veuillez réessayer plus tard.

Où ça apparaît :

Front-end : formulaire de contact, commande, inscription.
Admin : “Mot de passe oublié”, notifications, tests SMTP.
Cron : e-mails planifiés (newsletters, rappels, rapports) qui n’arrivent jamais.
API : sites headless / formulaires via REST qui déclenchent un e-mail.

Circonstances typiques que je croise souvent :

Après une migration (nouvel hébergeur, nouveau nom de domaine, passage HTTP→HTTPS).
Après activation d’un plugin “snippets” ou d’un plugin de formulaire.
Après une mise à jour PHP (ex. passage vers 8.1/8.2) sur un hébergement un peu strict.
Sur un VPS où le port 25 sortant est bloqué (très fréquent).

À qui s’adresse ce guide : blogueurs débutants (mais aussi intermédiaires) qui veulent une configuration SMTP fiable, et un diagnostic clair quand “ça ne part pas”. À la fin, vous saurez :

Configurer un SMTP moderne (TLS, ports, authentification, SPF/DKIM/DMARC).
Vérifier si le problème vient de WordPress, du serveur, ou de la délivrabilité.
Identifier les surcharges de wp_mail() qui cassent l’envoi.

Résumé rapide

WordPress envoie via wp_mail() (basé sur PHPMailer). Sans SMTP, l’envoi dépend souvent du serveur et échoue ou finit en spam.
La solution la plus stable pour débutants : un plugin SMTP + un vrai fournisseur (mail de domaine bien configuré, ou service transactionnel).
Si vous voyez “envoyé” mais rien n’arrive : problème de délivrabilité (SPF/DKIM/DMARC, spam, From incorrect).
Si vous voyez une erreur PHP / connexion : problème de réseau (ports bloqués, TLS, identifiants SMTP, firewall).
Si un plugin/thème modifie les headers (From/Reply-To/Content-Type), wp_mail() peut échouer ou produire des e-mails invalides.
Diagnostiquez dans l’ordre : logs + test SMTP + conflit plugin + DNS + blocage port 25.

Les symptômes

Voici ce que vous pouvez observer, du plus fréquent au plus “piégeux” :

Les e-mails n’arrivent pas, sans aucun message d’erreur dans WordPress.
Les e-mails arrivent en spam (Gmail/Outlook), ou avec un avertissement “Be careful with this message”.
Le bouton “Mot de passe oublié” ne reçoit rien (utilisateurs bloqués).
WooCommerce : commandes “en attente” mais e-mails client/admin absents.
Formulaires : message “envoyé” côté visiteur, mais aucune réception.
Erreurs SMTP : “Could not connect to SMTP host”, “Connection timed out”, “SMTP Error: Could not authenticate”.
Erreur 500 / écran blanc après ajout d’un snippet lié aux e-mails (parenthèse manquante, mauvais hook).
Ça marche en local (MAMP/Laragon) mais pas en production (ports sortants bloqués, DNS non alignés).
Ça marche parfois : certains e-mails partent, d’autres non (cron irrégulier, rate limiting, quotas, greylisting).

Compatibilité page builders : Divi 5, Elementor et Avada ne gèrent pas directement l’envoi d’e-mails, mais ils embarquent souvent des formulaires. Les problèmes SMTP impactent donc :

Divi 5 : module “Contact Form” (envoi via wp_mail()).
Elementor : Form widget (souvent via WP Mail / ou action email).
Avada : Fusion Builder forms (même logique).

Pourquoi ça arrive

Explication simple (débutant)

WordPress ne “possède” pas un serveur mail. Par défaut, il confie l’envoi à la fonction serveur (souvent mail()) via wp_mail(). Sur beaucoup d’hébergements, cette voie est limitée, désactivée, ou mal reconnue par les grands fournisseurs (Gmail, Outlook).

Résultat : soit l’envoi échoue, soit il “part” techniquement mais est rejeté/filtré.

Explication technique (intermédiaire/pro)

wp_mail() utilise PHPMailer (inclus dans WordPress) et, selon la config, envoie via :

mail() (sendmail) : dépend du serveur, souvent peu fiable en mutualisé.
SMTP : connexion authentifiée vers un serveur SMTP (recommandé).

Les causes les plus fréquentes (du plus courant au plus rare) :

Délivrabilité DNS : SPF/DKIM/DMARC absents ou incohérents, From non aligné avec le domaine.
SMTP non configuré : WordPress utilise mail() et l’hébergeur bloque/limite.
Ports sortants bloqués (25 surtout) ou TLS cassé (certificats, SNI, firewall).
Identifiants SMTP incorrects ou méthode de chiffrement/port non adaptés (465 SSL vs 587 TLS).
Plugin/thème qui filtre wp_mail_from, wp_mail_from_name ou wp_mail_content_type de façon incorrecte (headers invalides).
Conflit de plugins SMTP : deux plugins tentent de configurer PHPMailer en même temps.
Cron : WP-Cron ne s’exécute pas (pas de trafic, cache agressif), donc les e-mails “planifiés” ne partent jamais.
Hébergement : quotas/limites, blocage anti-spam, IP sur liste grise/noire.

Prérequis avant de commencer

Sauvegarde : faites une sauvegarde fichiers + base de données avant toute modification. Ne modifiez jamais le cœur de WordPress.
Versions : WordPress 6.9.4, PHP 8.1+ (recommandé). Vérifiez dans Outils → Santé du site.
Accès : idéalement accès admin WordPress + accès DNS du domaine + accès à l’hébergement (logs).
Outils utiles :
- Health Check & Troubleshooting (mode dépannage sans casser le site public) : wordpress.org/plugins/health-check
- Query Monitor (diagnostic hooks, erreurs, HTTP) : wordpress.org/plugins/query-monitor
- Doc wp_mail() : developer.wordpress.org/reference/functions/wp_mail
- Debug WordPress (WP_DEBUG) : developer.wordpress.org/advanced-administration/debug/debug-wordpress
- PHPMailer (amont technique) : github.com/PHPMailer/PHPMailer

Deux avertissements que je répète parce que je vois l’erreur chaque semaine :

Ne testez pas vos snippets sur le site en production sans sauvegarde. Une parenthèse oubliée peut déclencher une erreur 500.
N’installez pas deux plugins SMTP en même temps. Désactivez-en un avant d’en tester un autre.

Solution 1 : Configurer un SMTP fiable (méthode débutant via plugin)

Si vous débutez, la route la plus sûre est : utiliser un plugin SMTP qui configure PHPMailer proprement, puis envoyer via un serveur SMTP qui a une bonne réputation.

Ce que vous corrigez ici

Envoi via mail() non fiable → remplacement par SMTP.
Authentification, chiffrement, port correct.
Adresse “From” cohérente avec votre domaine (délivrabilité).

Choisir le bon type de SMTP (pratique)

SMTP de votre hébergeur : simple, mais parfois limité (quotas, réputation IP moyenne).
SMTP de votre domaine (Google Workspace / Microsoft 365) : bon, mais attention aux limites et à l’auth (OAuth parfois requis).
Service transactionnel (recommandé pour blogs pro) : meilleure délivrabilité, logs, webhooks (ex. Mailgun, SendGrid, Postmark, Brevo, Amazon SES). Vous obtenez des preuves d’envoi et des erreurs claires.

Je vois beaucoup de sites échouer parce qu’ils essaient d’envoyer depuis [email protected] alors que ce compte n’existe pas, ou depuis un Gmail en “From”. Le “From” doit être aligné avec le domaine expéditeur.

Étapes (sans code)

Installez un plugin SMTP réputé depuis le répertoire officiel WordPress. Exemple : “WP Mail SMTP” (ou équivalent). Faites-le depuis Extensions → Ajouter.
Désactivez tout autre plugin SMTP/Email déjà présent (sinon conflit).
Dans les réglages du plugin :
- Renseignez From Email : une adresse du domaine (ex. [email protected]).
- Activez “Force From Email” si votre site a plusieurs sources d’e-mails (WooCommerce, formulaires).
- Choisissez votre méthode : SMTP (host/port) ou API (si le plugin le propose).
- Testez l’envoi avec l’outil “Send a Test Email”.

Table de correspondance ports/chiffrement (cause classique d’échec)

Cas	Port	Chiffrement	Symptôme si mauvais
SMTP moderne standard	587	TLS (STARTTLS)	Timeout / handshake TLS
SMTP SSL implicite	465	SSL	“Could not connect to SMTP host”
Port historique (souvent bloqué)	25	aucun ou STARTTLS	Timeout (bloqué par hébergeur)

Diagnostic DNS indispensable (SPF/DKIM/DMARC)

Si l’e-mail “part” mais arrive en spam ou n’arrive jamais, le problème est souvent là. Pour un débutant, retenez :

SPF : autorise quels serveurs ont le droit d’envoyer pour votre domaine.
DKIM : signe cryptographiquement les e-mails.
DMARC : dit quoi faire si SPF/DKIM échouent, et fournit des rapports.

Vous configurez ça dans la zone DNS du domaine (chez votre registrar). Le contenu exact dépend du fournisseur SMTP (ils donnent les entrées à ajouter). Sans ces enregistrements, Gmail/Outlook deviennent très stricts.

Référence utile (concepts, côté PHP mail) : php.net/manual/en/function.mail.php

“Avant / Après” (cas réel : WordPress envoie via mail() et ça échoue)

Ce “avant” n’est pas un code que vous avez forcément écrit. C’est ce que fait WordPress si rien n’est configuré : envoi via la voie serveur, parfois bloquée.

AVANT (envoi basique via wp_mail, dépend du serveur)

<?php
// Exemple simplifié : un plugin de formulaire appelle wp_mail().
// Si le serveur bloque mail(), rien ne part ou ça finit en spam.

wp_mail(
	'[email protected]',
	'Test WordPress',
	'Bonjour, ceci est un test.'
);

APRÈS (même appel wp_mail, mais PHPMailer est configuré par le plugin SMTP)

<?php
// Rien à changer dans vos formulaires : le plugin SMTP configure PHPMailer.
// L'appel wp_mail() reste identique, mais l’envoi passe par SMTP/API.

wp_mail(
	'[email protected]',
	'Test WordPress via SMTP',
	'Bonjour, ceci est un test via SMTP.'
);

Pourquoi ça corrige : vous ne dépendez plus de mail() (souvent désactivé, non authentifié, mal réputé). Le SMTP authentifie l’expéditeur et fournit des erreurs plus claires.

Où “mettre quelque chose” ?

Pour cette solution : nulle part dans le code. C’est volontaire. En dépannage débutant, je privilégie d’abord une config SMTP propre et testable.

Solution 2 : Corriger les surcharges de wp_mail() (from, headers, HTML) qui cassent l’envoi

J’ai souvent croisé ce problème sur des sites où quelqu’un a collé un snippet “pour changer l’expéditeur” trouvé sur un vieux tutoriel. Ça marche parfois… jusqu’au jour où un plugin ajoute des headers, et l’e-mail devient invalide.

Définitions rapides (première fois) :

Hook : point d’accroche dans WordPress. Il y a des actions (exécuter du code) et des filtres (modifier une valeur).
Filtre : hook qui reçoit une valeur et doit la retourner (ex. wp_mail_from).

Cas A : mauvais “From” (adresse invalide ou non alignée)

Symptômes : e-mails rejetés, en spam, ou erreur SMTP “From address failed”.

AVANT (cassé : renvoie une chaîne non e-mail ou un domaine différent)

<?php
// Mauvais snippet trouvé sur un vieux forum : adresse invalide.
// Souvent collé dans functions.php du thème (pire : thème parent).

add_filter('wp_mail_from', function () {
	return 'WordPress'; // ❌ Ce n'est pas une adresse e-mail
});

APRÈS (corrigé : From cohérent et filtrable)

<?php
/**
 * Corrige l'adresse d'expéditeur pour les e-mails WordPress.
 *
 * OÙ COLLER CE CODE :
 * - Idéal : dans un mu-plugin (wp-content/mu-plugins/bpcab-mail.php)
 * - Ou dans un plugin custom
 * - Évitez functions.php si vous changez souvent de thème
 *
 * Sauvegardez avant de modifier.
 */

add_filter('wp_mail_from', function ($from_email) {
	// Utilisez un e-mail du domaine du site pour améliorer la délivrabilité.
	$site_host = wp_parse_url(home_url(), PHP_URL_HOST);

	// Fallback simple si parsing échoue.
	if (empty($site_host)) {
		return 'no-reply@' . preg_replace('/^www./', '', $_SERVER['HTTP_HOST'] ?? 'example.com');
	}

	$site_host = preg_replace('/^www./', '', $site_host);

	return 'no-reply@' . $site_host;
}, 20);

add_filter('wp_mail_from_name', function ($from_name) {
	// Nom lisible, évite les caractères exotiques qui cassent certains serveurs.
	return wp_specialchars_decode(get_bloginfo('name'), ENT_QUOTES);
}, 20);

Pourquoi ça corrige : vous fournissez une adresse valide, stable, alignée avec le domaine. Vous réduisez les rejets “spoofing”.

Créer un mu-plugin (recommandé)

Un mu-plugin (Must-Use plugin) est chargé automatiquement par WordPress, avant les plugins classiques. Pratique pour un correctif critique (comme le mail). Créez :

Dossier : wp-content/mu-plugins/ (s’il n’existe pas, créez-le)
Fichier : wp-content/mu-plugins/bpcab-mail.php

Structure minimale :

<?php
/**
 * Plugin Name: BPCAB - Correctifs e-mail
 * Description: Correctifs mu-plugin pour l'expéditeur et la compatibilité wp_mail().
 * Author: Vous
 */

// Ici, collez les add_filter() de cette section.

Cas B : content-type HTML forcé partout (casse certains e-mails système)

Symptômes : e-mails de reset mot de passe illisibles, liens cassés, ou erreurs sur certains serveurs SMTP stricts.

AVANT (cassé : force HTML pour tout, sans retour au type initial)

<?php
// ⚠️ Erreur fréquente : forcer le HTML globalement.
// Certains plugins s'attendent à du text/plain.

add_filter('wp_mail_content_type', function () {
	return 'text/html';
});

APRÈS (corrigé : HTML uniquement quand vous en avez besoin)

<?php
/**
 * Active le HTML uniquement pour vos e-mails "marketing" (ex: formulaire),
 * sans casser les e-mails système.
 *
 * OÙ COLLER : mu-plugin ou plugin custom.
 */

function bpcab_mail_set_html_content_type($content_type) {
	return 'text/html';
}

function bpcab_send_html_mail($to, $subject, $html_message, $headers = array(), $attachments = array()) {
	// On ajoute le filtre juste avant l'envoi.
	add_filter('wp_mail_content_type', 'bpcab_mail_set_html_content_type', 20);

	$sent = wp_mail($to, $subject, $html_message, $headers, $attachments);

	// On retire le filtre juste après pour ne pas affecter les autres e-mails.
	remove_filter('wp_mail_content_type', 'bpcab_mail_set_html_content_type', 20);

	return $sent;
}

Pourquoi ça corrige : vous évitez un effet de bord global. Dans mon expérience, c’est une cause sous-estimée de “ça marchait hier” après l’ajout d’un snippet.

Cas C : headers mal formés (Reply-To, CC, etc.)

Symptômes : erreurs PHPMailer, e-mails rejetés, parfois pas d’erreur visible côté WordPress.

AVANT (cassé : mélange de formats, retours ligne incorrects)

<?php
$headers = "Reply-To: [email protected]"; // ❌ n au lieu de rn (selon contexte)
$headers .= "CC: [email protected], [email protected]"; // ❌ format fragile

wp_mail('[email protected]', 'Sujet', 'Message', $headers);

APRÈS (corrigé : headers en tableau, format robuste)

<?php
$headers = array(
	'Reply-To: Contact <[email protected]>',
	'Cc: Copie <[email protected]>',
);

wp_mail('[email protected]', 'Sujet', 'Message', $headers);

Pourquoi ça corrige : wp_mail() accepte un tableau d’en-têtes, ce qui évite des erreurs de format. Référence : developer.wordpress.org/reference/functions/wp_mail.

Solution 3 : Diagnostic avancé (logs, WP-CLI, cron, hébergeur)

Cette partie sert quand vous avez “bien configuré” le SMTP, mais que ça échoue encore, ou quand vous devez prouver à l’hébergeur ce qui bloque.

Activer des logs WordPress propres (sans afficher aux visiteurs)

Dans wp-config.php (à la racine WordPress), ajoutez/ajustez :

<?php
// Sauvegardez avant modification. Ne faites pas ça en production sans comprendre l'impact.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);   // Log dans wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // Ne pas afficher les erreurs aux visiteurs

Doc officielle : developer.wordpress.org/advanced-administration/debug/debug-wordpress

Logger les erreurs de wp_mail() (mu-plugin de diagnostic)

WordPress expose le filtre wp_mail_failed (action déclenchée quand l’envoi échoue). C’est un excellent “capteur” quand un plugin masque l’erreur.

Où coller : mu-plugin (recommandé) wp-content/mu-plugins/bpcab-mail-debug.php.

<?php
/**
 * Plugin Name: BPCAB - Debug wp_mail()
 * Description: Journalise les échecs d'envoi d'e-mails WordPress dans debug.log.
 */

add_action('wp_mail_failed', function ($wp_error) {
	// $wp_error est une instance de WP_Error.
	if (!($wp_error instanceof WP_Error)) {
		return;
	}

	// On logge uniquement si WP_DEBUG_LOG est actif.
	if (defined('WP_DEBUG_LOG') && WP_DEBUG_LOG) {
		error_log('--- wp_mail_failed ---');
		error_log('Code: ' . implode(', ', $wp_error->get_error_codes()));
		error_log('Message: ' . $wp_error->get_error_message());

		$data = $wp_error->get_error_data();
		if (!empty($data)) {
			error_log('Données: ' . print_r($data, true));
		}
	}
}, 10);

Pourquoi c’est utile : vous récupérez des erreurs du type “Could not authenticate” ou “Invalid address” au lieu d’un simple “ça n’arrive pas”.

Tester WP-Cron (e-mails planifiés)

Si seuls les e-mails “planifiés” échouent (newsletters, rapports), suspectez WP-Cron :

Sur certains sites, un cache agressif ou un trafic faible empêche WP-Cron de se déclencher.
Certains hébergeurs recommandent de désactiver WP-Cron et de passer par un vrai cron système.

Vérification rapide : installez un plugin de gestion cron (ou utilisez un outil qui liste les événements). Si vous êtes à l’aise en ligne de commande, WP-CLI aide beaucoup.

WP-CLI (si disponible) :

wp cron event list --due-now
wp cron event run --due-now

Si tout est “en retard” et ne s’exécute jamais, c’est un signal fort.

Ports sortants bloqués (le grand classique)

Si votre SMTP est sur le port 25, testez autre chose. Beaucoup d’hébergeurs bloquent le 25 pour limiter le spam. Préférez :

587 TLS (le plus courant)
465 SSL (selon fournisseur)

Quand c’est bloqué, vous voyez souvent :

SMTP connect() failed. Connection timed out

Dans ce cas, vous ne “réparez” pas WordPress : vous changez de port, ou vous passez par un service transactionnel.

Vérifications après correction

Ne vous contentez pas d’un seul test. Validez en conditions réelles.

Test SMTP via le plugin : envoyez vers une adresse Gmail et une adresse Outlook (comportements différents).
Test e-mail système : utilisez “Mot de passe oublié” sur un compte test.
Test formulaire : envoyez un message depuis le front (Divi/Elementor/Avada si vous utilisez leurs formulaires).
Vérifiez les en-têtes dans l’e-mail reçu : From, Reply-To, et si possible “mailed-by”.
Surveillez debug.log pendant 10 minutes : aucune nouvelle entrée wp_mail_failed.

Résultats attendus :

Les e-mails arrivent en boîte principale (ou au moins pas systématiquement en spam).
Les tests ne déclenchent pas d’erreur d’authentification/connexion.
Les e-mails système (reset) restent lisibles (souvent en texte brut).

Si ça ne marche toujours pas

Procédure de dépannage que j’applique, dans cet ordre, pour éviter de partir dans tous les sens.

1) Vérifiez les erreurs exactes (ne devinez pas)

Activez le mu-plugin wp_mail_failed (Solution 3) et reproduisez le problème.
Regardez wp-content/debug.log.
Regardez les logs PHP de l’hébergeur (souvent dans le panel).

2) Désactivez les conflits (Health Check)

Avec Health Check, activez le mode dépannage :

Désactivez tous les plugins sauf le plugin SMTP.
Repassez temporairement sur un thème par défaut (si possible) pour tester.

Si ça fonctionne : vous avez un conflit. Réactivez un par un jusqu’à trouver le coupable (souvent un plugin de sécurité, cache, ou un snippet “mail”).

3) Videz les caches (oui, ça compte)

Cache plugin (page cache), cache serveur (LiteSpeed/Varnish), cache CDN (Cloudflare), et cache navigateur.
Certains formulaires chargent des scripts conditionnels : un vieux JS peut empêcher la soumission, donc pas d’e-mail.

4) Confirmez le “From” et l’alignement domaine

From = domaine du site (ex. @votredomaine.tld).
Évitez From = Gmail/Yahoo si vous envoyez depuis votre serveur : ça déclenche des politiques anti-spoofing.

5) Vérifiez SPF/DKIM/DMARC

Si vous utilisez un service transactionnel, suivez leur guide DNS. En pratique, si DKIM manque, Gmail met facilement en spam.

6) Vérifiez la version PHP et la mémoire

PHP 8.1+ recommandé. Certaines stacks SMTP/TLS se comportent mieux avec OpenSSL à jour.
Si vous avez des erreurs fatales lors de l’envoi, augmentez la mémoire WordPress/PHP (selon hébergeur).

7) Réglez le cas “WP-Cron ne tourne pas”

Si l’envoi dépend d’événements planifiés, configurez un cron serveur et désactivez WP-Cron (cas avancé). Faites-le avec prudence : mal fait, vous cassez les tâches planifiées.

Pièges et erreurs courantes

Symptôme	Cause probable	Vérification	Solution
“E-mail envoyé” mais rien reçu	Délivrabilité (SPF/DKIM/DMARC), spam	Dossier spam + headers + logs du fournisseur SMTP	Configurer DNS + From aligné + service transactionnel
Erreur “Could not authenticate”	Identifiants SMTP incorrects / méthode auth	Test SMTP du plugin + logs	Recréer mot de passe d’application / vérifier user/pass
Timeout SMTP	Port bloqué (25), firewall, mauvais host	Changer port 587/465, tester à nouveau	Utiliser 587 TLS ou un service API
Erreur 500 après ajout snippet	Point-virgule/parenthèse oubliée	Logs PHP, debug.log	Retirer le snippet, corriger syntaxe, passer en mu-plugin
Certains e-mails illisibles	Content-Type forcé en HTML partout	Inspecter snippets (`wp_mail_content_type`)	Activer HTML seulement ponctuellement (Solution 2B)
Ça marche puis ça casse après MAJ thème	Code collé dans thème parent	Comparer fichiers, historique	Mettre le code dans thème enfant / plugin / mu-plugin
Deux plugins SMTP installés	Conflit PHPMailer	Liste des plugins actifs	Gardez un seul plugin SMTP

Erreurs très réalistes que je vois chez les débutants

Copier le code au mauvais endroit : dans un article, dans l’éditeur de page, ou dans le thème parent. Utilisez un mu-plugin ou un plugin custom.
Utiliser un hook inadapté : ex. essayer de modifier le “From” via une action au lieu d’un filtre. Pour wp_mail_from, c’est un filtre, donc vous devez retourner une valeur.
Oublier de vider le cache et croire que le formulaire n’envoie pas (alors que c’est le JS qui n’est pas à jour).
Suivre un vieux tutoriel qui parle d’anciennes versions de PHPMailer/WordPress et propose des constantes ou méthodes obsolètes.
Tester sur production et se retrouver bloqué hors admin après une fatale. Faites un staging si possible.

Variante / alternative

Méthode sans code : passer par une API d’envoi (souvent plus fiable que SMTP)

Si votre plugin SMTP propose une intégration API (SendGrid, Mailgun, Postmark, SES, etc.), c’est souvent plus robuste :

Moins de problèmes de ports/TLS.
Meilleurs logs (bounces, blocks, spam reports).
Délivrabilité généralement supérieure.

Méthode développeur : plugin custom minimal pour imposer une politique mail

Si vous gérez plusieurs sites (ou un site client), je préfère un petit plugin custom qui :

Fixe “From” et “From name” proprement.
Logge wp_mail_failed en environnement de staging.
Évite les snippets éparpillés.

Vous avez déjà les briques dans les solutions 2 et 3. Le point clé : centraliser, versionner, documenter.

Éviter ce problème à l’avenir

Utilisez un expéditeur stable : [email protected] ou [email protected]. Évitez les adresses “fantômes”.
Documentez votre SMTP (host/port/méthode). Le jour d’une migration, vous gagnerez une heure.
SPF/DKIM/DMARC : faites-le une fois, correctement. Sans ça, vous jouez à la loterie.
Un seul point de configuration : un plugin SMTP + éventuellement un mu-plugin pour les filtres “From”. Pas 3 plugins et 2 snippets.
Surveillez les bounces : un service transactionnel vous dira si vous êtes bloqué. Sans logs, vous êtes aveugle.
Staging : testez les mises à jour de plugins de formulaire et de sécurité en préprod quand c’est possible.

Ressources

Questions fréquentes

Est-ce que WordPress 6.9.4 a “cassé” l’envoi d’e-mails ?

La majorité des pannes ne viennent pas du cœur WordPress, mais de la configuration serveur, du DNS, ou d’un plugin qui surcharge wp_mail(). Une mise à jour peut révéler un problème latent (TLS plus strict, plugin mis à jour, etc.).

Pourquoi ça marche pour certains e-mails mais pas pour d’autres ?

Souvent parce que les sources n’utilisent pas les mêmes headers (From/Reply-To), ou parce que certains e-mails sont envoyés via WP-Cron. Un SMTP mal configuré peut “tolérer” un cas et refuser un autre.

Dois-je utiliser le SMTP de mon hébergeur ?

Vous pouvez, mais si vous tenez à la délivrabilité et aux logs, un service transactionnel est généralement plus prévisible. Sur certains mutualisés, la réputation IP est un vrai sujet.

Quel port SMTP choisir ?

En pratique : 587 avec TLS (STARTTLS) est le choix le plus courant. 465 en SSL marche aussi selon fournisseur. Évitez 25 si possible : il est souvent filtré.

Mon e-mail arrive en spam. Le SMTP suffit ?

Non. Le SMTP règle l’envoi, pas la réputation. Pour sortir du spam : From aligné, SPF/DKIM/DMARC, contenu non “spammy”, et idéalement un service transactionnel avec une bonne réputation.

Puis-je envoyer depuis une adresse Gmail en “From” ?

Je le déconseille fortement si l’envoi part depuis votre serveur ou un SMTP différent. Les politiques anti-spoofing (DMARC) rendent ça très fragile. Utilisez une adresse de votre domaine.

Où trouver l’erreur exacte quand un e-mail échoue ?

Activez WP_DEBUG_LOG et ajoutez le mu-plugin basé sur wp_mail_failed (Solution 3). Beaucoup de plugins masquent l’erreur, alors que WordPress la fournit via WP_Error.

Divi 5 / Elementor / Avada : est-ce que ça change quelque chose ?

Pas pour l’envoi lui-même. Le builder déclenche l’envoi via WordPress. Par contre, un cache/minification peut casser la soumission du formulaire (donc pas d’e-mail). Si vous suspectez ça, testez en désactivant temporairement l’optimisation.

Est-ce dangereux d’activer WP_DEBUG sur un site en production ?

Ça peut l’être si vous affichez les erreurs à l’écran. Utilisez WP_DEBUG_DISPLAY à false et loggez dans un fichier. Et désactivez-le après dépannage.

J’ai mis le code dans functions.php et tout a planté. Que faire ?

Restaurez le fichier via FTP/gestionnaire de fichiers, ou repassez sur une sauvegarde. Ensuite, placez le code dans un mu-plugin (chargement plus stable) et collez-le tel quel, sans le modifier à la volée.