Comment fonctionnent les emails sous WordPress

WordPress est un CMS qui permet de concevoir et facilement gérer un site web. Dans son package, il a diverses fonctionnalités intégrées nativement. Dont une qui est particulièrement plébiscitée, à savoir celle de pouvoir envoyer des emails.

Pourtant, ce système intégré par défaut présente des limites. Dont beaucoup de structures ne peuvent se contenter. Que vous ayez besoin de recevoir ou envoyer des emails depuis votre site web, vous n’avez sans doute pas envie que l’adresse soit ou ressemble à WordPress@votrenomdedomaine.fr ou encore qu’on puisse y voir l’adresse du serveur qui héberge votre site.

C’est pourquoi beaucoup prennent le temps de paramétrer une solution d’emailing avec le protocole SMTP. Qui sécurisé les envois, les réceptions, mais aussi la délivrabilité.

Découvrons aujourd’hui le périmètre du fonctionnement des emails WordPress et comment en sortir.

Le fonctionnement par défaut : la fonction wp_mail()

WordPress n’est pas un logiciel de messagerie email. Pourtant, il envoie des emails en permanence : notification de nouveau commentaire, confirmation de commande WooCommerce, réinitialisation de mot de passe, alerte de mise à jour, message d’un formulaire de contact…

Tout cela repose sur un mécanisme d’envoi natif que la plupart des webmasters ne remettent jamais en question, jusqu’au jour où un client signale qu’il n’a rien reçu. Et si j’écris cet article aujourd’hui, c’est parce que la question des emails WordPress est d’actualité pour plusieurs de mes client.e.s et leur projet.

Comprendre comment WordPress envoie réellement ses emails permet de savoir pourquoi ce système atteint vite ses limites, et ce qu’il faut changer pour le fiabiliser.

Chaque fois qu’un plugin ou le cœur de WordPress doit envoyer un email, il passe par une fonction native, à savoir la fonction : wp_mail(). C’est le point de passage unique, que ce soit pour une notification de commentaire, un email WooCommerce, ou un formulaire Contact Form 7.

En interne, wp_mail() s’appuie sur la bibliothèque PHPMailer, intégrée au cœur de WordPress depuis des années. Par défaut, sans configuration particulière, PHPMailer utilise la fonction mail() de PHP pour transmettre le message. Cette fonction délègue l’envoi à l’agent de transfert de courrier installé sur le serveur (souvent sendmail ou un équivalent), qui se charge ensuite de router le message vers son destinataire.

Ce mécanisme fonctionne, dans le sens où l’email part bien du serveur. Le problème n’est pas là. Il se situe dans la façon dont ce message est perçu une fois arrivé chez le destinataire.

Limites de la fonction mail() PHP

L’envoi via la fonction mail de PHP présente trois faiblesses structurelles, propres à l’hébergement mutualisé sur lequel tourne la grande majorité des sites WordPress :

• Pas d’authentification : le message part sans identifiant ni mot de passe associé à un compte email reconnu. Rien ne prouve au destinataire que l’expéditeur est légitime.
• Une IP partagée et sa réputation collective : le serveur d’envoi héberge en général des centaines, voire des milliers d’autres sites. Si certains ont été compromis ou utilisés pour du spam, la réputation de l’IP s’en trouve dégradée, pour tous les sites qui la partagent, y compris le vôtre.
• Aucune garantie d’intégrité du message : sans signature cryptographique, rien ne certifie que le contenu n’a pas été modifié entre l’envoi et la réception.

Résultat : les serveurs de réception (Gmail, Outlook, Yahoo) appliquent leurs filtres anti-spam sur la base de ces éléments, indépendamment de la qualité du contenu du message. Un email parfaitement rédigé peut atterrir directement en indésirables, simplement parce qu’il a été envoyé de cette façon.

C’est un défaut structurel du mécanisme par défaut, pas une erreur de configuration propre à un site en particulier. Tous les sites WordPress qui n’ont jamais touché à leur configuration d’envoi sont exposés au même risque.

Bref, oui, la fonction existe et il vaut souvent mieux avoir peu, que rien. Jusque là nous sommes d’accord. Et pour un usage personnel et/ou très limité, ça peut faire le job.

Sauf que de nombreuses structures et businesses utilisent de l’emailing accosté à WordPress comme par exemple :

• confirmer une réservation de chambre d’hôte
• confirmer la bonne réception d’une candidature à une offre d’emploi
• confirmer une commande sur un site e-commerce WordPress

Bref, quand il y a des enjeux business, la fonction native d’email WP via PHP, ça suffit rarement.

