E-mails du site qui arrivent en spam

Les confirmations de commande arrivent dans les indésirables de vos clients. Les demandes du formulaire de contact ne vous parviennent pas, ou une fois sur deux.

Ce problème est presque toujours un problème de réglages, pas de contenu. Voici ce que nous vérifions, avec un exemple que nous avons vécu sur notre propre site.

Pourquoi les e-mails du site finissent en spam

Les messageries comme Gmail ou Outlook vérifient que l’e-mail vient bien d’un serveur autorisé à écrire au nom de votre domaine. Si rien ne le prouve, l’e-mail est classé en indésirable, ou refusé.

Or un site envoie souvent ses e-mails depuis son propre serveur, qui n’a jamais été déclaré comme expéditeur autorisé.

Les trois réglages à vérifier

• SPF : la liste des serveurs autorisés à envoyer pour votre domaine.
• DKIM : une signature qui prouve que l’e-mail n’a pas été modifié en route.
• DMARC : la consigne donnée aux messageries quand les deux premiers échouent.

Ces trois réglages se font dans la zone DNS du domaine, pas dans le site.

Un exemple précis : un serveur oublié dans le SPF

Voici à quoi ressemble un SPF pour un domaine dont la messagerie est chez Microsoft 365 et dont le site envoie depuis son propre serveur :

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ip6:2001:db8::10 ~all

Les adresses du serveur sont ici fictives. Le piège fréquent : déclarer l’adresse IPv4 du serveur, et oublier son adresse IPv6. Le serveur envoie alors une partie de ses e-mails en IPv6, et ceux-là sont rejetés.

Le cas que nous avons vécu

Sur notre propre site, les demandes de contact ne nous arrivaient pas. Deux causes se cumulaient. L’adresse IPv6 du serveur manquait dans le SPF. Et le serveur se croyait responsable de notre domaine : il gardait les e-mails pour lui au lieu de les envoyer vers notre messagerie.

Nous avons complété le SPF, puis fait partir ces e-mails directement vers la messagerie Microsoft 365. Depuis, chaque demande arrive en quelques secondes.

Comment nous traitons ce cas

Un e-mail de test envoyé depuis le site, dont nous lisons les en-têtes : ils disent exactement quel contrôle a échoué. Puis nous corrigeons la zone DNS et la configuration d’envoi, et nous refaisons le test.

Pour les boutiques qui envoient beaucoup, nous passons souvent par un service d’envoi spécialisé, mieux reconnu par les messageries.

Pour notre suivi des serveurs et des domaines, voyez notre page hébergement et maintenance.