WordPress n’envoie pas d’e-mails : configuration SMTP qui livre réellement

Playbook de diagnostic rapide

Si vous êtes d’astreinte, vous n’avez pas le temps de redécouvrir SMTP. Il faut trouver rapidement le goulot d’étranglement : WordPress ? PHP ? MTA local ? réseau ? relais distant ? DNS/politique ? filtrage côté destinataire ? Suivez cette séquence.

Premier point : confirmez si WordPress tente vraiment d’envoyer

• Déclenchez un e-mail connu : réinitialisation de mot de passe pour un utilisateur test, e-mail de commande WooCommerce, ou un envoi de formulaire qui journalise un événement.
• Vérifiez les logs de l’application : logs du plugin (si votre plugin SMTP les prend en charge), logs du serveur web pour la requête, et log de débogage WordPress si activé.
• Décision : S’il n’y a aucune tentative, vous avez un problème d’application/configuration. S’il y a une tentative, continuez.

Deuxième point : identifiez le chemin d’envoi

• Est-ce PHP mail() vers un MTA local ? Cela signifie « WordPress a remis un message au serveur ». Ça ne dit rien sur la livraison.
• Est-ce SMTP direct vers un relais ? Mieux : vous pouvez vous authentifier, logger et tracer les échecs.
• Décision : Si vous ne pouvez pas nommer le chemin en une phrase, vous n’avez pas un système — vous avez des impressions.

Troisième point : localisez la première erreur durable

• La file du MTA local grossit ? Inspectez la file et les logs de Postfix/Exim.
• Le SMTP distant rejette ? Vous avez besoin du code d’erreur distant (5xx/4xx) et de la raison.
• Accepté mais pas reçu ? Délivrabilité et politique : SPF/DKIM/DMARC, réputation, contenu, limitation de débit ou filtrage côté destinataire.
• Décision : Ne changez pas cinq choses à la fois. Capturez la première erreur solide, puis corrigez la cause sous-jacente.

Idée paraphrasée (attribuée) : Rendre l’échec visible ; la fiabilité commence par l’observation de ce que le système fait vraiment — Charity Majors (idée paraphrasée).

Ce qui casse réellement quand WordPress n’envoie pas d’e-mails

« WordPress n’envoie pas d’e-mails » correspond généralement à l’un des cas suivants :

1. Pas de MTA ou MTA local cassé. Beaucoup d’images VPS modernes ne sont pas fournies avec un agent de transfert de courrier configuré. PHP peut appeler sendmail, mais il n’y a rien de sensé derrière.
2. Le fournisseur bloque le SMTP sortant. Certains hébergeurs bloquent le port 25 ou limitent le mail depuis des plages IP partagées. Les fournisseurs cloud font cela pour réduire les abus.
3. L’authentification SMTP échoue. Mauvais nom d’utilisateur, mauvais mot de passe, mauvais port, mauvais mode de chiffrement, identité « From » incorrecte, ou mauvais paramètres de locataire (bonjour, Microsoft 365).
4. L’identité DNS est manquante ou mal alignée. SPF trop strict, DKIM non configuré, DMARC en enforcement et alignement qui échoue. Le mail est rejeté ou silencieusement dirigé en dossier spam.
5. Problèmes de réputation et de politique. Un domaine/IP neuf envoyant des mails transactionnels semble suspect. Les systèmes destinataires ne se soucient pas que ce soit « juste des réinitialisations de mot de passe ». Ils regardent les signaux.
6. Le contenu déclenche des filtres. Les formulaires envoyant du contenu généré par l’utilisateur peuvent ressembler à du phishing, ou contenir des URL listées comme malveillantes.
7. Problèmes d’heure et TLS. Une mauvaise heure système casse la validation TLS. Des suites de chiffrement obsolètes cassent des points SMTP modernes. « Ça marche sur mon laptop » parce que votre laptop n’est pas le serveur.

Blague #1 : La délivrabilité des e-mails ressemble à un videur de boîte de nuit : vous pouvez être sur la liste et ne pas passer parce que vous « avez l’air suspect ».

En production, je considère le mail WordPress comme un pipeline avec des points de contrôle :

• Point d’application : WordPress appelle wp_mail().
• Point de transport : le plugin passe à SMTP ou PHP mail() passe au MTA local.
• Point de relais : le relais SMTP accepte (ou rejette) le message.
• Point du destinataire : le SMTP destinataire accepte (ou rejette) du relais.
• Point de la boîte de réception : le filtrage et la politique décident où il arrive, ou s’il est mis en quarantaine.

Votre travail est de trouver le premier point de contrôle où la réalité diverge de l’attendu. Tout ce qui suit n’est que bruit en aval.

Faits intéressants (et pourquoi ils comptent encore)

