E-mail depuis votre site web et les formulaires

Module 7: Newsletters et e-mails depuis votre site · Temps de lecture : 11 minutes

Objectif pédagogique : après cette leçon, vous saurez configurer le courrier de votre site web (formulaires de contact, confirmations de commande, notifications WordPress) de façon à ce qu'il arrive à destination, ne pose pas de problème DMARC et ne permette pas qu'on abuse de votre offre.

Notions clés : PHP mail(), SMTP avec authentification, expéditeur d'enveloppe, From vs. Reply-To, ne jamais mettre l'adresse du visiteur en From, plugin SMTP, e-mail transactionnel, spam de formulaire, captcha, honeypot, limite d'envoi, remise locale alors que le MX pointe ailleurs

Votre site web est aussi un programme de messagerie

Votre site web envoie plus de courrier que vous ne le pensez. Un formulaire de contact vous envoie chaque message. Une boutique en ligne envoie des confirmations de commande, des factures et des avis d'expédition. WordPress envoie un e-mail en cas de nouveau commentaire, de mise à jour ou de réinitialisation de mot de passe. Pour le destinataire, il s'agit tout simplement d'un e-mail provenant de votre domaine, et il est contrôlé aussi strictement que le courrier issu de votre boîte mail : SPF, DKIM, DMARC, réputation.

Pourtant, le courrier du site web échoue plus souvent que le courrier ordinaire. Cela tient généralement à l'un de ces trois éléments : la méthode d'envoi, l'adresse d'expéditeur, ou l'abus du formulaire.

Méthode 1 : PHP mail()

La méthode la plus simple pour un site web d'envoyer du courrier est la fonction PHP mail(). Le site transmet alors directement l'e-mail au programme de messagerie du serveur web, sans authentification. Cela fonctionne généralement, mais présente des inconvénients :

• L'expéditeur d'enveloppe (Return-Path) devient souvent le compte système de votre offre, par exemple gebruiker@server.hosting.example, et non votre adresse. SPF est alors vérifié pour le domaine du serveur, ce qui n'est donc pas aligné avec votre domaine From (leçon 7.1).
• La présence ou non d'une signature DKIM de votre domaine dépend du serveur. Sur certains serveurs oui, sur d'autres non.
• Vous ne voyez rien revenir. Si l'e-mail n'arrive pas ou que vous recevez un bounce, celui-ci part vers le compte système, que personne ne consulte.
• Aucune limite par formulaire. Si le formulaire fait l'objet d'un abus, le serveur envoie en votre nom jusqu'à atteindre la limite de votre offre.

Méthode 2 : SMTP avec authentification (préférable)

Faites en sorte que votre site envoie comme le fait votre programme de messagerie : en s'authentifiant sur le serveur de messagerie sortant avec une véritable boîte mail, via le port 587 (STARTTLS) ou 465 (SSL/TLS), avec l'adresse e-mail complète comme nom d'utilisateur (leçon 1.4 et 2.1). Dans ce cas :

• l'expéditeur d'enveloppe est votre adresse et l'e-mail est signé comme un e-mail ordinaire de votre domaine ;
• les bounces arrivent dans une boîte mail que vous pouvez consulter ;
• l'e-mail envoyé se retrouve, si vous le souhaitez, dans le dossier Envoyé ;
• vous pouvez définir une limite d'envoi propre à chaque boîte mail.

Dans WordPress, vous procédez à l'aide d'un plugin SMTP. Celui-ci remplace la fonction d'envoi standard de WordPress par un envoi via SMTP. Vous renseignez les mêmes informations que dans un programme de messagerie : serveur, port, sécurité, nom d'utilisateur et mot de passe. Créez de préférence pour cela une boîte mail séparée, par exemple website@example.com. Si le mot de passe venait à être volé, votre propre boîte mail reste en sécurité, et vous voyez en un coup d'œil quel courrier provient du site.

Pour un site PHP sur mesure, il existe des bibliothèques qui envoient via SMTP, comme PHPMailer. Placez le mot de passe dans un fichier de configuration situé en dehors du répertoire web, pas dans le code d'une page.

Chez WebOké, les informations SMTP figurent dans le guide DirectAdmin 8.1, avec le nom du serveur de votre offre ; chez d'autres prestataires, elles se trouvent dans le guide ou l'e-mail de bienvenue, et cela fonctionne de la même manière.

Beaucoup d'e-mails transactionnels ? Utilisez un service dédié

Si vous envoyez des centaines de confirmations de commande par jour, un service transactionnel devient rentable : un service d'envoi dédié aux e-mails automatiques. Il dispose d'une bonne réputation et montre ce qui est advenu de chaque e-mail. Vous reliez le domaine comme pour un service de newsletter (DKIM via CNAME, leçon 7.1). Gardez les e-mails transactionnels et les newsletters séparés : une campagne qui échoue ne doit pas affecter l'e-mail de confirmation de vos commandes.

La règle d'or : l'adresse du visiteur n'est jamais l'expéditeur

Dans un formulaire de contact, il est tentant de faire envoyer l'e-mail "de la part" du visiteur. Vous pouvez alors cliquer directement sur Répondre dans votre programme de messagerie. Cela se présente ainsi :

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Mais votre serveur n'a absolument pas le droit d'envoyer au nom de example.net. Supposons que example.net applique une politique DMARC p=reject. Le serveur destinataire (le vôtre, ou celui de Gmail si vous redirigez votre courrier) voit un e-mail avec un From example.net qui ne passe pas via SPF ou DKIM de example.net, et le refuse. De nombreux grands domaines de messagerie appliquent une politique stricte : lors d'un contrôle effectué le 8 novembre 2026, yahoo.com, aol.com, ziggo.nl et kpnmail.nl avaient notamment une politique DMARC p=reject, et icloud.com, gmx.de et web.de une politique p=quarantine. Un visiteur disposant d'une telle adresse remplit votre formulaire, et vous ne recevez jamais le message, ou alors il atterrit dans votre dossier spam. Les domaines avec p=none (comme à ce moment là gmail.com et hotmail.com) peuvent durcir leur politique à tout moment, et Google indique explicitement dans ses consignes qu'il est interdit d'imiter des adresses Gmail en tant que From. Ne comptez donc jamais sur le fait que cela se passera bien.

