Le formulaire dit “merci”, mais le mail n’arrive jamais
Un visiteur remplit le formulaire de contact. Le site affiche gentiment “votre message a bien été envoyé”. Sauf que dans ta boîte mail : rien. Ni dans les spams. Ni le lendemain. Ce scénario, c’est probablement le bug le plus silencieux du web — parce que personne ne t’appelle pour te dire “votre formulaire ne marche pas”, il se contente juste de ne jamais recevoir de réponse. Et de ne plus jamais revenir.
Bonne nouvelle : dans l’immense majorité des cas, ce n’est ni un bug du plugin ni une malédiction. C’est un problème d’acheminement email, et ça se répare en moins d’une heure une fois qu’on sait où regarder. On a déjà traité ce sujet côté configuration pure dans notre article sur Contact Form 7 qui n’envoie pas les emails — ici on prend l’angle plus large : n’importe quel formulaire, sur n’importe quel site, et surtout la cause racine qui explique 80% de ces silences : la fonction mail() de PHP.
Pourquoi ça arrive : les 4 causes qui expliquent 95% des cas
- La fonction
mail()de PHP est utilisée par défaut. C’est la fonction native de PHP pour envoyer des emails, sans authentification, sans compte, sans rien. La plupart des plugins de formulaire (Contact Form 7, WPForms en config basique, Ninja Forms) s’appuient dessus par défaut. Problème : cette fonction envoie l’email “à poil”, sans preuve d’identité — les serveurs de messagerie (Gmail, Outlook, Orange) la traitent avec une méfiance quasi systématique. - L’hébergeur bloque ou limite
mail(). Beaucoup d’hébergeurs mutualisés désactivent purementmail(), ou la limitent à un quota ridicule (parfois 50 emails/jour) pour lutter contre le spam envoyé depuis leurs serveurs. Ton formulaire “envoie” bien le mail côté code, mais il part dans le vide. - Le mail part mais atterrit en spam, ou nulle part. Sans SPF, DKIM ni DMARC configurés sur ton domaine, les gros fournisseurs de messagerie considèrent l’email comme non fiable et le filtrent — silencieusement, souvent sans même le mettre en spam. On a détaillé ce mécanisme dans notre guide SPF, DKIM, DMARC.
- Une validation JavaScript ou un plugin de sécurité bloque l’envoi. Un champ obligatoire mal configuré, un captcha qui rejette silencieusement, un plugin anti-spam trop agressif : le formulaire ne déclenche jamais l’envoi côté serveur, même si l’utilisateur voit “merci”.
- L’adresse “expéditeur” du formulaire n’existe pas ou n’est pas autorisée. Beaucoup de plugins envoient par défaut depuis
wordpress@tondomaine.com— une adresse qui n’a aucune existence réelle et qui n’est pas autorisée à envoyer au nom de ton domaine.
1. Vérifie d’abord que le message part vraiment (test rapide)
Avant de toucher à quoi que ce soit, isole le problème. Remplis toi-même le formulaire avec une adresse Gmail ou Outlook que tu contrôles. Attends 10 minutes. Vérifie aussi le dossier spam. Si rien n’arrive nulle part : le problème est côté envoi (fonction mail() ou SMTP). Si ça arrive en spam : le problème est côté délivrabilité (SPF/DKIM/DMARC). Cette distinction change toute la suite du diagnostic.
Si tu es sous WordPress, installe temporairement le plugin gratuit WP Mail Logging ou Check Email. Il enregistre chaque tentative d’envoi et te dit si PHP a réussi ou échoué à transmettre le mail — sans ça, tu diagnostiques à l’aveugle.
2. Arrête d’utiliser la fonction mail() de PHP
C’est LA solution qui règle le problème dans la majorité des cas, et c’est non négociable en 2026 : remplace mail() par un vrai service d’envoi transactionnel via SMTP authentifié. Concrètement, sous WordPress, installe le plugin WP Mail SMTP (ou équivalent) et connecte-le à un service comme Resend, qui offre une API simple et un généreux quota gratuit pour démarrer.
On a écrit un guide dédié pour ça : configurer l’API Resend pour envoyer des emails depuis ton site. L’idée : ton site n’envoie plus le mail lui-même en mode anonyme, il délègue à un service dont c’est le métier, avec une authentification propre (clé API), une réputation d’IP déjà établie, et un tableau de bord qui te montre noir sur blanc si l’email est parti, a été ouvert, ou a rebondi.
Si tu n’es pas sous WordPress (site sur-mesure, Astro, Next.js), le principe est identique : ton formulaire doit appeler une API d’envoi transactionnel (Resend, Postmark, SendGrid) côté serveur, jamais tenter un envoi direct depuis le navigateur ou via mail().
3. Configure SPF, DKIM et DMARC sur ton domaine
Même avec un bon service SMTP, si ton domaine n’a pas les bons enregistrements DNS, les emails peuvent finir en spam ou être rejetés. Ces trois enregistrements sont la carte d’identité de ton domaine en matière d’email :
- SPF liste les serveurs autorisés à envoyer des emails “au nom de” ton domaine.
- DKIM signe cryptographiquement chaque email pour prouver qu’il n’a pas été modifié en route.
- DMARC dit aux fournisseurs de messagerie quoi faire si SPF ou DKIM échouent (rejeter, mettre en spam, ou laisser passer).
Ces enregistrements se configurent chez ton registrar ou hébergeur DNS — on a des guides pas à pas pour Hostinger et IONOS. Le détail complet de la configuration SPF/DKIM/DMARC est dans notre article dédié à la délivrabilité — ne saute pas cette étape, c’est souvent ce qui fait la différence entre “arrive en boîte de réception” et “arrive en spam, ou pas du tout”.
4. Vérifie l’adresse expéditeur configurée dans le plugin
Va dans les réglages de ton plugin de formulaire (Contact Form 7 : onglet “Mail” ; WPForms : “Notifications”). Vérifie que le champ “From” (“De”) utilise une adresse réelle sur ton propre domaine (ex: contact@tondomaine.com), pas une adresse générique du type wordpress@tondomaine.com créée automatiquement par le plugin, ni l’adresse du visiteur lui-même en position d’expéditeur — configure plutôt l’adresse du visiteur en “Reply-To” pour pouvoir lui répondre directement.
5. Isole les blocages de validation et de sécurité
Si le test technique montre que l’email part bien côté serveur mais que certains visiteurs se plaignent que “rien ne se passe” au clic sur Envoyer, le souci est probablement côté front-end :
- Un plugin anti-spam (Akismet, honeypot mal configuré) qui bloque silencieusement sans message d’erreur clair.
- Un conflit JavaScript entre le thème et le plugin de formulaire, fréquent après une mise à jour — voir notre article sur les problèmes après mise à jour automatique WordPress.
- Un captcha (reCAPTCHA) mal configuré dont la clé API a expiré ou ne correspond plus au domaine.
Ouvre la console développeur du navigateur (F12 → onglet Console) pendant l’envoi du formulaire : toute erreur JavaScript apparaîtra là, en rouge, avec le fichier et la ligne concernés.
6. Comprends les limites serveur qui peuvent bloquer l’envoi
Sur certains hébergements mutualisés très restrictifs, des directives PHP mal réglées peuvent aussi interrompre l’envoi, notamment quand le formulaire inclut des pièces jointes ou beaucoup de champs :
| Directive | Rôle | Symptôme si trop basse | Où la régler | Valeur de départ |
|---|---|---|---|---|
max_execution_time | Temps max d’exécution d’un script PHP | Le formulaire se bloque, timeout, page blanche | wp-config.php, .htaccess, ou panel hébergeur | 60 secondes |
max_input_vars | Nombre max de champs soumis en une requête | Formulaires complexes tronqués, données manquantes | php.ini ou panel hébergeur | 3000 |
upload_max_filesize | Taille max d’un fichier joint | Erreur silencieuse si pièce jointe au formulaire | php.ini, .htaccess | 10M |
post_max_size | Taille max totale des données envoyées | Formulaire avec fichiers qui échoue sans message clair | php.ini | 12M |
Ces réglages sont détaillés dans notre guide complet des directives PHP WordPress si tu veux aller plus loin — mais dans 90% des cas de formulaire muet, le vrai coupable reste mail() et non ces limites serveur.
Tableau récapitulatif : cause → solution
| Cause | Comment le repérer | Solution |
|---|---|---|
Fonction mail() non fiable | Test d’envoi : rien nulle part, ni spam | Basculer sur SMTP via un service comme Resend |
mail() bloquée par l’hébergeur | Log plugin montre “échec” côté serveur | Contacter l’hébergeur ou migrer vers SMTP |
| Absence de SPF/DKIM/DMARC | Mail arrive en spam ou pas du tout | Configurer les enregistrements DNS |
| Adresse expéditeur invalide | ”From” pointe vers une adresse fictive | Utiliser une vraie adresse sur ton domaine |
| Captcha ou JS cassé | Bouton “Envoyer” ne fait rien, erreur console | Vérifier la console F12, réinitialiser le captcha |
| Directives PHP trop basses | Erreur silencieuse avec pièces jointes | Ajuster post_max_size, upload_max_filesize |
FAQ
Mon formulaire affiche "message envoyé" mais je ne reçois rien : est-ce normal ?
Non, mais c’est très fréquent. Le message de confirmation s’affiche côté front-end dès que le formulaire est soumis, indépendamment de la réussite réelle de l’envoi de l’email côté serveur. C’est justement ce qui rend ce bug si dangereux : personne ne se doute qu’il y a un problème.
Faut-il un compte payant chez Resend ou un service similaire ?
Non, pas pour démarrer. Resend propose un quota gratuit qui couvre largement les besoins d’un formulaire de contact classique (quelques dizaines à centaines de messages par mois). Tu ne paies que si ton volume d’envoi devient significatif.
Puis-je juste changer d'adresse email de réception au lieu de configurer SMTP ?
Ça ne réglera rien si le problème vient de la fonction mail() ou de l’absence de SPF/DKIM. Changer l’adresse de réception ne change pas la fiabilité de l’envoi initial — le mail continuera à se perdre ou à finir en spam, quelle que soit l’adresse de destination.
Comment savoir si mon hébergeur bloque la fonction mail() ?
Installe un plugin de log (WP Mail Logging) et regarde le statut de chaque tentative. Si le log affiche systématiquement une erreur ou un échec de connexion au serveur mail sortant, c’est le signe que l’hébergeur restreint ou désactive mail(). Un simple appel à son support technique confirme généralement le diagnostic.
Le formulaire fonctionnait avant et a arrêté du jour au lendemain : que s'est-il passé ?
Trois causes fréquentes : une mise à jour de plugin qui a réinitialisé les réglages SMTP, un changement de politique anti-spam chez le fournisseur de messagerie du destinataire (Gmail durcit régulièrement ses filtres), ou un certificat/clé API expiré sur le service d’envoi utilisé. Vérifie d’abord les logs, la cause apparaît presque toujours là.
Quand passer la main à un pro
Si après avoir basculé sur un service SMTP type Resend et configuré SPF/DKIM/DMARC le problème persiste, ou si tu gères plusieurs formulaires sur plusieurs domaines (multilingue, multi-marques), il devient plus rentable de faire auditer la configuration complète par quelqu’un qui le fait tous les jours plutôt que de perdre des prospects à chaque test raté. Une agence qui inclut la maintenance email dans son forfait évite justement ce genre de silence qui coûte des clients sans que personne ne s’en aperçoive — c’est précisément le genre de détail qui distingue un site maintenu sérieusement d’un site laissé à l’abandon après la mise en ligne.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy