Livrer un site client : les vérifications email à faire avant la mise en ligne

Le site passe en production, le client valide, la facture part. 3 semaines plus tard, un message arrive : « on ne reçoit plus rien depuis le formulaire ». Le ticket revient au prestataire hors devis. La conversation glisse vite vers le reproche. La partie email d'un site livré occupe une zone grise entre le développement et l'infrastructure, donc personne ne la traite vraiment. Elle se contrôle pourtant en une heure, avant la recette, avec une liste courte.

Qui reçoit quoi : cartographier les adresses avant d'écrire la première ligne

Un site vitrine ordinaire fait circuler 4 ou 5 adresses distinctes, rarement listées au même endroit. L'adresse technique d'expédition, celle qui apparaît en From sur les messages sortants. L'adresse de réponse, sur laquelle le visiteur clique quand il répond. Le ou les destinataires des notifications de formulaire. L'adresse de l'administrateur WordPress, qui reçoit les alertes de mise à jour. Sur une boutique s'ajoutent les adresses des messages transactionnels et celle du gestionnaire de commandes.

Ces adresses vivent dans des réglages différents : les options générales du CMS, la configuration du plugin de formulaire, les réglages de la boutique, parfois une constante en dur dans le thème. Un tableau de 5 lignes validé par écrit au démarrage évite la moitié des surprises de livraison. La question à poser tient en une phrase : quelle adresse doit recevoir quoi et qui ouvre cette boîte tous les jours.

L'adresse de destination des formulaires vieillit pendant le projet

Quand le brief est signé, le client donne une adresse de contact, souvent celle du salarié qui pilote le projet ce jour-là. Entre la signature et la mise en ligne, il s'écoule 3 à 6 mois sur un projet de taille moyenne. Le salarié change de poste, l'alias disparaît du serveur, l'adresse fournie au départ était une boîte personnelle remplacée depuis par une adresse au domaine de l'entreprise. Le formulaire, lui, continue de pointer vers la valeur saisie au démarrage.

L'envoi ne signale rien. La fonction wp_mail rend la main dès que le message est remis au serveur d'envoi. Le plugin affiche sa confirmation au visiteur dans la foulée. Le refus arrive plus tard, côté serveur du destinataire : la RFC 3463 réserve le code 5.1.1 au cas où la boîte indiquée n'existe pas, un échec permanent. Ce refus part vers l'adresse d'enveloppe, qui sur un site mal configuré n'est lue par personne.

Le scénario coûteux est celui où tout fonctionne à l'écran et où le message revient en rebond dur parce que la boîte a disparu entre le devis et la livraison. Le plus simple reste de tester une adresse mail au moment de la recette, pour confirmer que la boîte du client existe et accepte les messages avant que le formulaire parte en production.

L'adresse d'expédition : le domaine du client plutôt que celui de l'hébergeur

Envoyer les messages d'un site depuis le domaine de l'hébergeur revient à emprunter la réputation d'un tiers. Le manuel d'administration avancée de WordPress décrit le comportement par défaut : le wrapper remplit le champ From avec wordpress@nom-de-domaine et confie l'envoi à la fonction mail() de PHP. Sur un mutualisé, le message part donc avec une adresse d'enveloppe rattachée au compte d'hébergement, depuis une IP partagée avec des dizaines d'autres sites dont vous ne saurez jamais ce qu'ils envoient.

2 mécanismes se déclenchent alors. La RFC 7208 définit SPF comme une validation du domaine annoncé en MAIL FROM, l'adresse d'enveloppe, sans aucun contrôle sur le champ From que le destinataire voit à l'écran. La RFC 7489 ajoute la notion d'alignement d'identifiants : le domaine du champ From doit correspondre au domaine validé par SPF ou par DKIM. Un message qui affiche une adresse au domaine du client tout en transitant par le serveur d'envoi de l'hébergeur échoue à cet alignement tant que rien ne signe pour le domaine du client.

Les consignes aux expéditeurs de Google demandent depuis le 1er février 2024 que tout expéditeur configure SPF ou DKIM sur ses domaines d'envoi et publie des enregistrements DNS directs et inverses valides pour l'IP d'envoi. Ces 2 points échappent au prestataire dès lors que l'envoi sort du domaine de l'hébergeur. Router les messages du site vers un service d'envoi authentifié sur le domaine du client les ramène dans le périmètre du projet et rend la réputation lisible : elle appartient au client et se mesure domaine par domaine.

