Emails de formulaire : fiabiliser l’envoi avec SPF, DKIM et DMARC

Un visiteur remplit votre formulaire de contact. Le site affiche une confirmation, mais votre équipe ne trouve aucun email. Pour comprendre ce qui manque, il faut suivre le message depuis l’application jusqu’à la messagerie destinataire, puis vérifier comment votre domaine est authentifié.

Prenons le cas fictif d’une PME dont le site avertit le commercial et envoie un accusé de réception au prospect. Voici les points à examiner avec le prestataire web, sans promettre que tous les messages arriveront dans la boîte principale.

1. Identifier le service qui envoie réellement les emails

Votre messagerie professionnelle et votre site peuvent utiliser des services différents. Un email envoyé manuellement depuis votre boîte ne valide donc pas la configuration du formulaire.

Recensez les outils qui expédient des messages : site, CRM, logiciel de facturation, plateforme de réservation et service de newsletter. Pour chacun, notez le fournisseur d’envoi, l’adresse visible par le destinataire et la personne responsable des réglages.

Google cite explicitement les formulaires de contact parmi les expéditeurs à inventorier avant de configurer SPF. Source : préparer la configuration SPF.

Dans notre exemple, testez séparément la notification interne et l’accusé de réception. Ils peuvent emprunter deux circuits différents. Conservez la configuration DNS actuelle avant toute modification, puis faites vérifier que les changements prévus préserveront les autres outils.

2. Séparer l’expéditeur et l’adresse de réponse

La notification doit partir d’une adresse appartenant à un domaine que votre entreprise contrôle et que le service d’envoi est autorisé à utiliser. Évitez de placer l’adresse personnelle du visiteur dans le champ « De » : votre site ne dispose généralement pas des autorisations nécessaires pour expédier au nom de son domaine.

Pour permettre au commercial de répondre au prospect, utilisez plutôt le champ « Reply-To », après validation de l’adresse saisie. Ce champ indique où diriger une réponse, conformément au format standard des emails. Source : RFC 5322, champs d’origine.

Exemple fictif pour la notification interne :

• « De » : Site de l’entreprise, notifications@example.com ;
• « À » : l’équipe commerciale ;
• « Répondre à » : l’adresse validée du visiteur.

Pour l’accusé envoyé au prospect, l’adresse de réponse doit au contraire conduire à une boîte suivie par votre équipe. Testez le bouton « Répondre » dans les deux cas.

3. Vérifier SPF et DKIM sur le bon circuit

SPF permet de déclarer les serveurs autorisés à utiliser un domaine pour l’enveloppe technique du message. Ce domaine peut différer de celui affiché dans « De ». Demandez au prestataire lequel est utilisé par votre service d’envoi.

Pour un même nom de domaine, il ne faut pas publier plusieurs enregistrements SPF concurrents. Ajouter un fournisseur demande de revoir l’enregistrement concerné, pas de copier un second SPF à côté du premier. Le standard prévoit aussi des limites de recherches DNS : faites contrôler l’ensemble de la configuration. Source : RFC 7208, fonctionnement de SPF.

DKIM ajoute une signature vérifiable à l’email. La clé publique correspondante est publiée dans le DNS selon les instructions du fournisseur. L’activation doit concerner le service qui envoie effectivement les messages du site. Source : configurer DKIM.

Les valeurs à publier dépendent du fournisseur et du domaine. Une recette copiée d’un autre projet risque d’autoriser le mauvais service ou de perturber un envoi existant.

4. Déployer DMARC après avoir vérifié l’alignement

DMARC relie l’authentification au domaine visible dans « De ». Pour réussir le contrôle, le message doit passer SPF avec un domaine aligné, ou DKIM avec un domaine aligné. L’alignement dépend du mode configuré, strict ou souple. Un résultat SPF positif sur le seul domaine technique du prestataire ne suffit donc pas toujours. Source : configuration et alignement DMARC.

DMARC permet également de publier une politique indiquant le traitement souhaité des messages qui échouent au contrôle, et de demander des rapports. Pour une première mise en place, Google recommande une progression depuis une politique d’observation, « none », vers « quarantine » ou « reject », après analyse des envois légitimes. Source : déploiement progressif de DMARC.

Attribuez la lecture des rapports à une personne identifiée. Avant de renforcer la politique, vérifiez aussi les outils utilisés occasionnellement, comme la facturation mensuelle. Si une politique restrictive fonctionne déjà, évitez de l’affaiblir pour contourner un défaut du formulaire : corrigez d’abord son circuit d’envoi.

5. Tester depuis le formulaire jusqu’à la réponse

Réalisez les essais avec des données fictives et des boîtes que votre équipe contrôle chez plusieurs fournisseurs. Déclenchez les vrais messages depuis le formulaire, plutôt qu’un simple email de test depuis l’interface du prestataire.

Pour chaque essai, vérifiez :

• la réception de la notification et de l’accusé ;
• le classement observé, y compris dans les indésirables ;
• les domaines et résultats SPF, DKIM et DMARC dans les en-têtes ;
• le destinataire proposé lorsque vous cliquez sur « Répondre » ;
• la lisibilité du message sur téléphone.

Dans Gmail, l’option « Afficher l’original » permet notamment d’examiner les résultats d’authentification. La documentation DKIM de Google décrit ce contrôle sur un message reçu. Source : activer et vérifier DKIM.

Ces essais établissent le comportement observé à une date donnée. Ils doivent être rejoués après un changement de domaine, de fournisseur ou de configuration du formulaire.

6. Suivre les échecs après la mise en ligne

Demandez l’accès aux statuts d’envoi et aux motifs de rejet disponibles. Dans Amazon SES, par exemple, un événement « Send » signifie que la demande d’envoi a été acceptée ; « Delivery » confirme la remise au serveur de messagerie destinataire. Cette remise ne prouve pas une lecture par le prospect. Source : événements d’envoi Amazon SES.

Prévoyez une alerte exploitable en cas d’échec et un endroit où retrouver les demandes, avec des accès adaptés. La personne responsable doit pouvoir rapprocher une demande de son statut d’email sans recevoir inutilement tout son contenu dans une notification.

Enfin, l’authentification ne garantit pas le placement en boîte principale. Google précise que les filtres antispam peuvent bloquer les messages d’un fournisseur et recommande SPF, DKIM et DMARC pour les domaines d’envoi. Source : consignes Gmail pour les expéditeurs.

Avant la livraison du site, demandez l’inventaire des expéditeurs, les résultats des essais et le nom du responsable des alertes. Ces éléments rendent le suivi concret. Pour examiner votre parcours actuel, décrivez votre formulaire et vos outils à KADRI AI.