Defaults.Exposed › Corrections › Guides

E-mails du formulaire de contact en spam — corriger l'expéditeur serveur web (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Les e-mails de formulaire de contact et de site web atterrissent en spam parce que votre serveur web les envoie sans authentification — aucune autorisation SPF, aucune signature DKIM. Le correctif fiable consiste à faire transiter ce courrier par un SMTP authentifié, pas à mettre le serveur en liste blanche. 46,4 % des 261 086 232 domaines évalués dans le recensement Defaults.Exposed (données au 2026-06-29) ne publient aucun enregistrement SPF.

L’ordre de correction compte, et la plupart des tutoriels le prennent à l’envers. Lancez un scan gratuit pour voir ce que votre domaine publie réellement ; faites transiter le courrier du site par un SMTP authentifié (votre prestataire de messagerie ou un service d’e-mail transactionnel) pour qu’il reçoive une vraie signature DKIM ; corrigez l’adresse From du formulaire ; et n’ajoutez l’IP du serveur à SPF qu’en tout dernier recours.

Pourquoi les e-mails envoyés depuis mon site partent-ils en spam ?

À cause de qui les envoie réellement. Quand un visiteur soumet votre formulaire de contact, l’e-mail n’est pas envoyé par votre prestataire de messagerie — le serveur web le génère lui-même, généralement via le mail() de PHP. Vu du côté réception, ce message :

• provient d’une IP que votre enregistrement SPF n’autorise pas (votre SPF couvre votre prestataire de messagerie, pas votre hébergeur web) ;
• ne porte aucune signature DKIM, donc rien ne le rattache cryptographiquement à votre domaine ;
• part souvent d’une IP d’hébergement mutualisé dont la réputation est faite par les sites de centaines d’inconnus.

Du courrier non authentifié depuis une IP à la réputation composite, c’est exactement ce que les filtres antispam existent pour attraper — Gmail et Outlook voient un serveur quelconque prétendre être vous. Le tableau d’ensemble est sombre : 46,4 % des domaines ne publient aucun SPF, et seuls 10,59 % (27 640 987 des 261 086 232 domaines évalués, recensement au 2026-06-29) appliquent une politique DMARC contraignante.

Pourquoi cela touche-t-il particulièrement les sites WordPress ?

WordPress envoie tous ses e-mails — notifications de formulaire, réinitialisations de mot de passe, confirmations de commande — via une seule fonction, wp_mail(), qui enrobe par défaut le mail() de PHP sur le serveur web. Tout site WordPress qui n’a pas été délibérément reconfiguré est, d’origine, un expéditeur non authentifié. Les plugins de formulaire (Contact Form 7, WPForms, Gravity Forms) confient tous le courrier à la même fonction : cela ressemble à un problème de plugin, mais c’est un problème de transport.

Le correctif n’est pas un autre plugin de formulaire mais un plugin SMTP (WP Mail SMTP et ses équivalents), qui réachemine tout ce que wp_mail() envoie vers un vrai compte de messagerie authentifié — une infrastructure que votre SPF autorise déjà, avec une signature DKIM en prime.

Quelle méthode d’envoi le site doit-il utiliser ?

Pour quelques notifications par jour, le SMTP via la messagerie que vous payez déjà est le chemin le plus court ; à vrai volume, un service transactionnel est fait pour ça. Les deux vous donnent DKIM — le raccourci de la liste blanche d’IP ne le donne jamais.

Comment corriger la délivrabilité des e-mails du formulaire de contact ?

1. Lancez le scan gratuit sur defaults.exposed avant de toucher à quoi que ce soit. Il montre ce que votre domaine publie réellement en SPF, DKIM et DMARC — que vous ayez à corriger le transport du formulaire, un enregistrement manquant, ou les deux. Aucun SPF du tout ? Commencez par comment corriger SPF.
2. Créez une identité SMTP dédiée pour le site — par exemple [email protected] chez votre prestataire de messagerie, ou un domaine d’envoi vérifié dans un service transactionnel. Utilisez un mot de passe d’application ou une clé API que vous pouvez révoquer, pas le mot de passe de la boîte d’une personne.
3. Faites transiter le courrier du site par cette identité. WordPress : installez un plugin SMTP et pointez-le vers ce compte. Autres piles techniques : configurez le mailer du framework au lieu du mail() local.
4. Corrigez l’adresse From (l’anti-modèle ci-dessous) : From doit être votre propre domaine ; le visiteur va dans Reply-To.
5. Si l’expéditeur est un service transactionnel, ajoutez ses enregistrements DKIM (généralement une paire de CNAME) pour que le courrier soit signé avec votre domaine — les étapes DNS reprennent celles des pas-à-pas de configuration SPF.
6. Envoyez une soumission de test et relancez le scan. Les en-têtes doivent montrer spf=pass et dkim=pass pour votre domaine ; corrigez ensuite tout ce que le scan signale d’autre via corriger SPF et corriger DKIM.

Pourquoi le formulaire envoie-t-il « depuis » l’adresse e-mail du visiteur ?