• SMTP est plus ancien que le web. La spécification SMTP de base précède l’hébergement web moderne, ce qui explique qu’elle suppose beaucoup de confiance et que l’authentification soit ajoutée plus tard.
• SPF a été conçu pour arrêter la falsification de l’expéditeur d’enveloppe, pas l’en-tête « From : ». Beaucoup s’attendent à ce que SPF valide ce que les utilisateurs voient. Ce n’est pas le cas — l’alignement via DMARC relie les choses.
• DKIM signe le corps du message et certains en-têtes sélectionnés. Cela signifie que certains relais « utiles » qui réécrivent le contenu peuvent casser les signatures et faire chuter la livraison.
• DMARC existe parce que SPF et DKIM seuls ne suffisaient pas. DMARC ajoute une politique et des rapports, et formalise l’alignement pour que les récepteurs puissent appliquer des règles.
• Le greylisting existe encore. Certains destinataires rejettent temporairement les expéditeurs inconnus (un 4xx). Les bons MTA renvoient ; les implémentations naïves déclarent l’échec et abandonnent.
• Les IP d’hébergement partagé héritent souvent d’une mauvaise réputation. Votre site WordPress peut être bien tenu, mais votre voisin IP peut être un lanceur de newsletters incontrôlable.
• Le port 25 est couramment bloqué par les fournisseurs cloud. Pas parce qu’ils vous en veulent — parce que le spam est une externalité et ils en paient le coût en réputation et gestion des abus.
• Les mails transactionnels et marketing n’ont pas les mêmes attentes. Les réinitialisations de mot de passe exigent une livraison rapide et une grande confiance ; le bulk nécessite un warm-up et une conformité stricte. Les mélanger nuit aux deux.
• L’adresse « From » compte plus qu’on ne le pense. Beaucoup de récepteurs appliquent la réputation au niveau du domaine affiché dans l’en-tête From, pas seulement à l’IP envoyante.

Choisir votre architecture SMTP (et éviter les mauvaises tentations)

Option A : Utiliser un service de relais SMTP dédié (recommandé)

C’est la réponse mature pour la plupart des sites WordPress importants. Votre hôte WordPress gère l’application. Un relais dédié gère la délivrabilité, les retries, le traitement des rebonds, les boucles de feedback et la réputation IP.

Avantages : meilleure délivrabilité, vrais logs, comportement de throttling prévisible, support DNS/authentification plus simple. Inconvénients : coût, travail DNS, gestion des identifiants.

Choisissez cela quand : vous envoyez des réinitialisations de mot de passe, confirmations de commande, e-mails d’adhésion, ou tout ce pour quoi les utilisateurs vont crier si ça échoue.

Option B : Utiliser le SMTP de votre fournisseur de boîte mail corporate (parfois acceptable)

Gmail/Google Workspace ou Microsoft 365 peuvent fonctionner pour des mails transactionnels à faible volume, mais attendez-vous à des contraintes : limites de débit, restrictions du « From », évolutions OAuth vs auth basique, politiques de locataire et surprises occasionnelles.

Avantages : déjà payé, console d’admin familière. Inconvénients : limites, friction d’audit, et il est facile de mal configurer les identités et casser DMARC.

Option C : Exécuter Postfix sur le serveur et livrer directement (rarement rentable)

Oui, vous pouvez exécuter votre propre MTA sortant et envoyer directement aux MX destinataires. Si vous lisez ceci parce que le mail WordPress est instable, vous ne voulez probablement pas devenir aussi ingénieur de réputation d’e-mail.

Avantages : contrôle total. Inconvénients : gestion de réputation, listes de blocage, reverse DNS, gestion des abus, tuning constant. Aussi : on vous reprochera le spam que vous n’avez pas envoyé.

Le mauvais choix par défaut : PHP mail() dans le vide

PHP mail() n’est pas « mauvais », c’est juste le transport le moins observable. C’est une remise à ce qui est configuré comme sendmail_path. En hébergement mutualisé ça peut marcher. Dans des environnements modernes gérés ça pointe souvent sur rien ou sur un relais local sans travail de délivrabilité.

Tâches pratiques : commandes, sorties, décisions (12+)

Ces tâches sont conçues pour être exécutées sur l’hôte WordPress (ou l’hôte du conteneur) avec accès shell. Chacune inclut : commande, sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Confirm WordPress host can resolve DNS correctly

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 8.8.8.8

Sens : la résolution DNS est configurée et pointe vers des résolveurs joignables.

Décision : Si le DNS est cassé ou pointe vers un résolveur interne incapable de résoudre les enregistrements publics, corrigez le DNS d’abord. Le dépannage SMTP sans DNS, c’est de l’art perfomatif.

Task 2: Check whether outbound SMTP ports are reachable

cr0x@server:~$ nc -vz smtp.mailprovider.example 587
Connection to smtp.mailprovider.example 587 port [tcp/submission] succeeded!

Sens : le chemin réseau vers le relais sur le port 587 (submission) est ouvert.

Décision : Si cela échoue, vous avez affaire à des règles de pare-feu, contrôles d’e sortie cloud ou restrictions du fournisseur. Utilisez 587/465 avec authentification ; ne combattez pas les blocages du port 25 à moins d’aimer les tickets d’abus.

Task 3: Verify system time (TLS depends on it)

