Maintenance et sécurité
Emails WordPress non reçus : diagnostic de bout en bout
Le succès de wp_mail() signifie que WordPress a transmis le message au système d’envoi, pas que le destinataire l’a reçu. Il faut distinguer déclenchement, file d’attente, rejet, authentification du domaine et placement en spam.
Ce que ce symptôme signifie réellement
Une absence de message peut venir du formulaire, d’une condition métier, du transport SMTP/API, d’un rebond, d’une politique DMARC ou du destinataire.
Changer l’adresse From sans aligner le domaine peut dégrader la délivrabilité. Les tests doivent utiliser des destinataires autorisés et un volume minimal.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Suivez un message de test identifiable sans exposer son contenu : événement WordPress, identifiant fournisseur, statut, rebond et résultat chez le destinataire.
- Confirmer que le formulaire ou l’événement valide sa requête et appelle l’envoi.
- Contrôler la configuration du transport et les journaux sans afficher de secret.
- Vérifier SPF, DKIM, DMARC, alignement From/Return-Path et TLS.
- Tester réception et réponse sur quelques boîtes autorisées.
Correction : appliquer une action ciblée et réversible
Corrigez le maillon fautif : logique du formulaire, transport authentifié, DNS, adresse d’expéditeur ou traitement du rebond.
- Utiliser un expéditeur du domaine authentifié et une adresse Reply-To pour le visiteur.
- Configurer SPF/DKIM/DMARC avec le fournisseur réellement utilisé.
- Journaliser statut et identifiant, pas le corps ni les données sensibles.
- Prévoir une file fiable et une alerte sur les échecs répétés.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Soumission nominale et erreur utilisateur testées sans double envoi.
- Réception, réponse et rebond observés.
- Aucun secret ni donnée personnelle dans les logs.
Quand arrêter et demander une intervention
Pour un domaine qui envoie en volume, impliquez l’administrateur DNS et le fournisseur avant tout changement SPF/DMARC ; une politique erronée peut affecter toute l’entreprise.