Contact form not sending sur WordPress - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant toute manipulation, range ton problème dans l'un des deux incidents. Ils ont des causes opposées et un mauvais diagnostic te fait perdre des heures.

Incident A — l'envoi (le plus courant). Le visiteur voit « Merci, votre message a bien été envoyé ». Côté admin, rien n'arrive dans la boîte de réception. Ce n'est PAS une preuve de fonctionnement : le message de succès de Contact Form 7 ou WPForms s'affiche dès que wp_mail() rend la main, pas quand le serveur de messagerie a réellement accepté le mail. Le mail peut être parti en spam, avoir été rejeté par Gmail, ou n'avoir jamais quitté ton serveur.

Incident B — le plantage UI. La soumission tourne en boucle (spinner infini), affiche un cadre rouge d'erreur, ou le bouton ne réagit pas. Là, le mail n'est même pas tenté : c'est du JavaScript, un conflit de plugin, une erreur AJAX (admin-ajax.php) ou des permaliens cassés.

Vérifie d'abord l'évidence pour l'incident A : le dossier Spam / Indésirables de la boîte destinataire, ainsi que l'adresse réellement utilisée. Confusion classique signalée sur les forums FR : l'adresse de l'admin (Réglages » Général) n'est pas forcément celle du champ destinataire du formulaire (Contact » Formulaires de contact » onglet Mail » champ « À »).

• Incident A — succès affiché, aucun mail : problème SMTP / délivrabilité (sections Diagnostic et Solutions §SMTP).
• Incident B — spinner infini ou erreur rouge : conflit plugin / thème / AJAX / permaliens (Solutions §conflit).
• Mail dans les indésirables du destinataire : SPF/DKIM manquants, pas une panne d'envoi.
• Couleur du bandeau CF7 : vert = succès, jaune/orange = problème de validation ou de config mail, rouge = échec d'envoi ou erreur réseau.

Impact business immédiat

Un formulaire KO ne déclenche aucune alerte : c'est ce qui le rend dangereux. Contrairement à un site en erreur 500, personne ne te prévient. Tu découvres la panne quand un client râle « je vous ai écrit il y a une semaine » ou quand le pipeline commercial se vide sans raison apparente.

Pour un site e-commerce ou de services, chaque formulaire perdu est une demande de devis, une question avant achat ou un contact SAV évaporé. La durée moyenne de détection d'une panne d'envoi silencieuse se compte en jours, parfois en semaines : autant de leads jamais rappelés et de chiffre d'affaires invisible.

• Leads et demandes de devis perdus sans aucune trace ni notification.
• Baisse progressive du pipeline commercial, attribuée à tort à une « mauvaise période ».
• Opportunités B2B et SAV manquées, dégradant la réputation (« ils ne répondent jamais »).
• Aucune détection immédiate : la panne dure jusqu'au signalement d'un tiers.

Causes classées par probabilité

Voici l'ordre statistique réel, du plus fréquent au plus rare. Diagnostique dans cet ordre, tu résoudras 90 % des cas avant la moitié de la liste.

• 1. wp_mail() s'appuie sur PHP mail() sans authentification SMTP : ~80 % des emails filtrés en spam ou refusés par Gmail/Outlook/Orange. Cause n°1 absolue.
• 2. L'hébergeur français bloque le SMTP sortant ou le port 25/587 (OVH, o2switch, Ionos selon l'offre) : cause racine n°1 spécifique à la France, souvent invisible dans les guides EN.
• 3. Champ expéditeur (From) invalide : adresse @gmail.com / @yahoo.fr en From, ou wordpress@domaine par défaut. Rejet renforcé depuis février 2024.
• 4. SPF / DKIM / DMARC absents ou erronés sur le domaine : mails marqués spam ou rejetés.
• 5. Conflit de plugin ou de thème (incident B) : JS cassé, AJAX en échec.
• 6. Anti-spam mal réglé : clés reCAPTCHA/Turnstile invalides, ou pare-feu (Wordfence) qui bloque admin-ajax.php.
• 7. Permaliens cassés ou cache servant une page de soumission obsolète (incident B).
• 8. Mise à jour récente : WordPress, PHP < 7.4 ou plugin incompatible (le « ça marchait avant »).

Diagnostic : les commandes à lancer

Objectif : savoir si le mail QUITTE ton serveur. Tant que tu n'as pas cette réponse, tu navigues à l'aveugle. Trois pistes : les logs serveur, un log applicatif, et un test SMTP isolé.

1) Vérifier la file et les logs mail côté serveur (SSH). Si tu as un accès SSH, c'est la vérité terrain. Cherche une trace de l'envoi au moment du test :

2) Tester directement la fonction d'envoi de PHP, sans passer par le formulaire, pour isoler WordPress de la couche mail :

3) Vérifier l'authentification du domaine (SPF/DKIM/DMARC) depuis n'importe quelle machine. Un SPF absent = mails en spam garantis :

