Formulaire de contact WordPress : pourquoi vous ne recevez plus les mails
Le 4 septembre au soir, on s’est aperçus que notre propre formulaire de contact n’envoyait plus rien. Pas depuis la veille : depuis des semaines. On a testé quatre causes, dans l’ordre. La bonne n’était pas celle qu’on croyait, et c’est presque toujours la même chez les sites qu’on récupère en audit.
Les trois fausses pistes qu’on a explorées d’abord
Première idée : la boîte mail est pleine. On ouvre le webmail, quota à 13 %. Deuxième idée : les messages partent en indésirables. Le dossier Pourriels contenait un seul mail, daté de mai. Troisième idée : la redirection vers la page de remerciement casse l’envoi. Sauf que le code se branche sur wpcf7mailsent, un événement qui ne se déclenche justement qu’après un envoi réussi.
Trois hypothèses, trois impasses, une bonne heure perdue. Ce qu’on aurait dû vérifier en premier tient en une question : est-ce que ce site sait encore envoyer un mail ?
Cause n° 1 : la délivrabilité, trois fois sur quatre
Par défaut, WordPress expédie ses notifications avec la fonction mail() de PHP. Le serveur d’hébergement mutualisé fabrique un message brut, sans signature cryptographique, et le pousse vers le monde. Ça fonctionnait très bien en 2015.
Depuis, les deux plus gros opérateurs de messagerie ont refermé la porte. Google exige que tout expéditeur publie au minimum un enregistrement SPF ou DKIM, et impose SPF, DKIM et DMARC réunis au-delà de 5 000 messages par jour vers des adresses Gmail personnelles, avec un taux de plainte pour spam maintenu sous 0,30 % (le seuil de surveillance étant fixé à 0,10 %), selon les directives officielles de Google pour les expéditeurs d’e-mails, entrées en vigueur le 1er février 2024. La clé DKIM doit faire 1 024 bits au minimum, 2 048 étant recommandé. Microsoft a aligné ses règles pour Outlook.com le 5 mai 2025.
La documentation Microsoft est plus directe encore sur le fond du problème. Dans son guide sur le fonctionnement de l’authentification par e-mail dans Microsoft 365, mis à jour le 3 juillet 2026, l’éditeur décrit SPF, DKIM et DMARC comme des briques interdépendantes et prévient que « tout ce qui est inférieur à toutes les méthodes d’authentification par e-mail entraîne une protection inférieure aux normes ». Traduction pour un site vitrine : un message non signé n’est pas mis en indésirables, il est souvent détruit en silence, sans rebond, sans trace.
Le piège qui nous a coûté le plus de temps
Notre domaine avait pourtant du DKIM. Deux sélecteurs bien présents dans le DNS, brevo1 et brevo2. De quoi conclure trop vite que l’authentification était en place.
Elle l’était pour Brevo. Sauf que Brevo n’était branché nulle part sur le site de l’agence. On avait installé ce dispositif chez nos clients, jamais chez nous. Le DNS annonçait donc un expéditeur légitime que personne n’utilisait, pendant que le serveur postait par un canal que le DNS ne couvrait pas. Et comme l’adresse d’expédition était identique à l’adresse de réception, le serveur de destination voyait un message se réclamant de son propre domaine sans pouvoir le vérifier. Le profil exact d’une usurpation.
Trois commandes pour trancher en une minute
dig +short TXT votredomaine.fr | grep spf
dig +short TXT _dmarc.votredomaine.fr
dig +short TXT selecteur._domainkey.votredomaine.frSi la troisième ligne ne renvoie rien pour le service qui expédie réellement vos mails, vous avez votre réponse. Chez nous, le correctif a pris vingt minutes : brancher un vrai relais SMTP authentifié à la place de mail(). Premier message reçu à 23 h 37 le même soir.
Cause n° 2 : votre antispam bloque vos clients
Deuxième scénario, plus vicieux, parce que le formulaire a l’air de fonctionner. Le visiteur remplit, valide, et reçoit un message d’erreur générique. Il repart.
Chez nous, une règle rejetait tout message de moins de 150 caractères ne contenant aucun mot-clé métier. L’intention était bonne. Le problème, c’est que le champ message était facultatif sur le formulaire d’audit. Un prospect pressé qui laissait juste son nom, son numéro et « rappelez-moi » était classé en spam par sa propre concision.
Il existe un signal pour distinguer les deux familles de blocage, et il vaut la peine d’être retenu. Sur Contact Form 7, « Une erreur est survenue lors de l’envoi » signale un rejet antispam. « Un ou plusieurs champs contiennent une erreur » signale un échec de validation. Deux phrases quasi jumelles, deux causes qui n’ont rien à voir. Lire la bonne évite une demi-journée de recherche dans la mauvaise direction.
Autre chose apprise à nos dépens : un module de sécurité déployé en mode observation doit avoir sa date de bascule notée quelque part. Le nôtre est resté onze mois à tout détecter et à tout laisser passer, parce que personne n’avait planifié le passage en mode actif.
Cause n° 3 : le cache statique qui périme le formulaire
Celle-là est spécifique aux sites rapides, et c’est bien ce qui la rend traître. Quand un cache statique sert directement un fichier HTML sans passer par PHP, il sert aussi le jeton de sécurité qui était inscrit dedans au moment de la génération. Ce jeton expire au bout de quelques heures. Le formulaire, lui, reste affiché.
Résultat : le visiteur voit un formulaire normal, le remplit, et reçoit « un ou plusieurs champs contiennent une erreur » alors que tous ses champs sont corrects.
Le correctif consiste à exclure du cache toute page portant un formulaire. Avec une précaution que beaucoup oublient : la directive d’exclusion est appliquée par PHP, alors que le serveur web sert les fichiers déjà présents sur le disque avant même d’appeler PHP. Il faut donc ajouter l’exclusion et supprimer les fichiers déjà en cache. Sinon la page continue de sortir périmée pendant des jours.
Cause n° 4 : une attaque de bots qui sature le serveur
Le 4 septembre au matin, notre administration WordPress renvoyait une erreur 524. Le site public tenait, servi par son cache, un cache qu’on venait justement de remettre en question en auditant nos temps de réponse. Derrière, un script automatisé pilonnait le formulaire de contact et consommait tous les processus PHP disponibles. On a détaillé le déroulé complet de cet incident et les cinq couches de protection à poser dans notre article consacré aux attaques de bots sur un formulaire.
Ce type d’incident n’a plus rien d’exceptionnel. D’après le Bad Bot Report 2025 publié par Imperva, le trafic automatisé a dépassé le trafic humain pour la première fois en dix ans et représente désormais 51 % du trafic web mondial. Les bots malveillants seuls en constituent 37 %, contre 32 % l’année précédente. Le rapport attribue cette accélération à l’arrivée des grands modèles de langage, qui ont rendu l’écriture d’un bot accessible à des attaquants sans compétence technique particulière.
Un point technique vaut d’être signalé, parce qu’il fait perdre beaucoup de temps : derrière un service de protection type Cloudflare, bloquer une adresse IP dans le fichier .htaccess ne sert à rien. Votre serveur ne voit plus l’adresse du visiteur, il voit celle du proxy. Le filtrage doit porter sur l’en-tête CF-Connecting-IP, ou se faire directement au niveau du pare-feu applicatif, en amont.
Le tableau de diagnostic
| Symptôme observé | Cause la plus probable | Test à faire en premier |
|---|---|---|
| Page de remerciement affichée, aucun mail reçu | Délivrabilité | Vérifier la présence d’un relais SMTP authentifié, puis dig sur SPF, DKIM et DMARC |
| « Une erreur est survenue lors de l’envoi » | Antispam | Lire le journal du module de sécurité, tester un envoi depuis une autre connexion |
| « Un ou plusieurs champs contiennent une erreur » sur un formulaire correct | Cache | Recharger la page avec un paramètre aléatoire dans l’URL, puis réessayer |
| Administration lente ou erreur 5xx, site public normal | Attaque | Compter les soumissions du jour, activer une limite de débit sur l’URL du formulaire |
« On a passé une heure sur le quota de la boîte mail et sur le dossier indésirables. La vraie question tenait en une ligne : est-ce que ce site a un service d’envoi authentifié, oui ou non ? Sur les sites qu’on récupère en audit, la réponse est non trois fois sur quatre. »
Ce que coûte un formulaire muet
La perte évidente, ce sont les demandes qui n’arrivent jamais. Il y en a une autre, moins visible, qu’on a mesurée sur notre propre compte.
Pendant la même période, une campagne publicitaire tournait vers la page de contact. Sept jours de diffusion, 47,90 $ dépensés, zéro conversion enregistrée. Pas parce que personne ne remplissait le formulaire, mais parce que les demandes se volatilisaient avant d’atteindre la boîte de réception. L’outil publicitaire, lui, en a déduit que les mots-clés ne convertissaient pas, et a réduit leur diffusion. Un formulaire cassé ne fait pas que perdre des prospects : il apprend à l’algorithme que votre campagne ne fonctionne pas.
La routine à faire tous les mois
Elle prend cinq minutes et évite tout ce qui précède.
- Remplir votre propre formulaire depuis une adresse Gmail extérieure, puis depuis une adresse Outlook. Les deux opérateurs n’appliquent pas les mêmes règles.
- Vérifier que le mail arrive en boîte principale, pas en indésirables.
- Lancer les trois commandes
digci-dessus après tout changement d’hébergeur, de DNS ou de service d’emailing. - Regarder le nombre de soumissions du mois. Une chute brutale sans changement de trafic n’est jamais un hasard.
Un dernier conseil qui vaut pour les quatre causes : testez toujours en navigation privée et déconnecté de l’administration. Un compte administrateur contourne la plupart des filtres de sécurité, donc vous verrez un formulaire qui marche pendant que vos visiteurs se heurtent à un mur.
Votre formulaire fonctionne vraiment ?
On teste la chaîne complète : envoi, authentification du domaine, filtres antispam, cache. Vous recevez le rapport sous 48 heures ouvrées, sans engagement.
Sources et références
- Google, Directives pour les expéditeurs d’e-mails, Google Workspace Admin Help, en vigueur depuis le 1er février 2024.
- Microsoft, Fonctionnement de l’authentification par e-mail dans Microsoft 365, Microsoft Learn, mis à jour le 3 juillet 2026.
- Imperva (groupe Thales), 2025 Bad Bot Report, 2025.
Jean Fagnon est le fondateur de Kefa Global Network, agence web installée en France qui conçoit et maintient des sites pour des TPE, des PME et des cabinets libéraux. Les incidents décrits dans cet article ont été relevés et corrigés sur le site de l’agence dans la nuit du 4 au 5 septembre 2026.
Publié le 5 septembre 2026.