cr0x@server:~$ timedatectl
               Local time: Sat 2025-12-27 13:05:41 UTC
           Universal time: Sat 2025-12-27 13:05:41 UTC
                 RTC time: Sat 2025-12-27 13:05:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : l’horloge est synchronisée ; la validation des certificats TLS ne va pas échouer parce que le système croit que nous sommes en 1970.

Décision : Si non synchronisé, corrigez NTP. Les échecs TLS aléatoires vont vous faire perdre votre après-midi.

Task 4: Identify whether a local MTA is present

cr0x@server:~$ command -v sendmail; systemctl status postfix 2>/dev/null | head
/usr/sbin/sendmail
Unit postfix.service could not be found.

Sens : un binaire sendmail existe (peut-être msmtp ou nullmailer), mais Postfix n’est pas installé.

Décision : Si vous vous fiez à PHP mail(), vous devez savoir ce qu’est réellement /usr/sbin/sendmail. S’il manque ou est inerte, passez au SMTP via un plugin ou installez/configurez un MTA correct.

Task 5: See what PHP thinks “sendmail” is

cr0x@server:~$ php -i | grep -E '^sendmail_path|^mail\.force_extra_parameters'
sendmail_path => /usr/sbin/sendmail -t -i => /usr/sbin/sendmail -t -i
mail.force_extra_parameters => no value => no value

Sens : PHP appellera /usr/sbin/sendmail -t -i.

Décision : Si vous n’exploitez pas intentionnellement un MTA local, cessez d’utiliser ce chemin. Par défaut il n’est pas journalisé et échoue de manière créative.

Task 6: If Postfix exists, inspect the mail queue

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A91234A      2213 Sat Dec 27 12:58:02  wordpress@example.com
                                         user@gmail.com
                                         (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)
-- 1 Kbytes in 1 Request.

Sens : les messages sont en file et ne peuvent pas atteindre le MX destinataire sur le port 25 (timeout).

Décision : Arrêtez d’essayer de livrer direct-to-MX depuis cet hôte. Utilisez un relais authentifié sur 587/465. La file vous dit que le chemin réseau est bloqué.

Task 7: Read mail logs for SMTP errors (Postfix example)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Dec 27 12:58:02 server postfix/smtp[21877]: connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out
Dec 27 12:58:32 server postfix/smtp[21877]: connect to gmail-smtp-in.l.google.com[2607:f8b0:400e:c06::1b]:25: Network is unreachable
Dec 27 12:59:02 server postfix/qmgr[901]: 3F2A91234A: from=<wordpress@example.com>, size=2213, nrcpt=1 (queue active)

Sens : timeouts constants et IPv6 injoignable. Ce n’est pas un bug WordPress.

Décision : Configurez Postfix pour relayer via un smarthost sur 587, ou désactivez IPv6 si il est mal routé. Mieux : évitez le MTA local et utilisez un plugin SMTP qui envoie directement au relais.

Task 8: Test SMTP authentication and TLS with OpenSSL

cr0x@server:~$ openssl s_client -starttls smtp -connect smtp.mailprovider.example:587 -servername smtp.mailprovider.example -crlf
CONNECTED(00000003)
depth=2 C=US O=Example CA CN=Example Root CA
verify return:1
depth=1 C=US O=Example CA CN=Example Issuing CA
verify return:1
depth=0 CN=smtp.mailprovider.example
verify return:1
---
250 STARTTLS
250 AUTH PLAIN LOGIN
250 PIPELINING
250 SIZE 10485760

Sens : la négociation TLS fonctionne ; le serveur annonce des mécanismes AUTH.

Décision : Si la vérification du certificat échoue, corrigez le bundle CA ou un proxy interceptant. Si STARTTLS n’est pas proposé, vous êtes sur le mauvais port ou le fournisseur exige TLS implicite (465).

Task 9: Validate SPF record presence for your sending domain

cr0x@server:~$ dig +short TXT example.com | grep -i spf
"v=spf1 include:_spf.mailprovider.example -all"

Sens : le domaine a un enregistrement SPF autorisant votre relais.

Décision : S’il manque, ajoutez-le. S’il se termine par -all et que vous n’incluez pas le relais, les destinataires vont vous rejeter ou vous mettre en spam. S’il y a plusieurs enregistrements SPF, corrigez cela aussi (voir Task 10).

Task 10: Detect multiple SPF records (a common self-own)

cr0x@server:~$ dig +short TXT example.com | grep -i "v=spf1" | wc -l
2

Sens : Deux enregistrements SPF existent. Les récepteurs traitent cela comme une erreur permanente (PermError) et SPF échoue en pratique.

Décision : Fusionnez les mécanismes SPF en un seul enregistrement. Ne publiez jamais plusieurs TXT v=spf1.

Task 11: Confirm DKIM records exist (selector-based)

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Sens : la clé publique DKIM est présente pour le sélecteur s1.

Décision : Si absent, activez DKIM chez votre fournisseur relais et publiez le TXT exactement comme fourni. DKIM n’est plus optionnel pour une livraison cohérente.

Task 12: Confirm DMARC policy and alignment expectations

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com"