4) Activer un log applicatif quand tu n'as pas de SSH. Installe « WP Mail Logging » ou utilise WP Mail SMTP » Réglages » Email Log. Chaque soumission crée une ligne : statut « Sent » signifie que wp_mail a rendu la main sans erreur (≠ livré), « Failed » te donne le message d'erreur SMTP exact (auth refusée, connexion refusée sur port 587, etc.).

5) Lire le résultat. Si le test SMTP de WP Mail SMTP (Outils » Test d'email) échoue avec « Could not connect to SMTP host » ou « Connection timed out », c'est ton hébergeur qui bloque le port (voir section hébergeurs). Si c'est « SMTP Error: Could not authenticate », c'est un mot de passe d'application erroné.

# File d'attente Postfix/Exim et logs au moment du test
mailq | tail -n 20

# Chercher la trace d'un envoi (adapter le chemin selon l'hébergeur)
sudo tail -n 100 /var/log/mail.log | grep -i "status="
# o2switch / cPanel : exim
sudo tail -n 100 /var/log/exim_mainlog | grep -i "<= \|=> \|** "

# Filtrer les rejets et différés
grep -iE "reject|deferred|bounced|timed out" /var/log/mail.log | tail -n 30

# Via WP-CLI : teste la pile wp_mail() complète (plugins SMTP inclus)
wp eval 'var_dump( wp_mail( "[email protected]", "Test wp_mail", "Corps de test depuis WP-CLI" ) );'

# true  = wp_mail a accepte l'envoi (ne garantit pas la livraison)
# false = echec immediat -> lire l'erreur ci-dessous
wp eval 'add_action("wp_mail_failed", function($e){ error_log( print_r( $e->get_error_message(), true ) ); }); wp_mail("[email protected]","Test","x");'

# Test brut PHP mail() hors WordPress (isole la couche serveur)
php -r 'var_dump( mail("[email protected]","Test PHP mail","corps") );'

# SPF : doit lister ton hebergeur / ton service SMTP
dig +short TXT votredomaine.com | grep -i spf

# DMARC : enregistrement _dmarc requis depuis 2024
dig +short TXT _dmarc.votredomaine.com

# DKIM (selecteur fourni par le service SMTP, ex: 'default', 'k1')
dig +short TXT default._domainkey.votredomaine.com

Solutions pas-à-pas

Applique dans l'ordre. La solution 1 (SMTP authentifié) règle à elle seule la grande majorité des incidents A.

Pour l'incident B (plantage UI), saute directement à l'étape 5.

1. 1. Installer et configurer un SMTP authentifié. Installe WP Mail SMTP ou FluentSMTP. Lance l'assistant, choisis ton service (Brevo/Sendinblue, Postmark, Gmail API, ou le SMTP de ton hébergeur). Renseigne hôte, port (587 en TLS ou 465 en SSL), identifiant et mot de passe d'application. Active impérativement « Force From Email » et « Force From Name » pour écraser le From par défaut.
2. 2. Corriger le champ expéditeur (From). Le From doit être une vraie boîte de TON domaine : [email protected], jamais [email protected] ni une adresse @gmail.com/@yahoo.fr. Dans Contact Form 7 : Contact » Formulaires » onglet Mail » champ « De ». Mets [email protected] et place l'adresse du visiteur dans « Reply-To: [your-email] » via la section En-têtes additionnels.
3. 3. Authentifier le domaine (SPF/DKIM/DMARC). Dans la zone DNS de ton domaine : ajoute l'enregistrement SPF fourni par ton service SMTP, les clés DKIM (CNAME ou TXT), et un DMARC minimal : v=DMARC1; p=none; rua=mailto:[email protected]. Sans ça, Gmail/Yahoo classent ou rejettent depuis 2024.
4. 4. Envoyer un email de test et lire le log. WP Mail SMTP » Outils » Test d'email vers une adresse Gmail ET une adresse pro. Confirme l'arrivée hors spam, puis ouvre l'en-tête du mail reçu : SPF=pass, DKIM=pass, DMARC=pass doivent apparaître. Tant que ces trois ne sont pas « pass », continue.
5. 5. Tester un conflit de plugin / thème (incident B et A persistant). Active le thème par défaut (Twenty Twenty-Four). Désactive tous les plugins SAUF le formulaire et le SMTP. Re-teste. Si ça remarche, réactive un par un jusqu'à trouver le coupable (souvent un cache agressif, un pare-feu, ou un autre plugin SMTP en doublon).
6. 6. Débloquer l'anti-spam et l'AJAX. Vérifie les clés reCAPTCHA/Turnstile (Contact » Intégration) : une clé invalide bloque la soumission silencieusement. Dans Wordfence, assure-toi que admin-ajax.php n'est pas bloqué. Pour CF7, n'accuse pas Akismet : il gère les commentaires, pas la soumission CF7.
7. 7. Réenregistrer les permaliens et vider le cache. Réglages » Permaliens » Enregistrer (sans rien changer) régénère les règles de réécriture. Vide ensuite tout cache (plugin + CDN) pour éviter qu'une page de soumission obsolète soit servie.
8. 8. Si rien ne part : c'est l'hébergeur. Si le test SMTP échoue en timeout/connexion refusée, ouvre un ticket support pour faire débloquer l'envoi sortant ou le port 587/465 (voir tableau ci-dessous).

Reply-To: [your-email]
Return-Path: [email protected]

# Champ « De » : [email protected]
# (jamais [your-email] ni une adresse @gmail.com en expediteur)

Spécificités par hébergeur français

C'est le trou des guides anglophones et l'angle qui résout le plus de cas en France. Citation littérale d'un forum WPFR après des heures de diagnostic : « Problème réglé. OVH avait bloqué l'envoi de mails. » Avant de soupçonner ton code, vérifie si ton hébergeur bloque le SMTP sortant.

Règle générale : le port 25 est presque toujours bloqué en mutualisé. Utilise le SMTP authentifié de l'hébergeur (ou d'un tiers) sur le port 587 (TLS) ou 465 (SSL).

