Partir d’un message reçu plutôt que d’une promesse d’envoi
Une notification du site est bien arrivée, mais dans les indésirables. La demande de récupération, le formulaire ou la commande a donc produit au moins ce message-là. Le travail consiste maintenant à comprendre son classement. Refaire tout le formulaire ou installer plusieurs extensions SMTP peut déplacer le problème sans modifier la décision de la messagerie destinataire.
Le résultat recherché est la réception normale des prochains messages légitimes du même flux. Une seule boîte peut appliquer un blocage personnel, tandis que plusieurs destinataires peuvent rencontrer un défaut commun d’expédition. Ces deux situations n’appellent pas la même correction. Un courrier déplacé manuellement vers la réception ne prouve pas encore que les suivants y arriveront spontanément.
Commencez sans ajouter d’extension. Retrouvez un message récent et authentique dont vous connaissez l’origine, puis notez le type de notification, l’heure, le destinataire et le domaine d’expéditeur. Gardez son original dans un espace privé : les en-têtes peuvent révéler des adresses ou des informations techniques, et le corps peut contenir des données de compte ou de commande.
Ce parcours s’applique aux courriers effectivement reçus. Si aucun message n’existe, reprenez le diagnostic de génération et de transport. Sur WordPress.com ou avec un service d’envoi géré par l’hébergement, certains réglages appartiennent à la plateforme. Dans un réseau multisite, identifiez le site et l’identité d’envoi concernés avant de changer une valeur partagée. Une réparation ciblée doit préserver les autres usages du même domaine.
Délimiter le flux et la boîte qui classent le message
Demandez à l’équipe si le classement touche une personne, un fournisseur de messagerie ou plusieurs boîtes indépendantes. Utilisez seulement des boîtes témoins que vous contrôlez pour une comparaison. Un essai direct vers chacune est plus lisible qu’un message transféré d’une boîte à l’autre, car un transfert ajoute un intermédiaire au parcours. Ne créez pas une série d’envois vers des clients pour mesurer le problème.
Comparez également les types de notification. Si seul le formulaire contient une adresse d’expéditeur différente, sa configuration est une piste prioritaire. Si tous les courriers provenant du même transport sont concernés, examinez l’identité et le service d’envoi communs. Une campagne commerciale classée en spam ne permet pas de conclure que tous les liens de récupération ont le même défaut.
Pour chaque message témoin, relevez l’expéditeur réel en ouvrant ses détails. Le nom affiché, par exemple celui de votre entreprise, peut masquer une adresse technique ou une adresse appartenant au visiteur. Cherchez aussi l’avertissement expliquant le classement lorsqu’il est proposé par la messagerie. Conservez ses termes exacts ; les reformuler en « SMTP défaillant » ferait perdre une information utile.
Cette collecte ne change aucun réglage. Elle doit aboutir à un périmètre : boîte personnelle, notification particulière ou transport commun. Gardez un message antérieur à la correction pour comparer ensuite ses en-têtes avec ceux du nouvel essai. N’utilisez pas un lien de récupération ancien comme message à transférer pour diagnostic ; un relevé technique minimal suffit.
Approche 1 : corriger le classement dans une boîte Gmail
Cette voie convient quand une boîte classe seule les courriels légitimes du site. Dans Gmail sur ordinateur, ouvrez Plus → Spam, sélectionnez le message vérifié puis cliquez sur Non-spam. Contrôlez l’adresse complète avant cette action, surtout si un avertissement signale une possible usurpation. Le nom du site ne suffit pas à reconnaître son courrier.
Consultez ensuite Paramètres → Afficher tous les paramètres → Filtres et adresses bloquées. Recherchez un blocage accidentel de l’adresse et les filtres qui correspondent à ce message. Notez leurs critères et leurs actions avant de modifier uniquement la règle responsable. Une règle d’archivage peut masquer un message sans l’avoir classé en spam ; distinguez les deux résultats.
Après correction, demandez une nouvelle notification témoin du même type. Le résultat attendu est son arrivée dans la réception de cette boîte. Pour annuler une modification de filtre, remettez les critères et actions relevés dans le même écran. Cette intervention ne change pas le classement des autres destinataires : si le problème reste général, poursuivez le parcours d’expédition plutôt que de demander à chaque utilisateur de créer une exception.
Appliquer la même correction limitée dans Outlook sur le web
Avec Outlook sur le web, ouvrez Paramètres → Courrier → Courrier indésirable. Dans Expéditeurs et domaines bloqués, recherchez une entrée concernant l’adresse du site et retirez-la seulement si elle a été bloquée par erreur. Relevez l’entrée initiale afin de pouvoir la remettre. Les menus d’une ancienne application Outlook peuvent différer ; utilisez ici l’interface web du compte concerné.
Si l’expéditeur est identifié et que cette boîte doit recevoir ses notifications, ajoutez son adresse exacte à Expéditeurs et domaines approuvés, puis enregistrez. Préférez l’adresse concernée à une autorisation de domaine très large. Cela reste une décision locale de réception, dont la portée dépend aussi des protections de l’organisation.
Envoyez une nouvelle notification témoin et constatez son dossier d’arrivée. Pour annuler l’exception, revenez dans cette liste, sélectionnez l’entrée ajoutée et retirez-la. Ne désactivez pas tout le filtrage du compte. Si une politique de l’organisation ou une quarantaine intervient, son administrateur doit examiner le message et la règle précise : une exception personnelle ne corrige pas nécessairement ce niveau de protection.
Lire l’original et les résultats d’authentification
Dans Gmail sur ordinateur, ouvrez le message, puis le menu Plus situé à côté de Répondre et choisissez Afficher l’original. Gardez cette vue privée. Relevez les résultats SPF, DKIM et DMARC présentés par la messagerie destinataire, avec les domaines concernés. Sur une autre messagerie, utilisez sa fonction d’affichage de la source ou des en-têtes complets ; ne vous contentez pas de recopier le nom visible de l’expéditeur.
SPF vérifie si le serveur d’envoi est autorisé pour le domaine utilisé dans l’enveloppe technique du courrier. Ce domaine peut différer de celui affiché dans From. DKIM vérifie une signature associée à un domaine, indiqué notamment par le paramètre d de DKIM-Signature. Un résultat positif est utile, mais il faut encore savoir quel domaine a été authentifié.
DMARC relie l’identité visible à un domaine authentifié compatible selon sa règle d’alignement. Un succès SPF ou DKIM pour un domaine quelconque ne démontre donc pas automatiquement cet alignement. Utilisez en priorité l’évaluation produite par le service qui reçoit réellement votre courrier, plutôt qu’un résultat ancien ajouté par un intermédiaire inconnu.
Le résultat attendu de cette lecture est une observation simple : authentification absente, en échec, incohérente avec l’expéditeur, ou réussie. Ce n’est pas une note générale de qualité du message. Un courrier authentifié peut encore être classé en spam pour d’autres raisons.
Distinguer défaut d’authentification et effet d’un transfert
Comparez un message envoyé directement à la boîte témoin avec celui qui passe par un alias ou un transfert. Le transfert peut modifier le serveur observé par SPF ; une transformation du contenu peut aussi affecter une signature DKIM. L’échec constaté après cet intermédiaire ne démontre pas à lui seul que le serveur WordPress initial a utilisé de mauvais identifiants.
Si la copie directe réussit l’authentification mais pas la copie transférée, examinez la chaîne de transfert avec l’administrateur de messagerie. Ne changez pas immédiatement l’expéditeur du site pour compenser ce seul parcours. Gardez l’adresse d’envoi stable pendant la comparaison et relevez les domaines qui passent ou échouent dans chaque original.
Si le message direct échoue lui aussi, corrigez d’abord le service réellement employé par le site : adresse autorisée, signature active et configuration de domaine propre à ce service. Le changement doit être validé sur un nouveau message, car un courrier déjà reçu conserve ses anciens en-têtes. Une capture d’un réglage déclaré valide ne remplace pas cette vérification.
Évitez de supprimer la politique DMARC du domaine pour faire disparaître un avertissement. Elle protège aussi les autres usages de l’adresse et ne crée ni autorisation SPF ni signature DKIM. Le parcours détaillé d’alignement de l’expéditeur est approprié si les domaines ne correspondent pas ; ici, le contrôle sert à choisir cette réparation plutôt qu’une simple exception de réception.
Approche 2 : remettre une identité d’envoi autorisée sur le site
Cette voie convient lorsqu’un message direct montre une identité d’expéditeur erronée ou une authentification qui ne correspond pas au service configuré. Utilisez l’extension de transport déjà active, avec un accès administrateur et les informations du fournisseur. N’ajoutez pas un deuxième transport pour améliorer une prétendue note de délivrabilité. Un outil SMTP sait remettre le courrier à un service ; il ne commande pas le classement de toutes les boîtes.
Avec WP Mail SMTP déjà présent, ouvrez WP Mail SMTP → Settings → General et relevez From Email, From Name ainsi que l’état de Force From Email. Comparez l’adresse avec celle autorisée dans votre service. Si elle a été remplacée par une ancienne adresse ou celle d’un visiteur, corrigez-la puis enregistrez. N’activez Force From Email qu’après avoir accepté sa portée sur les autres notifications concernées par le transport.
Au contrôle du 3 novembre 2026, WP Mail SMTP by WPForms est proposé en version 4.10.3, attribué à Syed Balkhi, avec WordPress 5.5 et PHP 7.4 minimum et une compatibilité déclarée jusqu’à WordPress 7.1.4. L’exemple concerne ses réglages existants ; il ne promet aucune fonction payante de journal ni de contrôle du classement.
Déclenchez une notification témoin et relisez son original. Le résultat attendu est une adresse effective autorisée et une authentification cohérente, puis une observation de son dossier d’arrivée. Si l’extension change une adresse attendue ailleurs, rétablissez les valeurs relevées dans le même écran. Une correction de DNS, si elle reste nécessaire, doit reprendre les noms et valeurs fournis pour votre compte, avec sauvegarde des enregistrements concernés : il n’existe pas de ligne SPF ou de clé DKIM universelle à copier ici.
Corriger le modèle d’une notification particulière
Si un seul formulaire est concerné, ouvrez ses réglages de notification avant de modifier le transport global. Avec Contact Form 7 déjà utilisé, Contact → Formulaires de contact → votre formulaire → Mail permet d’examiner From, Subject et Message body. Conservez une copie du modèle. Dans From, employez l’adresse autorisée du site ; l’adresse saisie par le visiteur peut servir de Reply-To lorsque le champ correspondant est correctement configuré.
Relisez le corps comme un destinataire : doit-il comprendre pourquoi ce message lui arrive, de quel site il provient et quelle action est attendue ? Corrigez un lien pointant vers un ancien domaine ou un texte resté en démonstration. Vérifiez la destination réelle des liens au lieu de changer seulement leur libellé. Ne remplacez pas un contenu légitime par une série de mots supposés contourner le filtre.
Pour isoler un problème de modèle, utilisez un message témoin simple sans donnée client, puis réintroduisez seulement les éléments nécessaires, par exemple la pièce jointe prévue. Comparez les résultats sur la même boîte et le même transport. Cette comparaison peut orienter le diagnostic ; elle ne permet pas d’attribuer une décision de spam à un mot précis sans autre preuve.
La version actuelle de Contact Form 7 examinée est 6.2.4.1 par Rock Lobster Inc., compatible déclarée jusqu’à WordPress 7.1.4 et exigeant WordPress 7.1/PHP 8.3. Il s’agit d’un exemple pour l’outil déjà installé. Après chaque correction, vérifiez le vrai message reçu. Pour revenir en arrière, remettez le modèle sauvegardé, sans restaurer toute la base du site.
Réduire les envois indésirables produits par le site
Même avec une identité correcte, le site peut générer un flux que les destinataires n’attendent pas. Examinez les notifications réellement actives, les destinataires et leur fréquence à partir des réglages du composant qui les produit. Un accusé de réception peut partir vers une adresse librement saisie par un visiteur ; un formulaire abusé peut alors expédier des messages à des personnes qui n’ont rien demandé.
Avec Contact Form 7, inspectez Use Mail (2) dans le modèle de courrier. S’il n’existe aucun besoin d’accusé et que cet envoi a été activé par erreur, notez son état, désactivez uniquement cette option et enregistrez. Vérifiez que la notification principale vers l’équipe continue d’arriver. Pour annuler, rétablissez le second modèle et son activation initiale. Si l’accusé est nécessaire, traitez la protection et les règles de destination du formulaire plutôt que de l’ouvrir à tous les envois.
Séparez aussi les notifications indispensables du site et les campagnes commerciales. Une personne qui demande un lien de récupération n’a pas pour autant demandé une série de promotions. Utilisez les fonctions d’abonnement et de désabonnement du système de campagne concerné ; ne fabriquez pas un faux lien de désabonnement dans une notification transactionnelle pour lui donner l’apparence d’un autre type de courrier.
Si le volume augmente sans explication, identifiez la source avant de reprendre les envois massifs : formulaire, automatisme, compte ou intégration. Changer de domaine à répétition ne supprime pas cette source. Conservez les notifications nécessaires et suspendez seulement le flux dont l’abus ou la configuration erronée est établi.
Vérifier les nouveaux messages sans multiplier les essais
Après une modification, refaites le même scénario avec le même destinataire témoin. Comparez l’adresse effective, les résultats d’authentification et le dossier d’arrivée du nouveau message avec l’original conservé. Si vous avez corrigé une règle personnelle, le résultat concerne cette boîte. Si vous avez corrigé l’expédition commune, utilisez ensuite une autre boîte contrôlée, sans exception locale, pour observer un autre parcours.
Un message ancien déplacé en réception ne change pas ses résultats d’authentification. De même, une ancienne conversation peut être classée différemment d’un nouveau sujet. Notez ce qui a réellement été testé au lieu de conclure à une réparation universelle. N’envoyez pas des dizaines de demandes de mot de passe pour obtenir un résultat statistique : elles créeraient des liens inutiles et brouilleraient la chronologie.
La réputation d’un domaine ou d’une adresse d’envoi peut dépendre d’un historique et de l’infrastructure du fournisseur, y compris d’une adresse IP partagée. Un nouvel essai ne permet pas de mesurer cet historique. Si l’identité est désormais correcte mais que plusieurs boîtes classent encore les messages, poursuivez avec le fournisseur sur les raisons observables, plutôt qu’avec une succession de réglages sans lien avec les preuves.
Le résultat documenté peut être partiel : authentification réparée, réception correcte dans une boîte, classement encore défavorable dans une autre. Cette précision aide à poursuivre le bon sujet sans annuler une correction utile.
Transmettre les bons éléments et conserver les corrections utiles
Préparez un relevé bref pour la personne qui gère la messagerie : type de notification, domaine visible, service d’envoi, heure avec fuseau, boîte concernée et résultats observés dans le message direct. Si un transfert intervient, signalez-le. Partagez l’original complet seulement dans un canal privé adapté, après vérification des données qu’il contient. Un lien de récupération ou une référence personnelle n’a pas à être rendu public pour expliquer le classement.
Demandez une vérification du domaine d’authentification, de l’infrastructure ou du statut de réputation correspondant au cas observé. La conclusion « WordPress envoie mal » est trop large si un seul modèle porte un expéditeur incorrect. À l’inverse, autoriser l’adresse dans votre boîte ne résout pas une signature manquante pour l’ensemble des destinataires.
Gardez dans votre suivi les valeurs initiales, la correction retenue et son périmètre. Une configuration stable et compréhensible permet de repérer la prochaine modification qui casse le parcours.
- Une seule boîte est corrigée : conserver la portée locale de la conclusion.
- L’authentification du message direct échoue : réparer l’expéditeur et le service concerné.
- L’authentification réussit mais le classement reste défavorable : examiner le flux, le contenu utile et les informations du fournisseur.
- Le transfert seul pose problème : faire examiner cette chaîne sans réécrire l’identité du site.
- Les notifications attendues arrivent normalement : fermer les diagnostics temporaires et conserver le relevé de contrôle.
Exercice sur en-têtes synthétiques avec SPF non aligné
Repérez d’abord le domaine dans From et le nom du service de réception qui a produit Authentication-Results. Dans un message réel, utilisez les résultats présentés par votre boîte ou par son outil d’administration. Plusieurs lignes peuvent apparaître lors d’un transfert et le nom d’un service dans une ligne ne suffit pas à établir sa provenance.
Dans cet exemple, SPF réussit pour relai.test, le domaine d’enveloppe indiqué par smtp.mailfrom. Le domaine visible est atelier.test. Les deux domaines sont distincts et l’exemple ne contient pas de résultat DKIM exploitable. Si vous lisez le même motif sur une notification réelle, relevez d’abord le service qui expédie ce flux et demandez-lui comment activer une signature DKIM sur votre domaine ou faire correspondre le domaine d’enveloppe au domaine visible.
From: Site de test <site@atelier.test>
Authentication-Results: reception.test;
spf=pass smtp.mailfrom=relai.test;
dkim=none;
dmarc=fail header.from=atelier.testExercice sur en-têtes synthétiques avec DKIM aligné
Dans le second exemple, l’enveloppe SPF est identique. Recherchez header.d et comparez-le à header.from.
La signature DKIM validée utilise ici le même domaine que le From. Cela explique dmarc=pass malgré le domaine différent côté SPF. Si vous trouvez ce résultat sur un message réel et qu’il arrive encore en indésirables, comparez un témoin du même flux dans une deuxième boîte de test, puis regardez les filtres locaux et les traces du fournisseur. Si l’original ne présente aucun résultat de confiance, transmettez l’heure, l’objet témoin et l’identifiant du message à votre service de messagerie.
Ces deux extraits ont été construits avec des domaines fictifs puis relus hors ligne. Une réponse SMTP 250 décrit une acceptation par le serveur qui l’a renvoyée. Pour établir le classement réel, relevez le dossier où le témoin apparaît et consultez l’original fourni par la boîte de réception.
From: Site de test <site@atelier.test>
Authentication-Results: reception.test;
spf=pass smtp.mailfrom=relai.test;
dkim=pass header.d=atelier.test;
dmarc=pass header.from=atelier.test