Sens : DMARC applique une quarantaine avec alignement strict pour DKIM et SPF.

Décision : L’alignement strict signifie que votre From: visible doit correspondre aux domaines authentifiés. Configurez le « From Email » de WordPress et l’identité du relais pour être alignés, ou assouplissez l’alignement si vous comprenez les implications.

Task 13: Check reverse DNS (PTR) for your sending IP (if you send directly)

cr0x@server:~$ dig +short -x 203.0.113.10
mail.example.com.

Sens : un PTR existe. Beaucoup de récepteurs se méfient des IP sans rDNS.

Décision : Si vous livrez directement, corrigez le PTR avec votre ISP/fournisseur cloud. Si vous relayezez via un fournisseur SMTP, cela importe moins pour votre hôte et plus pour les IP du relais.

Task 14: Observe WordPress/PHP errors around mail sending (PHP-FPM)

cr0x@server:~$ sudo tail -n 40 /var/log/php8.2-fpm.log
[27-Dec-2025 12:57:51] WARNING: [pool www] child 18234 said into stderr: "PHP Warning:  fsockopen(): Unable to connect to smtp.mailprovider.example:587 (Connection timed out) in /var/www/html/wp-includes/PHPMailer/SMTP.php on line 214"
[27-Dec-2025 12:57:51] WARNING: [pool www] child 18234 said into stderr: "SMTP connect() failed."

Sens : l’application a tenté SMTP mais a expiré — chemin réseau ou pare-feu.

Décision : Corrigez le pare-feu d’egress/groupes de sécurité, NAT, ou les restrictions du fournisseur d’hébergement. Ne continuez pas à tripoter les réglages du plugin quand la poignée de main TCP ne se fait jamais.

Task 15: Quick end-to-end SMTP test using swaks (if installed)

cr0x@server:~$ swaks --to user@gmail.com --from wordpress@example.com --server smtp.mailprovider.example --port 587 --auth LOGIN --auth-user wordpress@example.com --auth-password 'REDACTED' --tls
=== Trying smtp.mailprovider.example:587...
=== Connected to smtp.mailprovider.example.
<= 220 smtp.mailprovider.example ESMTP ready
=> EHLO server
<= 250-AUTH PLAIN LOGIN
=> AUTH LOGIN
<= 235 2.0.0 Authentication successful
=> MAIL FROM:<wordpress@example.com>
<= 250 2.1.0 Ok
=> RCPT TO:<user@gmail.com>
<= 250 2.1.5 Ok
=> DATA
<= 354 End data with <CR><LF>.<CR><LF>
=> .
<= 250 2.0.0 Accepted for delivery
=== Connection closed with remote host.

Sens : le relais SMTP a accepté le message. Vous êtes maintenant dans le territoire de la délivrabilité, pas du transport.

Décision : Si accepté mais non reçu, inspectez les logs du relais, vérifiez les dossiers spam/quarantaine, vérifiez l’alignement SPF/DKIM/DMARC et assurez-vous que le « From » correspond au domaine authentifié.

Configuration SMTP WordPress qui tient en production

WordPress utilise PHPMailer en interne. Le mode d’échec classique est que WordPress est configuré pour « envoyer » des mails mais le transport est soit manquant (pas de MTA) soit non fiable (IP partagée sans authentification). SMTP corrige les deux en rendant l’envoi explicite.

Choisissez un seul plugin SMTP — et traitez-le comme une infrastructure

Je ne suis pas là pour discuter des marques. Choisissez un plugin SMTP réputé qui :

• supporte SMTP authentifié avec TLS
• peut logger les tentatives d’envoi et les erreurs
• vous permet de définir un From name/email cohérent
• supporte OAuth si votre fournisseur l’exige

Règles de configuration pour éviter les désastres habituels

1. Utilisez le port 587 avec STARTTLS sauf si votre fournisseur exige explicitement 465 (TLS implicite). Le port 25 est pour serveur-à-serveur et souvent bloqué.
2. Définissez l’adresse From sur une boîte réelle ou un expéditeur autorisé dans le même domaine que vous authentifiez. N’utilisez pas wordpress@localhost ou no-reply@yourdomain à moins que votre relais le permette et que votre DNS soit aligné.
3. Forcez l’adresse From et le nom From pour les mails transactionnels. Les plugins et thèmes aiment remplacer les en-têtes ; cela casse l’alignement et crée des problèmes de délivrabilité « aléatoires ».
4. N’utilisez pas un identifiant de boîte perso pour un site web. Utilisez un compte de service ou une clé d’API de relais. Faites-le tourner. Stockez-le dans votre gestionnaire de secrets si vous en avez un.
5. Activez la journalisation du plugin si disponible, au moins pendant la configuration. Vous voulez des horodatages et des codes d’erreur SMTP.
6. Séparez transactionnel et marketing si le volume augmente. Même chez le même fournisseur, utilisez des sous-domaines ou identités d’envoi distincts pour éviter que l’un ne pollue l’autre.

Identité : l’adresse « From » n’est pas un choix esthétique

