Envoyer des courriels transactionnels fiables depuis un site PHP

Un client passe commande, il ne reçoit pas sa confirmation. Un visiteur demande la réinitialisation de son mot de passe, le message n'arrive jamais. Un formulaire de contact fonctionne parfaitement en apparence et le commercial ne voit rien arriver. Ces situations partagent une même cause profonde : le mécanisme d'envoi le plus simple du langage utilisé par la plupart des sites n'est pas conçu pour délivrer des messages de façon fiable. Le problème n'est presque jamais dans le code applicatif, il est dans la façon dont le message quitte le serveur et dans la manière dont les fournisseurs de messagerie le jugent à l'arrivée. Nous détaillons ici l'origine du phénomène, la solution qui règle durablement la question et les vérifications qui permettent de savoir où en sont réellement les envois.

Pourquoi les courriels d'un site se perdent

Le trajet d'un message comporte plusieurs étapes, et chacune peut le faire disparaître sans qu'aucune erreur ne remonte au site. Le protocole qui régit ces échanges, ses commandes et ses codes de réponse sont présentés dans notre article sur la définition du SMTP. La particularité de ce protocole est qu'un message peut être accepté par un serveur, puis silencieusement écarté plus loin.

La fonction d'envoi intégrée et ses limites

Le langage propose une fonction d'envoi en une ligne, ce qui explique son usage universel. Cette fonction ne fait qu'une chose : elle remet le message au programme d'envoi local du serveur et renvoie une confirmation de remise. Cette confirmation ne signifie pas que le message a été délivré, seulement qu'il a été accepté par le programme local. Toute la suite du trajet échappe complètement à l'application, y compris les rejets. Un site peut ainsi afficher des envois réussis pendant des mois alors qu'aucun message n'arrive. Cette confusion entre remise locale et délivrance constitue la première source de malentendu.

La réputation de l'adresse du serveur

Les fournisseurs de messagerie jugent un message d'abord sur l'adresse réseau qui l'envoie. Un hébergement mutualisé partage cette adresse entre des centaines de sites, dont certains envoient des messages non sollicités. La réputation de l'ensemble se dégrade et tous les sites hébergés en subissent les conséquences. Cette situation échappe totalement au propriétaire du site, qui n'a rien fait de répréhensible. Elle explique pourquoi un même code fonctionne chez un hébergeur et pas chez un autre. C'est la raison structurelle qui rend l'envoi direct depuis le serveur du site peu fiable.

L'absence d'autorisation d'envoi

Un message prétendant venir d'un domaine doit pouvoir être vérifié, faute de quoi n'importe qui pourrait envoyer des courriels en se faisant passer pour lui. Le mécanisme qui déclare les serveurs autorisés à envoyer pour un domaine est expliqué dans notre article sur la définition du SPF. Sans cette déclaration, ou avec une déclaration qui ne mentionne pas le serveur réellement utilisé, les fournisseurs classent le message comme suspect. Cette configuration est absente sur une grande partie des domaines professionnels. Elle se corrige en quelques minutes et elle produit un effet immédiat. C'est la première vérification à mener face à un problème de réception.

L'absence de signature

Une signature cryptographique apposée au message permet au destinataire de vérifier qu'il n'a pas été modifié en route et qu'il vient bien du domaine annoncé. Ce mécanisme complète le précédent et il est aujourd'hui attendu par tous les grands fournisseurs. Un message non signé n'est pas systématiquement rejeté, il part avec un handicap. Combiné à d'autres signaux défavorables, ce handicap suffit à basculer vers le dossier des indésirables. La mise en place demande la publication d'une clé dans la configuration du domaine. Elle est prise en charge automatiquement par les services d'envoi spécialisés.

Le contenu du message