La bonne méthode :

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

L'expéditeur est votre propre adresse, de sorte que SPF, DKIM et DMARC sont corrects. L'adresse du visiteur figure dans Reply-To. Si vous cliquez sur Répondre, votre réponse part vers Pieter. Dans la plupart des plugins de formulaire, vous trouverez cela dans les paramètres de l'e-mail : indiquez dans Expéditeur (From) une adresse fixe de votre propre domaine, et dans Reply-To le champ dans lequel le visiteur saisit son adresse.

Protéger les formulaires contre les abus

Un formulaire sans protection finit tôt ou tard par être repéré par des robots. Dans le meilleur des cas, vous recevez du spam. Dans le pire des cas, ils l'exploitent pour envoyer du spam à d'autres : si votre formulaire envoie une confirmation à "l'adresse saisie par le visiteur", un robot peut y saisir n'importe quelle adresse au monde, avec un texte libre dans le message. Votre domaine envoie alors du spam, avec toutes les conséquences sur votre réputation (leçon 5.2).

Protection par couches :

• Captcha ou une vérification invisible (comme reCAPTCHA ou Turnstile) arrête la plupart des robots.
• Honeypot : un champ caché que les humains ne voient pas et que les robots remplissent. Rempli ? Le message n'est alors pas envoyé.
• Pas de texte libre dans une confirmation au visiteur, ou pas de confirmation du tout vers l'adresse saisie. Un simple message "Merci, nous avons bien reçu votre message" sur la page suffit.
• Une limite d'envoi par boîte mail pour la boîte mail du site web, inférieure à celle de votre offre.
• Mettre à jour les logiciels. Les vieux plugins constituent une porte d'entrée connue pour les abus.

Vous remarquez que votre offre envoie soudainement beaucoup de courrier, ou vous recevez une notification indiquant que la limite journalière est atteinte alors que vous envoyez vous-même peu de courrier ? Modifiez alors immédiatement les mots de passe et vérifiez quel formulaire ou script envoie le courrier (leçon 3.4).

Le courrier est ailleurs, le site web est ici

Un piège fréquent : votre site web se trouve chez un prestataire, votre courrier chez un autre (par exemple Microsoft 365 ou Google Workspace). Votre MX pointe vers cet autre prestataire. Mais le serveur web pense encore qu'il gère lui-même le courrier de votre domaine, car le domaine figure aussi sur sa propre offre. Il remet alors localement le courrier du formulaire vers info@example.com, dans une boîte mail sur le serveur web que personne ne consulte, ou il renvoie une erreur du type 550 ... mailbox unavailable.

La solution consiste à indiquer dans le panneau du serveur web que le courrier est géré ailleurs. Dans DirectAdmin chez WebOké, il s'agit de la case "Utiliser ce serveur pour gérer mes e-mails" sous Enregistrements MX (à désactiver). D'autres panneaux disposent de paramètres comparables, comme "routage e-mail : externe" dans cPanel. Mieux encore : faites envoyer le courrier du site web via SMTP avec une boîte mail chez le prestataire qui héberge réellement votre courrier.

Résumé

• Le courrier du site web est contrôlé aussi strictement que le courrier ordinaire. Faites envoyer le site via SMTP avec authentification, pas via mail().
• Utilisez une boîte mail séparée pour le site web, avec sa propre limite d'envoi.
• L'adresse du visiteur doit figurer dans Reply-To, jamais dans From. Sinon, DMARC échoue, et pour les domaines avec p=reject (comme yahoo.com, ziggo.nl, kpnmail.nl), l'e-mail est refusé.
• Protégez les formulaires avec captcha, honeypot et sans confirmations en texte libre vers les adresses saisies.
• Si votre courrier est hébergé chez un autre prestataire, désactivez la remise locale sur le serveur web ou envoyez via SMTP chez ce prestataire.

Quiz

Exercice

Exercice O7.3 : Vérifier les e-mails du site web. Remplissez un formulaire sur votre propre site web avec une adresse Gmail ou Outlook.com comme expéditeur et examinez les en-têtes du message qui vous parvient. Répondez à la liste de vérification : quelle adresse figure dans From, l'adresse du visiteur figure-t-elle dans Reply-To, que disent spf=, dkim= et dmarc= dans Authentication-Results, votre site envoie-t-il via SMTP ou via mail(), et le formulaire dispose-t-il d'un captcha ou d'un honeypot ? Si vous n'avez pas de site web personnel, répondez aux questions à partir de l'exemple de cette leçon. Vous recevrez ensuite la réponse modèle.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres prestataires, cela fonctionne de manière comparable.

• Un formulaire de contact sur votre site web : recevoir les champs par e-mail et éviter le spam
• Comment obtenir le bon expéditeur avec mail() en PHP ? SMTP
• L'envoi d'e-mails via PHP ne fonctionne pas, les enregistrements MX pointent ailleurs
• Limite d'envoi d'e-mails
• Limite quotidienne d'envoi d'e-mails atteinte
• Guide DirectAdmin 8.1: Tous les paramètres en un coup d'œil : serveurs, ports et sécurité
• Guide DirectAdmin 5.10: E-mail chez Microsoft 365 ou Google Workspace, site web chez WebOké