Pour le mail aligné DMARC, l’en-tête visible From: doit s’aligner soit avec :

• le domaine aligné SPF (le domaine de l’expéditeur d’enveloppe / return-path), ou
• le domaine d= DKIM (le domaine qui signe le message)

Si vous vous authentifiez SMTP en tant que wordpress@example.com mais que votre plugin définit From comme wordpress@some-other-domain, DMARC peut échouer même si l’authentification SMTP réussit. C’est pourquoi « SMTP fonctionne mais les e-mails disparaissent ».

Blague #2 : L’en-tête « From » est comme un badge nominatif à une conférence — s’il ne correspond pas à votre inscription, la sécurité s’intéresse à vous.

DNS et authentification de domaine : SPF, DKIM, DMARC

SMTP fait sortir le mail. L’authentification fait qu’il soit accepté — et traité comme un citoyen responsable une fois arrivé. En 2025, supposez que les grosses boîtes mail soient par défaut méfiantes.

SPF : autorisez les expéditeurs, ne compliquez pas trop

SPF est un enregistrement TXT qui dit « ces hôtes/IP peuvent envoyer pour mon domaine ». Les récepteurs vérifient l’IP de connexion par rapport à cette politique.

Règles pour garder SPF sain :

• Publiez exactement un enregistrement SPF par domaine.
• Privilégiez les mécanismes include: pour votre fournisseur relais ; évitez de lister des dizaines d’IP à moins de les posséder.
• Surveillez la limite de recherche DNS (10). Trop d’includes peut causer un SPF PermError.
• Décidez de la politique : ~all (softfail) pendant la migration ; -all (fail) une fois sûr.

DKIM : intégrité et identité de domaine

DKIM signe les mails sortants avec une clé privée ; les destinataires vérifient avec votre clé publique publiée. Cela prouve que le message n’a pas été modifié en transit et le lie à un domaine.

Notes opérationnelles :

• Utilisez des clés 2048 bits là où c’est supporté.
• Faites pivoter les sélecteurs périodiquement (par ex. s1, s2). Gardez les anciens sélecteurs pendant la période de chevauchement.
• Méfiez-vous des plugins ou relais « utiles » qui réécrivent le HTML ou ajoutent des pieds de page ; cela peut casser DKIM sauf si la signature est faite après la réécriture (les fournisseurs gèrent généralement cela correctement).

DMARC : politique, alignement et la différence entre « envoyé » et « digne de confiance »

DMARC indique aux récepteurs quoi faire si SPF et DKIM ne s’alignent pas avec le domaine visible From, et où envoyer les rapports.

Progression pratique DMARC :

1. Commencez par p=none pour mesurer sans casser les mails.
2. Passez à p=quarantine une fois que vous avez corrigé les désalignements évidents et les expéditeurs non autorisés.
3. Utilisez p=reject quand vous êtes sûr de ne pas bloquer des expéditeurs légitimes (et que vous avez inventorié tous les systèmes envoyant en votre nom).

Pièges d’alignement spécifiques à WordPress

• Les plugins de formulaire de contact définissent parfois From à l’email du visiteur. C’est une défaillance DMARC en puissance. Utilisez Reply-To pour l’adresse du visiteur à la place.
• Les installations multisite peuvent varier le domaine From par site. Si vous ne pouvez pas authentifier tous les domaines, vous aurez une livraison incohérente.
• Les outils marketing tiers peuvent aussi envoyer depuis le domaine racine. Coordonnez SPF/DKIM/DMARC ou séparez avec des sous-domaines.

Réalité de la délivrabilité : réputation, limites et contenu

Une fois que le SMTP accepte le message, vous entrez dans le domaine des heuristiques, des systèmes de réputation et des politiques anti-abus. Ce n’est pas personnel. C’est des mathématiques.

Ce que signifie « accepté pour livraison »

Quand votre relais répond « 250 Accepted », cela signifie que le relais a accepté la responsabilité de tenter la livraison. Cela ne garantit pas le placement en boîte de réception. Cela ne garantit même pas que le destinataire l’a accepté — seulement que le relais va essayer.

Réputation : votre domaine et votre comportement d’envoi

Les fournisseurs de boîtes construisent une réputation à partir de signaux comme :

• authentification cohérente (alignement SPF/DKIM/DMARC)
• faible taux de rebond
• faible taux de plaintes (utilisateurs marquant comme spam)
• schémas de volume cohérents (les pics soudains ressemblent à une compromission)
• qualité du contenu et réputation des liens

Limitation de débit et erreurs transitoires

Beaucoup d’échecs SMTP sont des 4xx de report temporaire : « réessayer plus tard ». Un bon relais retente avec backoff. Une mauvaise configuration marque l’envoi comme échoué instantanément et vous ne le remarquez pas sauf des plaintes clients.

Contenu : les e-mails WordPress peuvent attirer les filtres

Déclencheurs courants :

