Le formulaire de contact fonctionne. Le message part. Aucune erreur visible. Et pourtant, côté client, le mail arrive dans les spams. C’est un grand classique.

Ou pire : il arrive parfois en boîte de réception, parfois en indésirable, selon l’adresse utilisée. Gmail le laisse passer, Outlook le range en spam, Orange fait sa cuisine dans son coin. Bref, tout le monde a son avis.

C’est le genre de problème frustrant, parce qu’on a souvent l’impression que le site fonctionne. Techniquement, il envoie bien le mail. Mais pour les serveurs de réception, ce n’est pas suffisant.

Un email ne doit pas seulement être envoyé. Il doit aussi prouver qu’il est légitime.

C’est ce que nous avons vérifié sur le site expertstraducteurs.com, qui rencontrait des soucis de réception avec les messages envoyés depuis son formulaire de contact SPIP.

Le mail partait, mais il n’inspirait pas assez confiance

Quand un formulaire de contact envoie un message, il y a plusieurs acteurs dans la boucle.

Il y a le site web.
Il y a le serveur qui envoie le mail.
Il y a le domaine utilisé comme expéditeur.
Il y a le service qui reçoit le message.
Et au milieu, il y a des filtres anti-spam qui jugent tout ça en quelques millisecondes.

Sur expertstraducteurs.com, la configuration était assez courante :

• le site web était hébergé sur o2switch ;
• les boîtes mail du domaine étaient gérées chez OVH ;
• l’envoi du formulaire passait par un service SMTP externe, Service-SMTP.fr / mysmtp.fr.

Rien d’anormal. Beaucoup de sites fonctionnent comme ça.

Mais dans ce type de configuration, il faut que le domaine dise clairement aux autres serveurs :

Oui, ce service SMTP a bien le droit d’envoyer des emails en mon nom.

Sans ça, le message peut être envoyé correctement, mais quand même finir en spam.

Le rôle du SPF, expliqué simplement

Le SPF, c’est une entrée DNS qui sert à lister les serveurs autorisés à envoyer des emails pour un domaine.

On peut voir ça comme une liste d’invités.

Si un serveur essaie d’envoyer un email pour expertstraducteurs.com, les services comme Gmail ou Outlook peuvent aller vérifier :

Est-ce que ce serveur est bien dans la liste ?

S’il n’y est pas, le message devient suspect.

Avant correction, le SPF du domaine autorisait le serveur web et OVH :

v=spf1 +ip4:109.234.161.141 +include:mx.ovh.com ~all

Mais il manquait le service SMTP externe utilisé pour envoyer les messages du formulaire.

Nous avons donc ajouté l’autorisation fournie par Service-SMTP.fr :

include:_spf.mysmtp.fr

Le SPF devient alors :

v=spf1 ip4:109.234.161.141 include:mx.ovh.com include:_spf.mysmtp.fr ~all

Cette ligne raconte une histoire plus cohérente :

• le site est sur o2switch ;
• les emails du domaine sont chez OVH ;
• le formulaire peut envoyer via mysmtp.fr.

Et cette cohérence est importante pour éviter le spam.

Pourquoi on ne crée pas plusieurs SPF

C’est une erreur fréquente.

On voit parfois un domaine avec un SPF pour l’hébergeur, un autre SPF pour le service mail, puis un troisième SPF pour le SMTP externe.

Ça part d’une bonne intention, mais ce n’est pas comme ça que ça fonctionne.

Un domaine doit avoir un seul SPF. Si plusieurs services doivent être autorisés, on les met dans la même ligne.

Sinon, les serveurs de réception peuvent considérer la configuration comme invalide ou ambiguë. Et quand un serveur mail hésite, il ne prend généralement pas de risque : il classe en spam.

Le DKIM était présent, mais pas forcément pour ce SMTP

Le domaine avait déjà des entrées DKIM liées à OVH.

Le DKIM, c’est une signature ajoutée aux emails. Elle permet de prouver que le message n’a pas été modifié et qu’il vient bien d’un service autorisé.

Mais attention : un DKIM OVH ne signe pas forcément les emails envoyés par un SMTP externe.

Dans notre cas, Service-SMTP.fr propose sa propre signature DKIM, avec une entrée DNS spécifique. Son activation demande toutefois une intervention de leur côté, avec une possible facturation.

Nous avons donc privilégié une approche progressive : corriger d’abord le SPF, tester les résultats, puis envisager le DKIM du SMTP externe seulement si les messages continuent à arriver en spam.

C’est souvent plus raisonnable que de tout modifier d’un coup.

Le DMARC en mode observation

Le domaine avait aussi un DMARC configuré en mode observation.

Le DMARC sert à dire aux serveurs de réception quoi faire quand un email échoue aux vérifications SPF ou DKIM.

En mode p=none, il n’impose pas encore de blocage. Il permet surtout d’observer.

C’est le bon réglage pendant une phase de diagnostic, surtout quand plusieurs services interviennent dans l’envoi des emails.

Passer trop vite en mode strict peut créer d’autres problèmes. On peut se retrouver à bloquer des messages légitimes simplement parce que toute la chaîne n’a pas encore été validée.

L’adresse du visiteur ne doit pas être l’expéditeur

Autre point qui peut faire partir un formulaire en spam : utiliser l’adresse du visiteur comme expéditeur technique.

Par exemple, si un visiteur saisit une adresse Gmail, le site ne doit pas envoyer le message comme s’il était Gmail.

Le site n’a pas le droit d’envoyer des emails pour gmail.com. Les filtres anti-spam le savent très bien.

La bonne logique est plutôt :

From: contact@expertstraducteurs.com
Reply-To: adresse du visiteur

Le message part depuis une adresse du domaine du site. C’est plus propre pour SPF, DKIM et DMARC.

Et quand le client clique sur “répondre”, la réponse part quand même vers le visiteur.

Tester avec le vrai formulaire

Pour ce type de problème, il ne faut pas tester depuis une boîte mail classique.

Il faut tester depuis le formulaire du site, parce que c’est lui qui utilise le bon chemin d’envoi.

Dans ce cas, le chemin était :

Formulaire SPIP → Service-SMTP.fr → destinataire

Le test utile consiste à envoyer un message vers Gmail, puis à ouvrir “Afficher l’original”.

Gmail indique alors si les contrôles passent :

SPF: PASS
DKIM: PASS ou NONE
DMARC: PASS

Un autre test utile est mail-tester.com, qui donne une note et signale les problèmes de configuration les plus visibles.

L’objectif minimum après correction du SPF était d’obtenir :

SPF: PASS
DMARC: PASS

Même sans DKIM spécifique au SMTP externe, c’est déjà une base beaucoup plus saine.

Ce qu’il faut retenir

Quand les emails d’un formulaire arrivent en spam, le problème ne vient pas toujours du formulaire.

Il peut venir du fait que le domaine n’autorise pas clairement le serveur qui envoie les messages.

Dans le cas d’expertstraducteurs.com, l’envoi passait par un SMTP externe, mais le SPF du domaine ne le déclarait pas encore. La correction a donc consisté à aligner la configuration DNS avec la réalité de l’envoi.

Le site reste hébergé sur o2switch.
Les emails entrants restent chez OVH.
Le formulaire envoie via Service-SMTP.fr.
Le SPF autorise désormais ce service.

C’est moins visible qu’un bug d’affichage, mais c’est souvent ce qui fait la différence entre un message reçu normalement et un message enterré dans les spams.

Les emails, c’est de la plomberie. Quand tout est bien raccordé, personne ne le remarque. Quand un tuyau est mal déclaré, tout finit dans le mauvais dossier.