Les filtres analysent également le message lui même : proportion de texte et d'images, présence de liens raccourcis, vocabulaire commercial, absence de version en texte simple. Un message de confirmation composé d'une seule grande image, sans texte, présente tous les signaux d'un envoi indésirable. Cette dimension est souvent négligée au profit des seules questions techniques. Elle explique les cas où la configuration est parfaite et les messages arrivent malgré tout en indésirables. Corriger le contenu coûte peu et améliore sensiblement la situation. Les bonnes pratiques sont stables depuis des années.

L'absence de retour d'information

Lorsqu'un message est rejeté, le serveur destinataire renvoie une notification à l'adresse d'expédition. Si cette adresse n'existe pas ou n'est lue par personne, l'information se perd et le problème reste invisible. Beaucoup de sites envoient depuis une adresse fictive, ce qui supprime toute possibilité de diagnostic. Utiliser une adresse réelle, relevée régulièrement, change complètement la capacité à détecter les incidents. C'est une correction triviale qui apporte une visibilité immédiate. Elle constitue le point de départ de tout travail sérieux sur la délivrabilité.

Passer par un service d'envoi

La solution qui règle la majorité des problèmes consiste à ne plus envoyer depuis le serveur du site mais à confier les messages à un service spécialisé.

Le principe

Le site se connecte à un serveur d'envoi externe, avec des identifiants, et lui remet le message. Ce service dispose d'adresses réseau dédiées à la messagerie, avec une réputation entretenue, et il applique les signatures nécessaires. Le taux de délivrance passe typiquement de soixante-dix à plus de quatre-vingt-quinze pour cent sans modification du contenu. Cette bascule constitue le levier le plus efficace de tout le sujet. Elle demande une configuration initiale d'une heure environ. Elle supprime également la dépendance à la qualité de l'hébergement.

Les offres disponibles

Plusieurs services proposent des paliers gratuits couvrant quelques milliers de messages par mois, ce qui suffit à la plupart des sites vitrines et à beaucoup de petits sites marchands. Au delà, les tarifs restent modestes, de l'ordre de quelques dizaines d'euros pour des volumes importants. Le choix se fait sur la qualité de la documentation, la présence de statistiques détaillées et la localisation des serveurs. Pour une entreprise européenne, un service hébergé en Europe simplifie les questions de traitement des données. Comparer deux ou trois offres sur un mois d'essai reste la méthode la plus sûre. Les différences de délivrabilité entre services sérieux restent faibles.

La configuration côté site

La bascule se fait en remplaçant l'appel à la fonction native par une bibliothèque d'envoi configurée avec les identifiants du service. Sur les systèmes de gestion de contenu courants, une extension dédiée effectue ce remplacement sans toucher au code. Les identifiants doivent être stockés en dehors du code source, dans un fichier de configuration non versionné. Un point de vigilance concerne les extensions qui envoient leurs propres messages sans passer par le mécanisme central. Vérifier que tous les envois transitent bien par le service constitue une étape indispensable. Un test par type de message couvre cette vérification.

La configuration côté domaine

Le service fournit des enregistrements à publier dans la configuration du nom de domaine : autorisation d'envoi, clés de signature et parfois un sous domaine dédié. Ces enregistrements doivent être ajoutés avec soin, une erreur de saisie annulant tout le bénéfice. La propagation prend de quelques minutes à quelques heures. Le service propose généralement un bouton de vérification qui confirme la bonne configuration. Ne pas franchir cette étape revient à utiliser le service sans profiter de sa réputation. C'est pourtant une omission fréquente.

La séparation des flux

Les messages transactionnels, attendus par le destinataire, ne doivent pas partir par le même canal que les envois marketing. Un désabonnement massif sur une campagne dégraderait la réputation du canal et pénaliserait les confirmations de commande. Utiliser un sous domaine distinct pour chaque flux isole les réputations. Cette séparation est proposée par tous les services sérieux et elle est trop rarement mise en place. Elle protège précisément les messages dont la non réception coûte le plus cher. Sa mise en œuvre ne demande qu'une déclaration supplémentaire.

