Emails WordPress non reçus : diagnostic de bout en bout

Un formulaire affiche « message envoyé », mais rien n’arrive dans la boîte mail. Avant d’installer une extension SMTP ou de modifier le domaine, il faut retrouver où le message s’arrête. WordPress, le service d’envoi et le serveur destinataire n’apportent pas la même preuve. Un résultat positif de wp_mail() ne garantit donc pas la réception.

Vérifier que WordPress déclenche bien le message

Partez d’un cas précis : une demande de contact, une notification de commande ou une récupération de mot de passe. Notez l’heure, le formulaire concerné et un identifiant de test neutre. Utilisez une boîte que vous êtes autorisé à solliciter, avec un contenu fictif. Il n’est pas nécessaire de recopier une demande client pour reproduire le problème.

• Le formulaire refuse la demande : vérifiez le champ signalé, le consentement requis ou la protection antispam. Aucun e-mail n’est forcément attendu à cette étape.
• La demande est acceptée, sans trace d’envoi : contrôlez les notifications activées, le destinataire configuré et les conditions qui déclenchent le message.
• Une trace d’envoi existe : relevez son statut et son heure avant de passer au transport. Le message de confirmation affiché au visiteur ne suffit pas.

Si le problème concerne surtout les messages indésirables, traitez aussi la protection du formulaire contre le spam. Une règle trop large peut bloquer une vraie demande ; une règle trop permissive peut remplir la file d’envoi.

Lire le résultat du transport, pas seulement celui du formulaire

Identifiez le chemin réellement utilisé : envoi local de l’hébergeur, connexion SMTP ou API d’un prestataire. Vérifiez ensuite les réglages de ce seul transport : compte autorisé, méthode d’authentification, serveur, port et chiffrement attendus par le fournisseur. Installer plusieurs extensions d’envoi en même temps complique le diagnostic et peut provoquer des comportements concurrents.

Dans le fonctionnement standard de WordPress, wp_mail_failed signale une exception capturée dans PHPMailer. wp_mail_succeeded indique que son appel d’envoi s’est terminé sans erreur ; il ne confirme pas l’arrivée chez le destinataire. Un service qui intercepte ou met les messages en attente peut suivre un autre circuit : consultez alors ses propres journaux et sa documentation.

Un refus d’authentification, un quota atteint ou une connexion sortante impossible n’appellent pas la même correction. Conservez le code utile et l’identifiant du message, sans publier un journal complet. Les données transmises aux hooks peuvent contenir destinataires, sujet, corps et pièces jointes : ne les affichez pas sur le site et ne les copiez pas telles quelles dans un fichier accessible au public.

Contrôler l’expéditeur et l’authentification du domaine

L’adresse visible dans « De » doit appartenir à un domaine que le service d’envoi est autorisé à utiliser. Pour un formulaire, placez généralement l’adresse du visiteur dans « Répondre à », plutôt que de lui faire porter le rôle d’expéditeur. Cela permet de lui répondre sans prétendre envoyer depuis son domaine.

SPF décrit les services autorisés à envoyer pour le domaine contrôlé ; DKIM ajoute une signature vérifiable. DMARC vérifie notamment l’alignement du domaine visible dans « De » avec un domaine authentifié par SPF ou DKIM. Les deux adresses visibles et de retour n’ont pas à être identiques caractère par caractère pour que cet alignement soit valable.

Avant une modification DNS, inventoriez tous les émetteurs du domaine, gardez les valeurs précédentes et prévoyez le retour arrière. N’ajoutez pas un second enregistrement SPF pour régler seulement WordPress : l’autorisation du nouveau service doit être intégrée à la configuration existante. Une politique DMARC plus stricte peut aussi affecter d’autres outils de l’entreprise. Faites valider ces changements avec le responsable de la messagerie.

Suivre le message jusqu’à la boîte destinataire

Un statut « accepté » chez le prestataire signifie qu’il a pris le message en charge. Un statut de distribution peut confirmer l’acceptation par le serveur distant, sans prouver le placement dans la boîte principale ni la lecture. Cherchez un rejet, un report, une suppression après des échecs antérieurs ou une mise en quarantaine. Gardez le code et l’heure du rebond pour demander une explication précise au fournisseur.

Si le message est accepté mais reste introuvable, vérifiez les indésirables, les règles de classement et la quarantaine avec le destinataire autorisé. Les en-têtes du message reçu permettent de contrôler les résultats SPF, DKIM et DMARC sans deviner à partir du seul écran WordPress. Évitez les séries de tentatives sur une adresse qui rebondit.

Une authentification correcte aide la distribution, mais ne garantit pas la boîte principale. Les exigences du destinataire et la réputation d’envoi comptent aussi. Pour une newsletter ou un volume important, reprenez les règles du fournisseur et les pratiques d’abonnement dans un chantier dédié ; une notification de formulaire ne doit pas servir de test d’envoi massif.

Valider la correction sans multiplier les envois

Modifiez une cause confirmée à la fois. Avant de toucher à une extension ou à sa configuration en production, vérifiez qu’une sauvegarde restaurable et les anciens réglages sont disponibles. Si le site utilise une file d’attente, contrôlez son mécanisme de traitement ; n’attribuez pas systématiquement l’envoi de wp_mail() à une tâche cron.

• Parcours accepté : une seule demande de test déclenche la notification attendue, qui est retrouvée dans la boîte autorisée. La réponse revient au bon interlocuteur.
• Parcours refusé : une erreur de saisie est expliquée et ne provoque ni notification indue ni double soumission.
• Suivi : le statut et l’identifiant permettent de retrouver un échec, avec accès limité et durée de conservation adaptée, sans garder inutilement le contenu des messages.

Une fois la réception confirmée, retirez les traces temporaires sensibles et contrôlez les autres notifications qui utilisent le même transport. Si plusieurs fonctions du site dépendent de cet envoi, la maintenance WordPress doit intégrer leur vérification après chaque changement concerné.

Références officielles

Pour approfondir le comportement de WordPress et les exigences d’authentification, consultez la documentation de wp_mail(), le hook wp_mail_failed, le hook wp_mail_succeeded et les consignes Gmail pour les expéditeurs. Appliquez les instructions correspondant au service réellement utilisé, sans recopier une configuration DNS trouvée pour un autre domaine.