La blessure auto-infligée la plus courante en configuration de formulaire, et beaucoup de plugins le faisaient par défaut : la notification arrive From : l’adresse du visiteur, pour pouvoir répondre d’un clic. C’est commode en apparence, et c’est de la falsification. Votre serveur n’a aucun droit d’envoyer du courrier en tant que [email protected] — il échoue à SPF et DKIM pour gmail.com, et la politique DMARC de Gmail dit aux serveurs de réception de le mettre en indésirable ou de le rejeter. Le correctif ne coûte rien :

• From : une adresse de votre propre domaine (l’identité SMTP de l’étape 2)
• Reply-To : l’adresse du visiteur — la réponse lui parvient toujours directement

Tous les plugins de formulaire grand public le permettent ; ce sont deux champs dans les réglages de notification.

Pourquoi ne pas simplement ajouter l’IP du serveur à mon enregistrement SPF ?

C’est le correctif que la plupart des fils de forum dégainent en premier, et ce n’est pas pour rien qu’il n’est qu’une solution de repli. Ajouter ip4:<server> (ou un mécanisme a pour votre hébergeur web) à SPF fait effectivement passer le test brut — mais :

• Sur un hébergement mutualisé, cela autorise des inconnus. L’IP appartient à la machine, pas à vous ; tous les autres sites de ce serveur peuvent désormais envoyer du courrier passant SPF au nom de votre domaine.
• Cela casse silencieusement. Les hébergeurs migrent leurs serveurs et changent d’IP sans vous prévenir ; votre SPF continue d’autoriser une adresse que vous avez quittée depuis des mois.
• Cela ne vous donne aucun DKIM. SPF seul casse au transfert et ne peut pas vous mener vers l’application stricte de DMARC comme une signature le peut.

Réservez cette voie au cas véritablement contraint : un serveur dédié avec une IP statique que vous contrôlez et une application incapable de parler SMTP — et associez-y une signature DKIM sur la machine si vous le pouvez.

SPF vérifie-t-il seulement l’adresse que mon formulaire met dans « From » ?

Non — et cela fait trébucher la moitié des diagnostics maison. Les serveurs de réception évaluent SPF sur le domaine du Return-Path (RFC5321.MailFrom), pas sur l’en-tête From. Les serveurs web tamponnent souvent leur propre nom d’hôte dans le Return-Path, si bien que votre enregistrement SPF n’a jamais été consulté — le serveur de réception a vérifié SPF pour srv0421.examplehost.com. Le SMTP authentifié corrige cela aussi : le Return-Path devient votre domaine, et le pass SPF compte enfin pour vous. C’est aussi pourquoi DKIM compte — l’alignement DMARC exige un pass rattaché au domaine du From, et une signature DKIM voyage avec le message.

Questions fréquentes

Un plugin SMTP corrigera-t-il aussi les e-mails de réinitialisation de mot de passe et de WooCommerce ? Oui. Sur WordPress, tout passe par wp_mail() : le réacheminer corrige d’un coup les notifications de formulaire, les réinitialisations de mot de passe et les e-mails de commande.

Ai-je encore besoin d’enregistrements SPF et DKIM si j’utilise un plugin SMTP ? Oui — le plugin change quelle infrastructure envoie votre courrier ; les enregistrements sont ce qui l’autorise. Si votre domaine fait partie des 46,4 % des 261 086 232 domaines évalués sans enregistrement SPF (recensement, 2026-06-29), le SMTP authentifié seul ne vous sauvera pas. La check-list e-mail du nouveau domaine couvre le jeu complet d’enregistrements.

Mes e-mails de formulaire passent SPF mais échouent encore à DMARC — pourquoi ? Presque toujours l’anti-modèle d’usurpation du From ci-dessus, ou un SPF qui passe pour le domaine Return-Path de l’hébergeur plutôt que le vôtre. Corrigez d’abord From/Reply-To ; si l’échec persiste, la pièce manquante est une signature DKIM alignée — voir « DKIM signature not valid ». Si des outils SaaS au-delà du site échouent aussi, le guide SPF en échec pour vos outils SaaS couvre l’ordre de correction.

Tout cela en vaut-il la peine pour un formulaire de contact à faible trafic ? Le formulaire est généralement là où l’argent entre — une demande manquée est un client dont vous n’avez jamais su que vous l’aviez perdu. Et le correctif est gratuit ; l’obstacle, c’était de savoir que le serveur web était depuis le début l’expéditeur non authentifié.

Envoyez le rapport au propriétaire

Si vous êtes le développeur ou le prestataire qui corrige cela : une fois la soumission de test passée, relancez le scan gratuit et transmettez le rapport noté au propriétaire du site — une trace datée, en langage clair, que le domaine s’authentifie correctement, et la pièce dont il aura besoin au prochain renouvellement de cyberassurance ou questionnaire de sécurité client. Si vous êtes le propriétaire et lisez ceci parce que les demandes ont cessé d’arriver : envoyez cette page et votre rapport de scan à la personne qui gère votre site — un chantier d’un après-midi, avec un avant/après qu’elle pourra vous montrer.

Vérifiez votre domaine → · SPF en échec pour vos outils SaaS ? → · Corriger SPF → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.