• OVH (mutualisé) : envoi via PHP mail() souvent bridé/bloqué. Utilise ssl0.ovh.net en 587/465 avec une adresse mail OVH authentifiée. Si rien ne part malgré une config correcte, ouvre un ticket : un blocage anti-spam sortant peut être actif sur le compte.
• o2switch : serveur Exim local autorisé, mais délivrabilité faible sans SMTP authentifié. SMTP : mail.votredomaine.com en 587/465. Logs consultables via cPanel » Email Deliverability (et exim_mainlog en SSH).
• Hostinger : PHP mail() limité en volume. SMTP : smtp.hostinger.com en 587. Active SPF/DKIM depuis hPanel (générés automatiquement pour les boîtes Hostinger).
• Ionos (1&1) : port 25 bloqué, SMTP authentifié obligatoire : smtp.ionos.fr en 587/465. Vérifie que la boîte d'envoi existe bien côté Ionos.
• Gandi : SMTP mail.gandi.net en 587, authentification obligatoire. SPF/DKIM à activer dans l'interface Gandi Mail.

Spécificités par version

Le cas « tout marchait, cassé après une mise à jour » se relie presque toujours à une incompatibilité de version.

PHP : WordPress moderne exige PHP ≥ 7.4 (recommandé 8.1+). Sous une version trop ancienne, la pile mail de certains plugins échoue silencieusement. Vérifie via Outils » Santé du site » Info » Serveur. Exigences serveur citées : PHP ≥ 7.4, MySQL ≥ 5.7 ou MariaDB ≥ 10.4.

WordPress 5.x vs 6.x : sur 6.x, l'éditeur de blocs peut imbriquer le shortcode du formulaire dans un bloc mal converti après migration : re-teste en éditant le bloc en HTML brut. Le hook wp_mail_failed (depuis WP 4.4) reste la méthode fiable pour capturer l'erreur, quelle que soit la version.

Plugins : après une mise à jour majeure de Contact Form 7 ou WPForms, une clé reCAPTCHA v2/v3 mal migrée bloque la soumission. Si la panne suit pile une mise à jour, fais un rollback du plugin (WP Rollback) pour confirmer la corrélation avant d'investiguer plus loin.

Localhost : un formulaire ne peut PAS envoyer en local (MAMP/Local/XAMPP) sans serveur mail configuré : c'est normal, pas un bug. Teste toujours la délivrabilité en environnement de prod ou préprod.

Quand appeler un expert

Tu as configuré le SMTP, corrigé le From, posé SPF/DKIM/DMARC, et pourtant les mails arrivent encore en spam ou pas du tout ? Ou le test SMTP échoue en timeout et le support hébergeur renvoie la balle ? À ce stade, le problème est souvent une combinaison délivrabilité + config serveur qui demande un diagnostic terrain (lecture des logs Exim/Postfix, en-têtes complets, réputation IP).

BugRescue (Soulaimane Aattar, fondateur) intervient sur ces cas : audit de la chaîne d'envoi de bout en bout, mise en place d'un SMTP transactionnel fiable avec monitoring de livraison, et déblocage côté hébergeur. L'objectif : un formulaire dont chaque soumission est tracée et dont la livraison est prouvée, pas seulement affichée.

• Mails toujours en spam malgré SPF/DKIM/DMARC en « pass ».
• Blocage hébergeur que le support ne lève pas, ou IP serveur sur liste noire.
• Besoin d'un monitoring de livraison et d'alertes sur échec (Postmark/SendGrid).
• Perte de leads à fort enjeu : il faut prouver et garantir la livraison, pas deviner.

FAQ