• formulaires acceptant du contenu arbitraire fourni par l’utilisateur, y compris des URL suspectes
• messages avec un mauvais ratio texte/HTML ou des encodages étranges
• sujets qui ressemblent à du phishing (« Urgent : Vérification du compte »)
• envoi « From » depuis un domaine sans alignement site-web (domaine tout neuf, pas d’historique)

Si votre message inclut du contenu fourni par l’utilisateur, traitez-le comme une entrée non fiable. Assainissez-le. Limitez les liens. Envisagez d’envoyer une notification minimale avec un lien pour consulter le message dans votre application web authentifiée.

Trois mini-histoires d’entreprise

Mini-histoire #1 : L’incident causé par une mauvaise hypothèse

La configuration semblait normale : WordPress sur un VPS managé, un plugin de formulaire de contact, et une adresse From réglée sur support@company.example. L’équipe supposait que parce que le site utilisait le domaine de l’entreprise, l’authentification e-mail « devait déjà être bonne ». Ils avaient configuré SPF il y a des années pour leur plateforme de newsletter et l’avaient considéré comme terminé.

Puis un changement discret est survenu : la politique DMARC est passée de p=none à p=quarantine après une revue sécurité. Personne n’a informé l’équipe web, parce que bien sûr personne n’a prévenu l’équipe web. Du coup, les e-mails du formulaire de contact ont cessé d’apparaître pour une partie des destinataires — surtout des boîtes professionnelles avec des filtres stricts.

La première réaction fut d’accuser WordPress. La deuxième fut de réinstaller le plugin. La troisième fut de « simplement utiliser PHP mail() ». Rien de tout cela n’a aidé. Le vrai problème : le plugin de formulaire mettait l’e-mail du visiteur dans l’en-tête From (pour que les réponses soient jolies). Cela faisait échouer l’alignement DMARC pour chaque message où le visiteur utilisait un domaine avec p=reject (ce qui est… beaucoup d’entre eux).

La correction fut ennuyeuse : garder From comme support@company.example, mettre Reply-To à l’adresse du visiteur. Ajouter la signature DKIM via un relais approprié. L’incident s’est réglé non par un patch héroïque, mais par un en-tête d’e-mail qui a cessé de mentir.

Mini-histoire #2 : L’optimisation qui a mal tourné

Une autre organisation avait une boutique WooCommerce à fort trafic. Ils payaient un relais e-mail et ont décidé « d’optimiser » en envoyant les réinitialisations de mots de passe et confirmations de commande via leur propre Postfix pour économiser quelques dollars. Ils avaient une IP, un serveur, et l’e-mail c’est « juste SMTP », non ?

Ça a marché environ deux semaines. Puis la délivrabilité a chuté. Certains gros fournisseurs ont commencé à renvoyer des 4xx de limitation. D’autres ont tout mis en dossier bulk. La file de support s’est remplie de « je n’ai pas reçu mon reçu ». Pire : les réinitialisations de mot de passe ont parfois disparu, créant des blocages de comptes et des rétrofacturations parce que les clients ne pouvaient pas consulter le statut de commande.

L’équipe a essayé d’ajuster Postfix, puis différents noms HELO, puis d’envoyer depuis un autre domaine. Ils couraient après des symptômes. Le vrai problème était la réputation et le comportement : une IP d’envoi nouvelle avec des volumes en pics, pas d’historique de confiance, et des rebonds occasionnels d’adresses mal saisies.

Ils sont revenus au fournisseur relais pour le mail transactionnel et ont gardé Postfix seulement comme point de soumission local vers le relais (smarthost), pas comme expéditeur direct vers les MX. L’« optimisation » a fait économiser de l’argent jusqu’à ce qu’elle ne le fasse plus. La conséquence n’était pas la complexité technique — c’était la sous-estimation de l’importance de l’historique entreprise par les récepteurs.

Mini-histoire #3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise SaaS faisait tourner plusieurs instances WordPress pour des sites marketing et des portails de documentation. Ils avaient été brûlés auparavant, alors ils ont standardisé l’envoi d’e-mails : chaque WordPress utilisait le même relais, un domaine d’envoi séparé (mail.company.example), et des adresses From forcées. Ils centralisaient aussi les logs SMTP.

Un lundi, les réinitialisations de mot de passe ont ralenti. Pas arrêté — ralenti. Le helpdesk a vu un pattern : les utilisateurs Gmail recevaient le mail, certains domaines corporate non. L’SRE de garde n’a pas touché WordPress. Il a regardé les logs du relais et a vu des 4xx de report croissants provenant d’une famille de domaines destinataires spécifique.

Parce qu’ils avaient des rapports DMARC et une signature DKIM cohérente, ils ont pu écarter rapidement un problème d’authentification. Les reports étaient des limitations de débit côté destinataire. Leur relais a retenté automatiquement avec backoff, et la livraison a rattrapé le retard en quelques heures.

La bonne action n’était pas de l’ingéniosité. C’était d’avoir construit de l’observabilité et de la cohérence dans une infrastructure e-mail « ennuyeuse », si bien que l’incident n’était qu’une mise à jour de statut, pas une panique.

Erreurs courantes : symptôme → cause racine → correction

1) « WordPress dit envoyé, mais rien n’arrive »

