Tel quel, WordPress confie chaque message à la fonction mail() de PHP, qui ne signe rien, n’authentifie rien et annonce un succès que le courrier soit remis ou non. C’est pour cela que les réinitialisations de mot de passe, les notifications de formulaire de contact et les e-mails de commande WooCommerce finissent dans les spams, quand ils ne disparaissent pas purement et simplement. Ce guide couvre ce que fait réellement wp_mail(), pourquoi l’adresse From wordpress@ par défaut casse l’alignement, quels hébergeurs bloquent quels ports SMTP, et comment tester un envoi réel avec Unspam.
Le cœur de WordPress ne configure jamais DKIM. La bibliothèque PHPMailer qu’il embarque sait pourtant signer et expose DKIM_domain, DKIM_selector et DKIM_private, mais rien dans le cœur ne renseigne jamais ces propriétés : le message quitte donc votre serveur sans la moindre signature.
Quand aucun en-tête From n’est fourni, wp_mail() en fabrique un à partir de l’hôte du site : il lit l’hôte via network_home_url(), retire un www. initial, puis préfixe wordpress@. Le nom d’expéditeur affiché est WordPress par défaut. Réinitialisations de mot de passe, notifications de nouvel utilisateur, courrier de modération des commentaires et avis de mise à jour du cœur partent tous sous cette adresse, et sur la plupart des sites aucune boîte n’existe derrière : réponses et bounces n’arrivent donc nulle part. Définissez une vraie adresse avec le filtre wp_mail_from, ou dans WP Mail SMTP sous WP Mail SMTP > Settings avec le champ From Email et l’option Force From Email cochée.
Avec PHP mail(), l’adresse d’enveloppe est celle que produit la configuration de votre hébergeur, en général l’utilisateur du serveur web au nom d’hôte du serveur lui-même. Les serveurs de réception évaluent SPF face à ce domaine d’enveloppe : à moins que votre hébergeur n’impose une adresse d’enveloppe sur votre propre domaine (par le sendmail_from de PHP, par mail.force_extra_parameters, ou par une réécriture dans son propre MTA), ce n’est pas votre enregistrement SPF qui est consulté, et SPF ne peut pas s’aligner sur le domaine From pour DMARC.
Les hébergeurs bloquent le SMTP sortant pour contenir le spam, et les règles diffèrent d’une plateforme à l’autre. Kinsta indique que le port 25 est inutilisable parce que son infrastructure bloque le port 25 sortant, et cite 587, 465 et 2525 comme utilisables, tandis que WP Engine indique que ses fournisseurs d’infrastructure n’autorisent pas le courrier sur le port 25, autorise 587 et 465, et recommande 2525. DigitalOcean bloque par défaut 25, 465 et 587 sur les Droplets, y compris le trafic passant par une Reserved IP, Google Cloud bloque le port 25 vers les destinations situées hors de votre VPC, et AWS limite le port 25 depuis EC2 tant que vous n’en demandez pas la levée. Notez que le récapitulatif des hébergeurs publié par WP Mail SMTP range WP Engine et Kinsta parmi les hébergeurs qui ne bloquent pas le SMTP, ce qui contredit ce que ces deux hébergeurs publient sur le port 25 : fiez-vous à la documentation de votre hébergeur plutôt qu’à une liste tierce.
La configuration la plus répandue place l’adresse du visiteur dans le champ From pour que la réponse soit facile. Autrement dit, votre serveur envoie du courrier qui se déclare venir de gmail.com ou d’outlook.com, un domaine qui n’a jamais autorisé votre serveur, et DMARC échoue sur le domaine du visiteur plutôt que sur le vôtre. La documentation de WPForms le dit elle-même : le From Email doit être valide, il doit correspondre à votre domaine, et il faut éviter d’y mettre l’adresse de la personne qui remplit le formulaire, parce que cela peut ressembler à une tentative d’hameçonnage ; son adresse a sa place dans le Reply-To, via un smart tag. WooCommerce dit exactement la même chose du courrier de commande : une adresse From sur un domaine grand public comme @gmail.com ou @yahoo.com a toutes les chances d’être classée en spam ou bloquée, à cause de l’écart entre l’expéditeur déclaré et l’expéditeur réel.
En hébergement mutualisé, PHP mail() sort par une IP utilisée par des centaines de sites voisins, et une seule installation WordPress compromise sur cette machine peut faire inscrire l’IP entière sur une liste noire. Vous ne maîtrisez ni la réputation de cette IP ni, le plus souvent, son DNS inverse, alors que les règles de Google exigent des IP d’envoi qu’elles aient des enregistrements DNS directs et inverses valides. Passer par un prestataire vous déplace sur une infrastructure dont quelqu’un est payé pour défendre la réputation. En attendant, relevez l’IP d’envoi dans les en-têtes Received d’un message réellement parti de votre site et passez-la dans le contrôle de listes noires d’Unspam, qui interroge les listes à la demande, pour voir si le voisinage vous a déjà coûté cher.
WordPress ne publie aucun enregistrement DNS à votre place et ne signe rien : il n’existe donc aucune identité d’envoi à authentifier tant que vous n’avez pas changé la façon dont le courrier quitte le site. Corrigez d’abord la route, ensuite les enregistrements, dans cet ordre : des enregistrements SPF et DKIM ne servent à rien tant que le message sort par PHP mail() avec l’adresse d’enveloppe de votre hébergeur.
| enregistrement | par défaut | le problème | la solution |
|---|---|---|---|
| Sending route (SMTP plugin) | wp_mail() appelle isMail() de PHPMailer : chaque message passe donc par la fonction mail() de PHP et par le MTA local de votre hébergeur. | Rien ne signe le message et personne ne possède l’adresse d’enveloppe : il n’y a donc aucune identité à laquelle SPF, DKIM ou DMARC puissent se rattacher. | La version gratuite de WP Mail SMTP couvre SendLayer, SMTP.com, Brevo, Gmail, Elastic Email, Mailgun, Mailjet, SendGrid, Postmark, SparkPost, SMTP2GO et Other SMTP, tandis que Microsoft, Amazon SES et Zoho sont marqués Pro. |
| SPF | Absent, ou sans effet : avec PHP mail(), l’expéditeur d’enveloppe est choisi par votre hébergeur, donc ce n’est pas votre enregistrement SPF qui est contrôlé. | Les serveurs de réception interrogent le SPF du domaine d’enveloppe, c’est-à-dire le nom d’hôte de votre serveur : votre enregistrement ne peut donc ni passer ni s’aligner sur le domaine From pour DMARC. | Une fois l’enveloppe confiée à un prestataire, publiez l’include qu’il documente, dans un enregistrement unique sur le domaine d’envoi, par exemple v=spf1 include:_spf.google.com ~all pour Google Workspace. Un seul enregistrement SPF par domaine, sans exception. |
| DKIM | Aucune signature, d’aucune sorte. Le cœur embarque un PHPMailer capable de signer, mais rien dans WordPress ne renseigne jamais ses propriétés de signature DKIM. | Google demande à tous les expéditeurs SPF ou DKIM, et aux expéditeurs en masse (5 000 messages par jour ou plus vers Gmail) les deux, plus l’alignement. Un courrier non authentifié peut être classé en spam ou rejeté avec une erreur 5.7.26. | Publiez les enregistrements CNAME ou TXT de sélecteur que fournit le service d’envoi choisi, puis vérifiez sur un envoi réel que le domaine d= de DKIM est bien le vôtre, et non le domaine partagé du prestataire. |
| DMARC | Aucun. Rien dans WordPress ne publie de politique ni ne vous avertit qu’il en manque une. | Sans enregistrement, vous ne recevez aucun rapport sur le courrier non authentifié qui part de votre domaine. Avec un p=reject publié pendant que le site utilise encore PHP mail(), vous rejetez vos propres réinitialisations de mot de passe. | Publiez v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, confirmez dans les rapports que votre trafic WordPress apparaît désormais aligné sous le prestataire choisi, puis durcissez vers quarantine, puis reject. |
Une fois ces enregistrements mis à jour, vérifiez qu’ils passent avec les outils gratuits d’Unspam : SPF checker, DKIM checker et DMARC checker.
Le test intégré de WP Mail SMTP, sous WP Mail SMTP > Tools > Email Test, n’expose qu’une adresse Send To et un interrupteur HTML, et son message de succès dit que l’e-mail de test a été envoyé, pas où il a atterri. Il prouve que votre connexion et vos identifiants fonctionnent, et son Domain Check interroge SPF, DKIM et DMARC pour le domaine From, mais il ne peut pas vous dire dans quel dossier arrive une vraie notification. Faites plutôt un envoi réel.
Lancez un test antispam ou un test de placement en boîte de réception dans Unspam et copiez l’adresse de test qu’il génère. Les tests de placement livrent dans des boîtes de test chez Gmail, Outlook, Yahoo et cinq autres fournisseurs, et rapportent où chaque exemplaire a atterri. Un test de placement en boîte de réception génère aussi un ID de test. Vous devez le coller dans l’objet ou dans le corps du message avant l’envoi, sinon le message arrive dans les boîtes de test sans jamais être rattaché à votre test.
Chaque chemin a son propre expéditeur. Le courrier du cœur de WordPress part de wordpress@yourdomain.com, sauf si wp_mail_from ou Force From Email l’emporte ; WooCommerce utilise l’adresse From définie sous WooCommerce > Settings > Emails ; et une extension de formulaire utilise le From Email de la notification concernée. Tester le courrier du cœur ne prouve rien sur celui de WooCommerce si les deux partent sous des adresses différentes.
Pour un formulaire de contact, soumettez le formulaire vous-même avec l’adresse de test dans le champ e-mail et l’ID de test collé dans le champ message, pour que la notification le transporte dans le corps. Pour WooCommerce, chaque modèle d’e-mail a son propre champ Subject sous WooCommerce > Settings > Emails : ajoutez-y l’ID de test le temps du test, puis retirez-le ensuite. Ne testez pas avec une réinitialisation de mot de passe du cœur : vous ne pouvez pas injecter l’ID de test dans ce message.
Envoyez depuis l’hébergement de production, pas depuis une installation locale ni depuis une copie de préproduction. L’IP d’envoi, la route SMTP et jusqu’à la disponibilité des ports diffèrent d’un environnement à l’autre, et les extensions de préproduction qui suppriment le courrier sortant rendront tout l’exercice muet. Si vous utilisez une couche de cache ou un pare-feu, soumettez le formulaire en visiteur déconnecté, pour que la requête suive exactement le chemin de code qu’emprunterait celle d’un client.
Dans Unspam, confirmez que le domaine d= de DKIM est le vôtre, que SPF est passé face à un Return-Path que vous reconnaissez et non face au nom d’hôte de votre serveur web, et que DMARC montre l’alignement. Regardez ensuite le placement par fournisseur, le score de spam et les règles qu’il a déclenchées, ainsi que les prévisualisations dans les clients de messagerie. Corrigez ce que le rapport signale, puis refaites le même envoi avec un nouvel ID de test.
Le même test affiche votre campagne dans plus de 50 clients de messagerie réels, dont Gmail, Outlook, Apple Mail, iPhone et Android, chacun en mode clair et en mode sombre, grâce aux prévisualisations dans les clients de messagerie, pour confirmer le placement et le rendu en une seule passe.
La valeur de retour vous dit que PHPMailer a passé le message sans lever d’exception, ce qui, sur le chemin PHP mail(), signifie que le MTA local l’a accepté. La remise, le filtrage et l’abandon pur et simple se produisent tous après ce point. WordPress ne déclenche l’action wp_mail_failed avec un WP_Error que lorsque PHPMailer lève une exception : un message mis en file localement puis discrètement jeté ressemble donc exactement à un succès du point de vue de votre site.
Cela compte doublement, parce qu’une extension de formulaire qui injecte discrètement l’adresse du visiteur pose sur le message une adresse From qui ne vous appartient pas, c’est-à-dire exactement ce que WPForms vous dit d’éviter : selon sa documentation, utiliser l’adresse de la personne qui a rempli le formulaire donne l’impression que vous envoyez depuis une adresse dont vous n’êtes pas propriétaire, et peut faire signaler la notification comme de l’hameçonnage.
wp_mail() utilise par défaut un type de contenu text/plain et fixe explicitement l’AltBody de PHPMailer à une chaîne vide. Quand une extension filtre wp_mail_content_type vers text/html, PHPMailer bascule en HTML mais le corps alternatif reste vide : le message part donc comme une unique partie text/html. Les filtres de contenu pénalisent cette forme à elle seule, puisque la règle MIME_HTML_ONLY de SpamAssassin se déclenche pour un message dont les parties MIME se limitent à text/html. Utilisez un service d’envoi ou un modèle qui construit un vrai message multipart/alternative.
Dans WP Mail SMTP, Email Log, Email Reports, Email Alerts, Backup Connection, Smart Conditional Routing et Rate Limiting sont toutes des fonctionnalités Pro. Sur le palier gratuit, un service d’envoi qui se met à refuser vos messages ne laisse aucune trace dans l’administration, et le premier signe est un client qui demande pourquoi il n’a jamais reçu son reçu. FluentSMTP fournit gratuitement les journaux d’e-mails et les alertes d’échec vers Slack, Telegram ou Discord, et WooCommerce enregistre de son côté les tentatives Sent, Failed, Disabled et Skipped sous WooCommerce > Status > Logs.
Les problèmes de délivrabilité que les expéditeurs WordPress rencontrent le plus souvent, chacun avec la solution qui le règle.
wp_mail() renvoie true dès que PHPMailer a passé le message à PHP mail() et que le MTA local l’a accepté. Si ce MTA n’a aucune route de sortie, ou si le serveur de réception jette le message parce qu’il n’est pas signé et que son enveloppe appartient à un serveur mutualisé, rien nulle part dans WordPress n’enregistre la perte. L’action wp_mail_failed ne se déclenche que lorsque PHPMailer lève une exception.
La solution Installez FluentSMTP ou WP Mail SMTP, connectez un prestataire, et consultez le journal de l’extension pour cet envoi précis. Si le journal montre une remise et que la boîte reste vide, le problème se situe côté réception : faites alors un envoi réel vers une adresse de test Unspam et lisez les résultats d’authentification.
Votre propre serveur de messagerie met en général votre domaine ou votre serveur en liste blanche : un test interne ne vous apprend donc rien. Gmail applique ses règles pour les expéditeurs : SPF ou DKIM au minimum, des enregistrements DNS directs et inverses valides sur l’IP d’envoi, et TLS pendant le transport. PHP mail() depuis un hébergement mutualisé échoue au premier point, échoue souvent au deuxième, et ne vous donne aucune visibilité sur l’un comme sur l’autre.
La solution Faites passer le courrier WooCommerce par un prestataire, réglez l’adresse From sous WooCommerce > Settings > Emails sur une boîte de votre propre domaine, et vérifiez sur une vraie commande que DKIM signe bien avec votre domaine. Ne testez jamais la délivrabilité en écrivant à une boîte hébergée sur l’infrastructure d’où vous envoyez.
L’outil Email Test envoie son propre message avec le From Email de l’extension. Votre extension de formulaire, elle, définit sa propre adresse From dans les réglages de la notification : à moins que Force From Email ne soit coché, la vraie notification part donc sous un autre expéditeur, peut-être un expéditeur que le prestataire n’a pas vérifié et que vos enregistrements DNS ne couvrent pas. Même site, deux identités d’envoi différentes.
La solution Cochez Force From Email sous WP Mail SMTP > Settings, ou réglez le From Email de la notification du formulaire sur la même adresse vérifiée, et déplacez l’adresse du visiteur dans le Reply-To avec un smart tag. Soumettez ensuite le formulaire pour de vrai, avec une adresse de test Unspam et l’ID de test dans le champ message.
Le formulaire place l’adresse du visiteur dans l’en-tête From : votre serveur envoie donc du courrier qui se déclare venir de gmail.com. Les exigences de Google pour les expéditeurs se sont durcies en février 2024, et un courrier non authentifié peut désormais être classé en spam ou rejeté franchement avec un 5.7.26. Rien n’a changé sur votre site ; c’est la barre qui a monté.
La solution Mettez une adresse de votre propre domaine dans le From, et l’adresse de la personne qui a rempli le formulaire dans le Reply-To, ce que documentent aussi bien WPForms que WooCommerce. Authentifiez ensuite correctement ce domaine par un prestataire SMTP, pour que le From que vous utilisez désormais passe réellement l’alignement SPF ou DKIM.
La politique des ports sortants dépend de la plateforme et elle ne voyage pas avec vos fichiers. Kinsta bloque le port 25 sortant et propose 587, 465 et 2525. WP Engine n’autorise pas le port 25, autorise 587 et 465, et recommande 2525. DigitalOcean bloque par défaut 25, 465 et 587 sur les Droplets, y compris le trafic passant par une Reserved IP, et AWS limite par défaut le port 25 depuis EC2. Un port bloqué se manifeste par un délai de connexion dépassé, pas comme un problème de délivrabilité.
La solution Demandez par écrit à votre hébergeur quels ports sortants sont ouverts pour votre offre, réglez dans votre extension le couple port et chiffrement correspondant (TLS avec 587, ou SSL avec 465), et si tout est bloqué, basculez sur un service d’envoi qui joint le prestataire en HTTPS plutôt qu’en SMTP.
Ce n’est pas le volume qui gêne les filtres. wp_mail() confie le message à PHP mail(), qui l’envoie sans signature, depuis une adresse que personne ne possède, avec une enveloppe appartenant à votre serveur web plutôt qu’à votre domaine. Google demande à tout expéditeur, quel que soit son volume, de mettre en place SPF ou DKIM. Une seule réinitialisation de mot de passe non authentifiée échoue à cette exigence aussi nettement qu’une campagne.
Oui, dans presque tous les cas. Avec PHP mail(), ce n’est pas votre enregistrement SPF que les serveurs de réception contrôlent, puisque l’expéditeur d’enveloppe appartient à votre hébergeur, et rien dans WordPress ne signe avec votre clé DKIM. Les enregistrements ne commencent à servir qu’une fois l’identité d’envoi possédée par quelque chose, et c’est exactement ce qu’apporte une extension SMTP reliée à un prestataire. Publier DMARC en restant sur PHP mail() ne sert qu’aux rapports que cela génère.
Les deux remplacent le chemin wp_mail() par une connexion authentifiée à un prestataire, et les deux s’installent gratuitement. FluentSMTP est entièrement gratuit et fournit les journaux d’e-mails, les alertes d’échec et le routage entre plusieurs connexions selon l’adresse From. WP Mail SMTP offre une liste gratuite plus large, avec SendLayer, Brevo, Gmail, Mailgun, SendGrid et Postmark, mais réserve à la version Pro Email Log, Alerts, Backup Connection, Smart Conditional Routing ainsi que Microsoft, Amazon SES et Zoho. Choisissez selon le service d’envoi dont vous avez besoin, et selon votre envie de journaliser sans payer.
Essayez d’abord 587 en TLS, puis 465 en SSL, puis 2525 si votre prestataire le propose : Kinsta cite 587, 465 et 2525 comme utilisables, et WP Engine autorise 587 et 465 tout en recommandant 2525. Si tous les ports SMTP sont bloqués, ce qui est le réglage par défaut de DigitalOcean sur les Droplets, utilisez un service d’envoi qui parle à l’API d’un prestataire en HTTPS au lieu de passer par SMTP. Le correctif que WP Mail SMTP donne lui-même pour un échec de connexion consiste à corriger le couple port et chiffrement, ou à basculer sur un service d’envoi qui passe par une API.
Non. Remplacez-la par une vraie boîte, relevée par quelqu’un, sur votre domaine d’envoi, pour que les réponses et les avis de bounce arrivent chez un humain. Appliquez-la avec les filtres wp_mail_from et wp_mail_from_name, ou renseignez From Email et From Name dans WP Mail SMTP en cochant Force From Email, pour que les extensions ne l’écrasent pas. Assurez-vous que cette adresse a bien été vérifiée chez votre prestataire, sinon l’envoi sera rejeté.
Non. Unspam ne se connecte jamais à votre site, à votre hébergeur ni à votre administration. Il y a exactement deux points d’intégration : une adresse de test à laquelle vous écrivez, et des identifiants SMTP que vous fournissez vous-même si vous voulez faire tourner des tests automatiques à intervalles réguliers. Tout le reste du rapport est lu dans le message que votre site a réellement envoyé.
Les informations sur la plateforme WordPress ont été vérifiées à partir de la documentation publique en août 2026 et ont pu changer depuis. WordPress est une marque de son propriétaire respectif. Unspam n’est ni affilié à WordPress ni approuvé par WordPress.