C’est à ce titre que beaucoup optent pour le protocole SMTP.

Les avantages du SMTP authentifié

La solution consiste à remplacer l’envoi natif de PHP par un envoi via un serveur SMTP authentifié (via un plugin comme WP Mail SMTP ou Easy WP SMTP, connecté à un fournisseur comme Brevo, Mailjet, SendGrid ou Amazon SES). Par rapport au fonctionnement par défaut, les bénéfices sont directs :

• Un envoi authentifié : chaque email passe par un compte identifié, avec ses propres identifiants, au lieu de partir anonymement depuis le serveur d’hébergement.
• Une réputation d’envoi propre, indépendante de l’IP mutualisée : le fournisseur SMTP gère sa propre infrastructure d’envoi, distincte et surveillée, ce qui limite l’impact des autres sites hébergés sur le même serveur.
• Une meilleure traçabilité : la plupart des fournisseurs SMTP proposent un suivi de la délivrabilité (envoyé, ouvert, rejeté), ce que la fonction mail() de PHP ne permet pas.
• Une fiabilité accrue : moins d’échecs d’envoi silencieux, un point de défaillance identifiable en cas de problème.

Concrètement, la mise en place suit ces étapes : installer un plugin SMTP, choisir un fournisseur, renseigner les identifiants (serveur, port, méthode de chiffrement, identifiant et mot de passe d’application), envoyer un email de test depuis l’interface du plugin, puis vérifier en conditions réelles avec un vrai formulaire ou une vraie commande.

Le protocole SMTP est un protocole relativement connu, fiable et éprouvé. Par ailleurs, la plupart des hébergeurs web, notamment français, proposent des tutoriels et technologies embarquées qui permettent de facilement configurer une adresse email et ensuite sont comportement. Du moment de la création de votre adresse jusqu’aux premiers tests d’envoi.

Il existe même des outils (prenons le cas d’o2switch) qui permettent d’installer votre adresse email fonctionnant via SMTP, directement sur votre Outlook ordinateur ou sur Android pour téléphone et iOs pour les iPhones.

Tester le smtp

Une fois votre adresse email créée et votre protocole SMTP configuré, il convient de vérifier vos paramétrages. Faîtes toujours un test d’envoi et de réception avant de communiquer votre adresse 😉

Le but est de vous assurer que tout est ok, le mieux reste de tester votre serveur SMTP.

Pour avoir longtemps travaillé dans une entreprise de téléphonie française (environ 17 ans), j’ai souvent entendu des personnes qui travaillaient au support DATA. Ces personnes passaient de longues minutes au téléphone à aider des client.e.s professionnel.l.e.s à paramétrer le protocole SMTP sur leur téléphone/smartphone. Et quand tout se passe bien, viennent les tests concluants qui confirment que tout est ok 🙂 !

Ce que le SMTP ne règle pas à lui seul

Le SMTP authentifié est une condition nécessaire, mais pas suffisante. Trois éléments DNS complètent le dispositif :

• le SPF déclare quels serveurs sont autorisés à envoyer des emails pour votre domaine
• le DKIM signe cryptographiquement chaque email pour prouver qu’il n’a pas été altéré en chemin
• le DMARC indique aux serveurs de réception quoi faire si SPF ou DKIM échouent, et permet de recevoir des rapports sur les tentatives d’usurpation

Sans ces trois enregistrements, configurés dans la zone DNS du domaine, même un envoi SMTP bien paramétré peut continuer à être filtré, en particulier depuis que Gmail et Yahoo ont durci leurs exigences d’authentification en 2024 pour tout expéditeur envoyant un volume significatif d’emails.

Cela ne vous est d’ailleurs sans doute pas étranger. Pour de nombreux comptes emails, depuis 2024, il faut aller rajouter ces marqueurs DKIM, SPF et DMARC à vos paramétrages historiques déjà en place.

Bref !

Le fonctionnement par défaut de WordPress envoie les emails sans authentification depuis une IP partagée, ce qui explique la majorité des problèmes de délivrabilité. Tandis que le protocole SMTP authentifié corrige ce point précis, mais doit être complété par SPF, DKIM et DMARC pour que vos emails arrivent réellement à destination.

Toutefois, ne mettons pas tous les torts sur la fonctionnalité native de WordPress. Elle reste un socle important pour le quotidien et la vie de nos sites WordPress. Elle nous permet d’être prévenu.e des soucis sur le sites, des mises à jour forcées à distance ou à faire… Bref, dans divers cas, elle peut aussi suffire ! 🙂