Authentification du domaine client : ce qu'on demande à l'hébergeur en une passe

Groupez les demandes en un seul message à l'interlocuteur qui tient la zone DNS : l'include SPF du service d'envoi retenu, la publication du sélecteur DKIM avec sa clé, un enregistrement DMARC en p=none avec une adresse de rapport et la confirmation écrite que la zone fait autorité. Un seul aller-retour. Le détour par 4 tickets étalés sur 2 semaines coûte plus cher que la configuration.

Les seuils des fournisseurs visent les gros volumes. Google impose SPF, DKIM et DMARC alignés au-delà de 5 000 messages par jour vers des comptes Gmail. Microsoft rejette depuis le 5 mai 2025 les envois non authentifiés au-delà du même volume quotidien vers outlook.com, hotmail.com et live.com. Un site vitrine n'atteindra jamais ces chiffres. L'alignement reste la raison de faire le travail.

La recette : ce qu'on teste réellement et vers quelles boîtes

Si la recette se résume à un envoi vers sa propre boîte pro, elle ne prouve presque rien : le message part d'un domaine connu vers un serveur qui accepte déjà tout ce qui vient de vous. 3 destinations au minimum : un compte Gmail, une boîte Outlook.com et une adresse hébergée sur le domaine du client lui-même. 

Ces 3 environnements appliquent des politiques différentes, avec chacun ses pannes propres et sans lien avec le site testé : on peut un jour ne plus recevoir ses mails sur Gmail, ou à l'inverse recevoir des mails sans pouvoir en envoyer avec Outlook. L'écart entre ces environnements est justement ce qui renseigne.

Passez par le formulaire public plutôt que par le bouton « envoyer un email de test » du plugin, les 2 chemins ne traversent pas le même code. Vérifiez le dossier de réception, l'adresse affichée en expéditeur et le sujet, puis répondez au message pour voir où atterrit la réponse. Regardez aussi le nom d'expéditeur affiché : un site livré qui signe « WordPress » à la place du nom commercial du client fait mauvais effet dès le premier accusé de réception. Ouvrez les en-têtes du message reçu et lisez la ligne d'authentification : spf, dkim et dmarc doivent y apparaître en pass. Sur une boutique, refaites le parcours avec une commande de test complète, le circuit transactionnel emprunte souvent une autre route que le formulaire de contact.

2 cas de bord méritent 5 minutes de plus. Un message rempli avec des accents et une apostrophe dans le nom, pour valider l'encodage jusqu'au client de messagerie. Puis un envoi vers une adresse volontairement inexistante sur le domaine du client, pour voir où atterrit le rebond : si personne ne surveille cette boîte, les échecs resteront invisibles pendant des mois.

Reste un contrôle que beaucoup sautent, alors qu'il tient en une requête DNS : les enregistrements MX du domaine du client. La RFC 5321 prévoit qu'en l'absence de MX, l'adresse est traitée comme un MX implicite de préférence 0 pointant vers l'hôte lui-même. Sur un domaine dont l'enregistrement A pointe vers le serveur web mutualisé, les messages adressés au client arrivent donc dans une boîte locale du serveur, que personne n'ouvre. Le formulaire fonctionne, les logs sont propres, le client ne reçoit rien.

Ce qu'on documente pour ne pas être rappelé dans 6 mois

Ce qui revient en support un an plus tard tient presque toujours à une ligne jamais écrite. Une annexe d'une page suffit : la liste des adresses et de leur rôle, l'emplacement exact de chaque réglage avec une capture d'écran, la route d'envoi utilisée et le compte associé, les enregistrements DNS ajoutés avec la date et le nom de la personne qui les a publiés. Le document sert d'abord au prestataire : il rend vérifiable ce qui a été livré, ligne par ligne, le jour où le client conteste.

Ajoutez la procédure de changement d'adresse de destination, écrite pour quelqu'un qui n'est pas développeur. C'est la seule opération que le client fera seul. C'est aussi celle qui casse tout quand elle est faite au mauvais endroit. Précisez que la zone DNS appartient au client : le jour où il change d'hébergeur ou de prestataire, les enregistrements le suivent, à condition que quelqu'un sache qu'ils existent.

Un dernier point tient en une ligne de contrat : la surveillance. Un envoi de test mensuel vers 2 boîtes externes rend visible une panne qui autrement passe inaperçue jusqu'au premier client perdu. Le prestataire qui pose ce garde-fou à la livraison ne récupère pas le ticket 6 mois plus tard.