Cause racine : utilisation de PHP mail() sans MTA fonctionnel, ou avec un MTA local incapable de livrer (port 25 bloqué, pas de relais, file bloquée).

Correction : configurez SMTP authentifié vers un relais sur 587/465. Si vous devez utiliser un MTA local, configurez-le pour relayer via un smarthost et surveillez la file.

2) « Le SMTP fonctionne dans l’e-mail de test du plugin, mais les e-mails de formulaire échouent »

Cause racine : le plugin de formulaire définit From sur l’adresse du visiteur ; l’alignement DMARC échoue ou le relais rejette le spoofing.

Correction : définissez From sur votre domaine (aligné avec DKIM/SPF). Mettez l’e-mail du visiteur en Reply-To. La plupart des plugins de formulaire ont un réglage pour cela.

3) « Authentication failed » ou « 535 5.7.3 Authentication unsuccessful »

Cause racine : identifiants incorrects, mauvais mode d’auth, auth basique désactivée, ou le fournisseur exige un mot de passe d’application/OAuth.

Correction : utilisez la méthode approuvée par le fournisseur : mot de passe d’application, identifiants relais SMTP, ou flux OAuth. Confirmez port/chiffrement. Cessez de réutiliser les mots de passe de boîtes perso.

4) « Connection timed out » vers l’hôte SMTP

Cause racine : pare-feu egress, restrictions de groupe de sécurité, SMTP sortant bloqué par l’hébergeur, DNS erroné, ou route IPv6 cassée.

Correction : testez avec nc et openssl s_client. Autorisez l’e sortie vers le relais sur 587/465. Désactivez IPv6 défectueux ou corrigez le routage.

5) Les e-mails vont en spam chez les gros fournisseurs

Cause racine : DKIM manquant ou en échec, PermError SPF (plusieurs enregistrements SPF), DMARC mal aligné, ou mauvaise réputation.

Correction : publiez un SPF correct (un seul enregistrement), activez DKIM, ajoutez DMARC (commencez par p=none), assurez-vous que From s’aligne avec le domaine authentifié. Envisagez un relais réputé et une montée en charge progressive.

6) « Certains destinataires reçoivent le mail, d’autres jamais »

Cause racine : filtrage spécifique au destinataire, greylisting, limitation de débit, ou mise sur liste noire de l’IP/domaine d’envoi.

Correction : utilisez un relais avec retry/backoff et logs. Vérifiez les logs d’événements du relais pour les reports et rebonds. Ne supposez pas un comportement uniforme entre destinataires.

7) Les e-mails de réinitialisation WordPress échouent après une migration de site

Cause racine : réputation de la nouvelle IP, enregistrements DNS manquants dans la nouvelle zone DNS, ou envoi depuis un domaine non autorisé par le nouveau relais.

Correction : revérifiez SPF/DKIM/DMARC dans la zone DNS active. Utilisez les mêmes identifiants relais et domaine d’envoi. Confirmez que l’adresse From n’est pas revenue à une valeur par défaut.

8) « Ça marchait jusqu’à ce qu’on active le cache/CDN/plugin de sécurité »

Cause racine : pas le cache. Généralement c’est un changement concomitant : mise à jour de plugin, rotation d’identifiants, changement de politique fournisseur, durcissement de l’e sortie, ou cron arrêté donc les notifications en file ne partent plus.

Correction : vérifiez wp-cron/cron réel, la connectivité SMTP, et les logs du plugin. Corrélez les horodatages avec les déploiements et rotations d’identifiants.

Listes de contrôle / plan pas à pas

Étape par étape : de « pas d’e-mail » à « livré de manière fiable »

1. Décidez l’architecture : utilisez un relais SMTP dédié pour le mail transactionnel.
2. Choisissez l’identité d’envoi : par ex. no-reply@example.com ou support@example.com — mais faites-la réelle et alignée.
3. Configurez le plugin SMTP WordPress : hôte, port 587, STARTTLS, auth activée, forcer From.
4. Publiez SPF : enregistrement unique incluant le fournisseur relais.
5. Publiez DKIM : enregistrements sélecteurs fournis par le relais.
6. Publiez DMARC : commencez par p=none avec rapports, puis évoluez vers enforcement une fois stable.
7. Exécutez des tests de connectivité depuis le serveur : nc + openssl s_client vers le relais.
8. Envoyez un e-mail test : confirmez que le relais accepte et que le destinataire reçoit.
9. Corrigez l’alignement pour les formulaires : From = votre domaine, Reply-To = visiteur.
10. Activez la journalisation : logs du plugin + logs du relais ; conservez-les assez longtemps pour déboguer.
11. Mettez en place la surveillance : alertez sur échecs d’envoi soutenus, croissance de file (si applicable), et pics de rebonds.
12. Documentez la configuration « connue bonne » : emplacement des identifiants, enregistrements DNS, et la raison pour laquelle ce relais existe.

Checklist opérationnelle : quoi vérifier pendant un incident

