Formulaire de contact : les messages arrivent-ils ?

Deux opérations successives, dont une seule est visible

Quand quelqu'un envoie un formulaire, deux choses se produisent l'une après l'autre. Elles peuvent réussir ou échouer indépendamment.

La première : le navigateur transmet les champs au serveur, qui les reçoit et affiche la confirmation. C'est celle que le visiteur voit.

La seconde : le serveur fabrique un e-mail et le remet à un autre serveur, lequel doit l'accepter, puis le classer, puis vous le montrer. Celle-là, personne ne la voit.

Le bandeau vert s'affiche après la première. Il ne sait rien de la seconde.

Pourquoi la seconde échoue

Les grands fournisseurs de messagerie ont durci leurs exigences, et ce n'est pas une rumeur de forum : c'est écrit dans leurs documentations.

Google demande que tout expéditeur mette en place au minimum SPF ou DKIM, deux mécanismes qui permettent de vérifier qu'un serveur a le droit d'envoyer du courrier au nom d'un domaine. Yahoo pose exactement la même exigence minimale.

Au-delà de cinq mille messages par jour, les deux fournisseurs réclament les trois, DMARC compris, et ajoutent une condition : le domaine qui apparaît dans l'en-tête From, celui que vous lisez comme expéditeur, doit correspondre au domaine validé par SPF ou par DKIM. Ces seuils visent les gros expéditeurs, pas votre formulaire. Le mécanisme, lui, ne change pas : un domaine qui n'a ni SPF ni DKIM n'est authentifié par personne, quel que soit le nombre de messages qu'il envoie. Google précise qu'un message non authentifié peut être classé en indésirable, ou refusé avec une erreur 5.7.26.

Refusé. Pas mis de côté, pas signalé. Le serveur qui l'a émis reçoit l'erreur, et si personne ne lit les journaux de ce serveur, l'information s'arrête là.

L'erreur qu'on retrouve dans beaucoup de formulaires

Un formulaire est souvent configuré pour que l'e-mail parte au nom du visiteur. L'idée paraît pratique : le message arrive dans votre boîte avec l'adresse du prospect comme expéditeur, vous n'avez qu'à cliquer sur répondre.

Sauf que votre serveur n'a aucun droit d'envoyer du courrier au nom d'une adresse chez un fournisseur grand public. Le domaine affiché en expéditeur ne correspond à rien de ce que votre serveur peut prouver, et le message ressemble exactement à ce que les filtres cherchent à écarter.

Le réglage correct sépare les deux rôles. L'expéditeur est une adresse de votre domaine, celle que vos réglages autorisent. L'adresse du visiteur va dans le champ Reply-To, prévu pour ça : quand vous répondez, votre logiciel de messagerie utilise cette adresse, quel que soit l'expéditeur affiché.

Le bandeau vert prouve que la page a marché. Rien d'autre.

Le test, et la façon de le rater

Le réflexe est de remplir son propre formulaire et de regarder sa boîte. C'est mieux que rien, et c'est insuffisant. Le protocole qui apprend quelque chose tient en trois gestes.

• Envoyez depuis une adresse extérieure, chez un fournisseur différent du vôtre. Un message qui part de chez vous vers chez vous emprunte souvent un chemin plus court et plus indulgent.
• Ouvrez le dossier indésirables avant de conclure quoi que ce soit. Un message classé en spam est arrivé, ce qui est une information très différente d'un message disparu.
• Recommencez depuis deux ou trois fournisseurs différents. La décision d'accepter ou de refuser se prend chez le destinataire, et elle n'est pas la même partout.

Notez la date et le résultat quelque part. Ce relevé servira de point de comparaison la prochaine fois.

Les limites de ce que vous observez

Il faut être honnête sur ce que ce test prouve, parce que la tentation est de conclure trop vite.

Un test réussi prouve qu'un message est passé, une fois, depuis ce fournisseur-là, à ce moment-là. Il ne prouve pas que le message d'un inconnu arrivera demain. Les règles de filtrage évoluent, la réputation d'un serveur d'envoi bouge, et un hébergement mutualisé partage cette réputation avec des voisins que vous n'avez pas choisis.

Il y a plus gênant. Vous ne pouvez pas observer ce qui n'arrive pas. Un message perdu ne laisse aucune trace chez vous : pas de ligne, pas de compteur, pas de notification. Le seul indice disponible est indirect, c'est l'appel de quelqu'un qui vous dit « je vous ai écrit la semaine dernière ».

Cette asymétrie est le vrai problème, et elle mérite d'être formulée franchement : un formulaire cassé ressemble à un formulaire qui n'intéresse personne. Les deux produisent le même silence.

Vingt minutes, ce matin

Faites le test depuis une adresse extérieure, regardez la boîte principale puis les indésirables, et recommencez depuis un deuxième fournisseur. Notez ce que vous obtenez, avec la date.

Refaites-le après chaque intervention sur le site, pas seulement à la mise en ligne. Un changement d'hébergement, une mise à jour, une modification des réglages de domaine peuvent casser la chaîne sans rien changer à l'apparence de la page.

Ajoutez enfin un second canal bien visible sur votre page de contact : un numéro, une adresse e-mail en clair, un lien de prise de rendez-vous. Un visiteur qui n'obtient pas de réponse ne recommence pas, il va ailleurs. C'est aussi pour cette raison qu'une demande gagne à atterrir dans un endroit traçable plutôt que dans une seule boîte mail, ce que couvre la page automatisation, et la FAQ répond aux questions qui reviennent le plus.

Sources

• Email sender guidelines, aide Google Workspace. Source primaire : obligation de SPF ou DKIM pour tout expéditeur, SPF, DKIM et DMARC au-delà de cinq mille messages par jour vers Gmail, alignement du domaine From, erreur 5.7.26.
• Email sender guidelines FAQ, aide Google Workspace. Source primaire, précisions sur l'alignement et le classement des messages non authentifiés.
• Sender Hub, bonnes pratiques expéditeurs, Yahoo. Source primaire : SPF ou DKIM au minimum pour tout expéditeur, les deux plus DMARC et l'alignement du From pour les expéditeurs en volume.
• How email authentication works in Microsoft 365, Microsoft Learn. Source primaire pour le fonctionnement de SPF, DKIM et DMARC et le comportement du champ Reply-To.

Questions fréquentes

Pourquoi les messages de mon formulaire de contact n'arrivent-ils pas ?

Le message de confirmation affiché au visiteur signale seulement que le serveur a reçu les champs. L'envoi de l'e-mail est une seconde opération, qui peut échouer silencieusement si le serveur expéditeur n'est pas authentifié. Google indique qu'un message non authentifié peut être classé en indésirable ou refusé avec une erreur 5.7.26.

Faut-il mettre l'adresse du visiteur comme expéditeur du formulaire ?

Non. Votre serveur n'est pas autorisé à envoyer du courrier au nom d'une adresse chez un fournisseur grand public : le domaine affiché en expéditeur ne correspond alors à rien que SPF ou DKIM puissent valider. Mettez une adresse de votre domaine en expéditeur et l'adresse du visiteur dans le champ Reply-To, prévu pour cela.

Comment tester correctement un formulaire de contact ?

Envoyez un message depuis une adresse extérieure, chez un fournisseur différent du vôtre, puis vérifiez la boîte principale et le dossier indésirables. Recommencez depuis deux ou trois fournisseurs, car la décision d'accepter se prend chez le destinataire et varie de l'un à l'autre.

Sur le même sujet : ce que le cache du navigateur vous cache de vos propres modifications, et la boîte à outils, où je ne recommande que du vérifiable.