La file d'attente

Envoyer le message directement pendant le traitement de la requête ralentit la réponse au visiteur et fait échouer l'opération si le service est indisponible. Placer les envois dans une file traitée en arrière plan supprime ces deux inconvénients. Le client voit sa commande confirmée immédiatement, le message part quelques secondes plus tard. En cas d'indisponibilité, les messages s'accumulent et partent au rétablissement plutôt que d'être perdus. Ce mécanisme se met en place avec les outils de tâches planifiées du système. Il constitue la différence entre un envoi qui fonctionne et un envoi qui résiste aux incidents.

Soigner le contenu et la présentation

La qualité technique de l'envoi ne suffit pas si le message lui même présente les caractéristiques d'un courrier indésirable.

Le couple expéditeur et objet

Le nom d'expéditeur doit être celui de l'entreprise, reconnaissable au premier coup d'œil dans une liste de messages. L'adresse doit appartenir au domaine du site et non à un service tiers, sous peine de brouiller l'identification. L'objet doit annoncer précisément le contenu, sans majuscules excessives ni points d'exclamation multiples. Un objet indiquant simplement la nature du message et la référence de commande fait parfaitement l'affaire. Ces détails déterminent une part importante du taux d'ouverture réel. Ils constituent aussi les premiers éléments examinés par les filtres.

La version en texte simple

Tout message mis en forme doit être accompagné d'une version en texte brut, contenant la même information. Cette version sert aux clients de messagerie qui n'affichent pas la mise en forme et elle constitue un signal de sérieux pour les filtres. Son absence est l'un des motifs de classement défavorable les plus fréquents. Les bibliothèques d'envoi produisent cette version automatiquement si on le leur demande. Vérifier son contenu reste utile, la conversion automatique produisant parfois un résultat illisible. Cette vérification prend deux minutes par gabarit.

L'équilibre entre texte et images

Un message composé uniquement d'images ne peut être analysé par aucun filtre, ce qui conduit à un classement prudent. Il devient également illisible pour les destinataires dont le client bloque le chargement des images par défaut. La règle pratique consiste à ce que l'information essentielle figure en texte, les images n'ayant qu'un rôle d'illustration. Un attribut alternatif doit accompagner chaque image. Cette contrainte améliore simultanément la délivrabilité et l'accessibilité. Elle simplifie aussi considérablement la maintenance des gabarits.

Les liens et leur apparence

Les liens doivent pointer vers le domaine du site, en clair, sans passer par un service de raccourcissement. Un lien raccourci masque sa destination, comportement typique des messages malveillants. Les liens de suivi, s'ils sont nécessaires, doivent utiliser un sous domaine du site plutôt qu'un domaine tiers. Le nombre de liens doit rester raisonnable, un message transactionnel n'ayant généralement besoin que de deux ou trois. Cette sobriété améliore la délivrabilité et la lisibilité. Elle réduit également le risque qu'un lien casse dans le temps.

La compatibilité entre clients de messagerie

Les logiciels de messagerie interprètent la mise en forme de façon très inégale, certains ignorant des propriétés pourtant standard depuis des années. Un gabarit construit comme une page web moderne s'affichera correctement dans la moitié des cas seulement. Les gabarits fiables reposent sur des structures simples, avec une mise en page en colonnes classique. Des services de prévisualisation permettent de contrôler le rendu sur les principaux clients. Investir dans deux ou trois gabarits solides, réutilisés pour tous les messages, vaut mieux que d'en créer un par cas. Cette bibliothèque se constitue une fois et sert des années.

L'authentification et son alignement