• Le serveur peut-il atteindre le relais sur 587/465 ?
• Les identifiants ont-ils été tournés ou expirés ?
• Des mises à jour WordPress/plugin récentes ?
• Des changements DNS récents (SPF/DKIM/DMARC) ou des basculements de zone ?
• Logs du relais : rejets (5xx) vs reports (4xx) vs acceptés.
• Côté destinataire : des domaines spécifiques sont-ils affectés ?

Règles strictes (parce que vous serez tenté)

• Ne pas envoyer les mails de formulaire avec le visiteur en From. Utilisez Reply-To.
• Ne comptez pas sur PHP mail() dans des environnements que vous ne contrôlez pas. Si vous ne pouvez pas lire les logs mail, vous n’avez pas de système.
• Ne publiez jamais plusieurs enregistrements SPF. Jamais.
• Ne pas utiliser des identifiants de boîte partagée en production. Créez une identité de service.

FAQ

1) Pourquoi WordPress « marche » sur un hôte mais pas sur un autre ?

Parce que PHP mail() dépend du MTA et des politiques réseau de l’hôte. Un hôte a un relais configuré ; un autre n’a rien derrière /usr/sbin/sendmail, ou le SMTP sortant est bloqué.

2) Dois-je utiliser le port 465 ou 587 ?

Utilisez 587 avec STARTTLS sauf si votre fournisseur indique explicitement 465. Les deux peuvent être sécurisés ; 587 est le défaut moderne pour la soumission et se comporte généralement de manière prévisible à travers les pare-feux.

3) Mon test SMTP indique « succès », mais les e-mails n’apparaissent toujours pas. Et maintenant ?

C’est de la délivrabilité ou du filtrage côté destinataire. Vérifiez l’alignement SPF/DKIM/DMARC, consultez les logs d’événements du relais pour rebonds/reports, et testez l’envoi vers plusieurs fournisseurs. Vérifiez aussi les dossiers spam/quarantaine.

4) Puis-je juste utiliser mes identifiants Gmail ou Microsoft 365 ?

Vous pouvez, mais c’est fragile. Les fournisseurs changent les règles d’auth, imposent la MFA, et limitent le débit. Préférez un identifiant relais dédié ou un mot de passe d’application/flux OAuth supporté avec un compte de service.

5) Quelle adresse From WooCommerce doit-elle utiliser ?

Utilisez une adresse de votre domaine que vous authentifiez (par ex. orders@example.com). Forcez-la dans votre plugin SMTP pour que les templates et extensions ne la remplacent pas et provoquent un désalignement.

6) Pourquoi les e-mails de formulaire échouent souvent seulement pour certains expéditeurs ?

Si le formulaire met From à l’adresse du visiteur, les politiques DMARC du domaine du visiteur peuvent provoquer un rejet ou placement en spam. Beaucoup de grands domaines publient des DMARC stricts précisément pour empêcher ce type d’usurpation.

7) Ai-je besoin de DKIM si SPF est correct ?

Oui si vous voulez une délivrabilité cohérente. SPF peut casser avec le forwarding, et il ne signe pas le contenu. DKIM ajoute l’intégrité et améliore souvent la confiance. DMARC fonctionne mieux quand les deux sont présents.

8) Quelle est la façon la plus rapide de savoir si c’est un blocage réseau ?

Exécutez nc -vz relay 587 et openssl s_client -starttls smtp depuis l’hôte WordPress. Les timeouts et messages « no route » valent mieux que deviner.

9) Lancer mon propre Postfix pour le mail sortant est-il un bon choix un jour ?

Parfois : si vous avez une équipe mail, un espace IP stable, contrôle du reverse DNS, et l’envie de gérer réputation et abus. Pour la plupart des sites WordPress, relayer via un fournisseur est moins coûteux que votre temps.

10) Comment arrêter les e-mails d’aller en spam sans changer le contenu ?

Commencez par l’alignement d’authentification (SPF/DKIM/DMARC), puis la consistance d’envoi (volumes stables), puis la réputation (utiliser un relais réputé). Les ajustements de contenu aident, mais l’identité est la base.

Prochaines étapes réalisables aujourd’hui

Si les e-mails WordPress échouent, ne discutez pas. Instrumentez-les et donnez-leur un vrai transport.

1. Éloignez-vous de PHP mail() sauf si vous exploitez intentionnellement un MTA local avec des logs et un chemin de relais.
2. Configurez un SMTP authentifié vers un relais dédié sur 587/465 et testez la connectivité depuis l’hôte.
3. Publiez et vérifiez SPF/DKIM/DMARC et assurez-vous que l’adresse From WordPress s’aligne avec ce que votre relais authentifie.
4. Corrigez les plugins de formulaire pour que l’e-mail du visiteur aille en Reply-To, pas en From.
5. Conservez les logs (plugin + relais) et utilisez-les pour distinguer problèmes de transport et problèmes de délivrabilité.

Faites cela, et « WordPress n’envoie pas d’e-mails » cesse d’être un mystère récurrent et devient un sous-système ennuyeux et surveillable. L’ennui, c’est bien. L’ennui vous permet de dormir.