Les mécanismes de vérification exigent une cohérence entre le domaine affiché comme expéditeur et celui qui signe le message. La signature cryptographique et son fonctionnement sont détaillés dans notre article sur la définition du DKIM. Un défaut d'alignement, fréquent lorsque le service d'envoi utilise son propre domaine, réduit fortement le bénéfice de la configuration. Le contrôle se fait en examinant les en-têtes d'un message reçu, où figurent les résultats des vérifications. Cette lecture demande un peu d'habitude et elle est décisive pour un diagnostic. Elle permet de savoir en trente secondes si la configuration est correcte.

Vérifier et surveiller dans la durée

Un dispositif d'envoi fonctionne rarement mal dès le premier jour : il se dégrade, et sans surveillance cette dégradation reste invisible.

Tester sur plusieurs fournisseurs

Les grands fournisseurs de messagerie appliquent des politiques différentes, et un message accepté par l'un peut être écarté par un autre. Créer des adresses de test chez les trois ou quatre fournisseurs les plus utilisés par les clients permet un contrôle réaliste. Ce test doit être refait après chaque modification de gabarit ou de configuration. Des services spécialisés automatisent cette vérification et fournissent un score détaillé. Une vérification manuelle trimestrielle suffit sur un site à faible volume. Elle prend un quart d'heure et elle évite les mauvaises surprises.

Lire les statistiques du service

Le service d'envoi fournit les taux de délivrance, de rejet définitif, de rejet temporaire et de plainte. Un taux de rejet définitif supérieur à deux pour cent signale un problème de qualité des adresses collectées. Un taux de plainte supérieur à un pour mille appelle une action immédiate, ce seuil étant celui à partir duquel les fournisseurs réagissent. Ces indicateurs sont disponibles sans effort et rarement consultés. Un coup d'œil mensuel suffit à détecter une dérive. Il permet d'agir avant que la réputation ne se dégrade durablement.

Traiter les adresses invalides

Une adresse qui rejette définitivement doit être retirée des envois futurs, sous peine de dégrader la réputation à chaque tentative. Les services proposent une liste de suppression automatique qu'il faut penser à synchroniser avec la base du site. Sur un site marchand, une adresse invalide signale aussi un client injoignable, information commercialement utile. Prévoir un traitement de ces retours, même manuel au début, évite l'accumulation. Cette hygiène de base est ce qui distingue les expéditeurs sérieux des autres. Elle demande peu de temps une fois organisée.

Mettre en place les rapports d'authentification

Une déclaration complémentaire dans la configuration du domaine permet de recevoir des rapports quotidiens sur les messages envoyés en votre nom. Ces rapports révèlent les envois légitimes mal configurés et les tentatives d'usurpation. Ils arrivent dans un format technique qui demande un outil de lecture, plusieurs services proposant cette analyse gratuitement pour de petits volumes. Commencer en mode observation, sans politique restrictive, permet de découvrir tous les flux avant de durcir. Cette découverte réserve presque toujours des surprises. Elle constitue le préalable à toute politique de rejet.

Journaliser les envois côté site

Conserver la trace de chaque message envoyé, avec son destinataire, son type et son horodatage, permet de répondre à une réclamation. Sans cette trace, il est impossible de savoir si le message a réellement été émis. La conservation doit rester limitée dans le temps et exclure le contenu détaillé lorsqu'il comporte des données personnelles. Un identifiant permettant de retrouver le message dans les journaux du service suffit généralement. Cette journalisation se code en quelques lignes. Elle rend le service client beaucoup plus efficace.

Prévoir le contrôle après chaque changement

Un changement d'hébergeur, une migration de domaine, une mise à jour majeure ou l'ajout d'une extension peuvent casser silencieusement la configuration d'envoi. Ajouter un test d'envoi à la liste des vérifications post-déploiement évite de découvrir le problème par une réclamation client. Ce test peut être automatisé, un message envoyé vers une adresse de contrôle après chaque mise en ligne. La surveillance de la réception effective demande un peu plus de travail et elle se justifie sur les sites marchands. Le coût d'une confirmation de commande non reçue dépasse largement celui de cette vérification. C'est un investissement de tranquillité.