Pourquoi les emails transactionnels de ton app arrivent en spam (et comment y remédier)

Pourquoi la délivrabilité transactionnelle est un tout autre sujet

Il existe une distinction essentielle entre emails marketing et emails transactionnels que beaucoup de développeurs négligent lorsqu'ils commencent à s'intéresser sérieusement à la délivrabilité. Les emails marketing — newsletters, campagnes promotionnelles, annonces — s'adressent à des abonnés qui ont explicitement donné leur accord. Ils tolèrent des retards occasionnels et même des placements ponctuels en spam. Si une newsletter part en spam pour 2 % de ta liste, c'est dommage, mais ton activité continue.

Les emails transactionnels, c'est tout autre chose. Liens de vérification, réinitialisations de mot de passe, confirmations d'achat, codes d'authentification à deux facteurs, alertes de sécurité du compte — ils arrivent à des moments critiques du parcours utilisateur. Une réinitialisation de mot de passe qui part en spam, c'est un utilisateur bloqué hors de son compte, qui ouvrira probablement un ticket de support ou, pire, ne reviendra jamais. Un email de vérification en spam, c'est un nouvel utilisateur incapable de terminer son inscription et une fuite silencieuse et invisible dans ton tunnel d'acquisition.

Et pourtant, les emails transactionnels sont souvent configurés avec moins de soin que les campagnes marketing. Beaucoup de développeurs utilisent le code d'envoi fourni par leur framework au lieu de construire soigneusement le système d'email de vérification, le branchent sur un serveur SMTP mutualisé, déploient, testent une fois avec leur propre boîte — dont les seuils antispam sont généreux — et passent à autre chose. Les problèmes n'apparaissent que lorsque de vrais utilisateurs sur Gmail, Outlook ou Yahoo signalent des emails manquants. À ce stade, la panne est silencieuse en production depuis des semaines.

SPF : le socle de l'authentification email

Le Sender Policy Framework (SPF) est un enregistrement DNS TXT sur ton domaine d'envoi qui indique au monde entier quels serveurs de messagerie sont autorisés à envoyer des emails en ton nom. Quand Gmail reçoit un email prétendument envoyé par [email protected], il effectue une résolution DNS de l'enregistrement SPF de ton domaine. Si l'adresse IP du serveur qui a réellement envoyé l'email figure dans ton enregistrement SPF, l'email passe SPF. S'il n'existe aucun enregistrement SPF — ou si le serveur émetteur n'y figure pas — l'email est traité avec suspicion avant même que l'analyse du contenu ne commence.

Mettre SPF en place est simple dès qu'on sait quoi faire. Ajoute un enregistrement TXT au DNS de ton domaine. La valeur dépend de ton prestataire d'envoi. Avec SendGrid : v=spf1 include:sendgrid.net ~all. Avec AWS SES : v=spf1 include:amazonses.com ~all. Avec Mailgun : v=spf1 include:mailgun.org ~all. La documentation de ton prestataire te donnera la valeur include exacte. Le suffixe ~all est un « soft fail » : les emails provenant de serveurs non listés sont signalés mais pas rejetés d'emblée. Une fois certain que ton enregistrement SPF est complet et correct, tu peux passer à -all (hard fail), qui demande aux serveurs destinataires de rejeter purement et simplement le courrier non autorisé.

Un piège classique : la limite de 10 résolutions DNS. Les enregistrements SPF qui enchaînent plusieurs directives include: peuvent dépasser cette limite, ce qui fait échouer SPF même si tous tes serveurs y figurent techniquement. Utilise MXToolbox pour vérifier ton enregistrement SPF — les problèmes de nombre de résolutions y sont clairement signalés. La façon dont SPF, DKIM et DMARC s'articulent est très bien expliquée dans la documentation de SendGrid sur l'authentification email.

DKIM : la preuve cryptographique que ton email n'a pas été altéré

DomainKeys Identified Mail (DKIM) ajoute une signature cryptographique à chaque email que tu envoies. La signature est générée avec une clé privée détenue par ton prestataire d'envoi, et les serveurs destinataires la vérifient à l'aide d'une clé publique que tu publies dans un enregistrement DNS TXT. Si la signature est valide, deux choses sont prouvées : l'email provient réellement de ton infrastructure d'envoi, et son contenu n'a pas été modifié entre l'expédition et la réception.

Sans DKIM configuré, il devient beaucoup plus facile pour des acteurs malveillants d'usurper ton domaine — d'envoyer des emails qui semblent venir de [email protected] alors qu'ils ont été expédiés par quelqu'un d'autre. C'est exactement le mécanisme des campagnes de phishing. Les filtres antispam le savent aussi, et c'est pourquoi un email dépourvu de signature DKIM valide, alors que son domaine devrait en avoir une, est traité avec une suspicion accrue. Spamhaus et d'autres services de réputation intègrent l'historique de signature DKIM dans les scores de réputation de domaine.

La configuration de DKIM se fait chez ton prestataire d'envoi. Il génère une paire de clés, conserve la clé privée sur son infrastructure et te fournit une clé publique à ajouter à ton DNS sous forme d'enregistrement TXT. Dès que cet enregistrement est publié et propagé, chaque email envoyé en ton nom portera automatiquement une signature DKIM valide. La plupart des grands prestataires — SendGrid, Mailgun, Amazon SES, Postmark — te guident pas à pas lors de la configuration initiale. Si tu as sauté cette étape, reprends-la maintenant.

DMARC : la couche de politique qui relie le tout

DMARC (Domain-based Message Authentication, Reporting and Conformance) s'appuie sur SPF et DKIM en définissant ce que les serveurs destinataires doivent faire quand un email échoue à ces contrôles. Il introduit aussi l'« alignement » : l'exigence que le domaine de l'en-tête From corresponde effectivement au domaine qui a passé SPF ou DKIM. Cela empêche un attaquant de passer le contrôle SPF sur un domaine tout en usurpant un autre domaine dans l'adresse From visible.

La bonne approche avec DMARC est de procéder progressivement. Commence par une politique de simple surveillance : v=DMARC1; p=none; rua=mailto:[email protected]. Le p=none indique aux serveurs destinataires de ne rien faire en cas d'échec, mais de t'envoyer des rapports. Ces rapports agrégés te diront quels serveurs envoient des emails en ton nom et s'ils passent SPF et DKIM. Analyse-les pendant quelques semaines avant de modifier la politique.

Une fois certain que tout le trafic légitime passe, passe à p=quarantine (les emails en échec vont en spam) puis, à terme, à p=reject (les emails en échec sont rejetés d'emblée). Cette progression protège la réputation de ton domaine contre l'usurpation tout en te laissant le temps de repérer les sources d'envoi légitimes que tu aurais oubliées. Une politique DMARC en p=reject combinée à SPF et DKIM valides rend quasi impossible l'usurpation efficace de ton domaine.

Réputation IP : pourquoi ton serveur d'envoi compte

Même avec un SPF, un DKIM et un DMARC parfaits, tes emails peuvent finir en spam si l'adresse IP d'envoi a une mauvaise réputation. Les serveurs destinataires maintiennent — ou consultent des services tiers qui maintiennent — des listes de blocage et des scores de réputation pour les IP émettrices. Une IP avec un historique de spam, ou qui apparaît sur les listes de blocage de services comme Spamhaus, verra ses emails sortants traités avec suspicion, quelle que soit la qualité de ta configuration d'authentification.

Si tu utilises une adresse IP mutualisée d'un hébergeur partagé ou d'un service SMTP low cost, ta réputation est liée à celle de tous les autres utilisateurs de cette IP. Un seul spammeur dans le même pool partagé peut ruiner la délivrabilité de tous les expéditeurs de cette IP. C'est l'un des arguments les plus forts en faveur d'un prestataire dédié à l'email transactionnel — SendGrid, Amazon SES, Postmark, Mailgun — plutôt que d'envoyer directement depuis ton serveur applicatif ou via un SMTP mutualisé.

Sur une nouvelle IP d'envoi, il faudra aussi la « chauffer » progressivement. Un pic soudain de volume depuis une IP neuve ressemble à un comportement de spammeur aux yeux des serveurs destinataires. Commence par de faibles volumes et augmente progressivement sur plusieurs jours ou semaines. La plupart des prestataires email dédiés gèrent automatiquement ce warm-up si tu es sur un pool d'envoi partagé, ou fournissent des calendriers de montée en charge si tu utilises une IP dédiée.

Contenu et ligne d'objet : ce qui déclenche les filtres

Au-delà de l'authentification et de la réputation IP, le contenu même de ton email est évalué par les filtres antispam. Certains schémas déclenchent systématiquement un classement en spam. Les mots déclencheurs dans l'objet — « GRATUIT », « GARANTI », « AGISSEZ MAINTENANT », les points d'exclamation à répétition, les MAJUSCULES — sont les plus évidents et la plupart des développeurs les évitent. Moins évident : les objets trop vagues (« Message important pour vous »), trop urgents (« Votre compte va être fermé ») ou trop promotionnels pour ce qui est censé être un email transactionnel.

Le ratio texte/image compte également. Un email composé majoritairement d'images avec très peu de texte est un schéma de spam classique — les expéditeurs de masse utilisent les images pour dissimuler des mots-clés aux filtres textuels. Les emails transactionnels doivent être principalement textuels, avec très peu d'images. Un HTML cassé — balises non fermées, attributs mal formés — est un autre signal d'alerte. Envoie toujours une version texte brut en complément de la version HTML. Les filtres antispam considèrent les emails HTML seuls avec une méfiance accrue, et les messageries d'entreprise suppriment souvent complètement le HTML.

Tester la délivrabilité de tes emails — la bonne méthode

La méthode de test la plus rapide et la plus pratique est celle-ci : envoie un email de test vers une boîte mail temporaire fraîche et vérifie à la fois la boîte de réception et le dossier spam. Tu obtiens un retour immédiat et sans ambiguïté sur le fait que ton email atteint la boîte ou se fait filtrer. Contrairement à un test depuis ton propre compte Gmail — qui t'a peut-être déjà mis en liste blanche en tant qu'expéditeur habituel — une adresse temporaire neuve n'a aucun historique avec ton domaine, ce qui simule bien plus fidèlement le premier contact d'un nouvel utilisateur.

Tu devrais vérifier que l'email de vérification arrive vraiment chaque fois que tu modifies quelque chose susceptible d'affecter la délivrabilité : changement de prestataire d'envoi, refonte importante du template HTML, changement de domaine d'envoi, ajout d'un nouveau sous-domaine d'envoi ou déploiement dans un nouvel environnement (préproduction, production). Cela prend deux minutes et fournit une preuve formelle. L'alternative — attendre que les utilisateurs signalent le problème — signifie que tes soucis de délivrabilité échouent déjà en silence depuis une durée inconnue.

Au-delà du test boîte de réception/spam, utilise le vérificateur de santé email de MXToolbox pour contrôler l'état général de ton domaine : SPF, DKIM, DMARC, présence sur les listes noires et configuration des enregistrements MX, tout au même endroit. Intègre cela à ta checklist d'avant lancement pour chaque nouvelle application ou nouveau domaine d'envoi. Consulte aussi les recommandations de l'OWASP sur les bonnes pratiques email liées à la sécurité.

Taux de rebond et plaintes pour spam : les métriques qui comptent

Deux métriques ont un effet démesuré sur la délivrabilité à long terme : le taux de rebond et le taux de plaintes pour spam. Un taux de rebond supérieur à 2 % indique aux serveurs destinataires et à ton prestataire que tu envoies vers beaucoup d'adresses invalides ou inexistantes — un schéma associé aux listes achetées et aux opérations de spam. Même si tout le reste est irréprochable, un taux de rebond élevé provoquera des problèmes de délivrabilité. Retire les rebonds durs de ta liste d'envoi immédiatement et définitivement.

Un taux de plaintes supérieur à 0,1 % (une plainte pour mille emails envoyés) est le seuil à partir duquel la plupart des prestataires commencent à restreindre ton compte. Les Postmaster Tools de Gmail te remontent directement ce taux si tu les as configurés. Surveille ces métriques depuis le tableau de bord de ton prestataire. Si le taux de plaintes augmente, cherche pourquoi : envoies-tu à des utilisateurs qui n'ont pas donné leur accord explicite ? Tes emails sont-ils trop fréquents ? Y a-t-il un décalage entre ce que les utilisateurs attendaient et ce qu'ils reçoivent ?

Checklist complète de délivrabilité

• Enregistrement SPF : enregistrement DNS TXT sur ton domaine d'envoi listant tous les serveurs autorisés. À tester avec MXToolbox.
• DKIM : signature cryptographique configurée chez ton prestataire, clé publique publiée dans le DNS.
• DMARC : commencer par la surveillance p=none, puis passer à p=quarantine et enfin p=reject après analyse des rapports agrégés.
• Prestataire d'envoi dédié : utiliser SendGrid, SES, Postmark ou Mailgun — pas ton serveur applicatif ni un SMTP mutualisé.
• Objets propres : précis, pertinents, sans mots déclencheurs, sans ponctuation ni majuscules excessives.
• HTML + texte brut : toujours inclure les deux. Ne jamais envoyer un email HTML seul.
• Pas de raccourcisseurs d'URL : utiliser des URL complètes et directes dans le corps de l'email et les liens de vérification.
• Lien de désabonnement : à inclure même dans les emails transactionnels quand c'est pertinent — certains prestataires l'exigent.
• Adresse postale : exigée par CAN-SPAM et des réglementations similaires dans de nombreuses juridictions.
• Gestion des rebonds durs : supprimer immédiatement ; ne jamais réessayer un rebond dur.
• Suivi des plaintes : configurer les Postmaster Tools de Gmail ; surveiller le taux de plaintes dans le tableau de bord.
• Test en boîte de réception : envoyer des emails de test vers des boîtes temporaires fraîches avant chaque déploiement et après toute modification de template ou de configuration.
• Bilan de santé MXToolbox : à inclure dans la checklist d'avant lancement pour chaque nouveau domaine et environnement.

Quand utiliser un service d'email transactionnel dédié

Si ton application envoie ne serait-ce qu'un email dont l'utilisateur a besoin pour que le produit fonctionne — lien de vérification, réinitialisation de mot de passe et les reçus qui clôturent un parcours complet d'inscription et de paiement — tu devrais utiliser un prestataire d'email transactionnel dédié dès le premier jour. Le coût est faible (souvent gratuit jusqu'à plusieurs dizaines de milliers d'emails par mois), la fiabilité est nettement supérieure à un SMTP maison, et l'infrastructure de délivrabilité — pools d'IP partagés à réputation gérée, signature DKIM automatique, traitement des rebonds et des plaintes — est maintenue par des équipes dont le métier consiste à garder les emails dans les boîtes de réception.

L'erreur maison la plus fréquente consiste à faire tourner un serveur de messagerie sur la même IP que l'application web, ou à utiliser le SMTP inclus d'un hébergeur bon marché. Ces IP se retrouvent régulièrement sur les listes de blocage de services comme Spamhaus, parce que l'environnement d'hébergement est partagé avec des acteurs malveillants. Migrer vers un prestataire transactionnel dédié demande généralement une après-midi de travail et a un effet positif immédiat sur la délivrabilité. C'est l'une des améliorations d'infrastructure au meilleur rapport effort/impact pour une petite équipe. Les équipes soucieuses de la confidentialité devraient également consulter les recommandations de l'Electronic Frontier Foundation sur le traitement responsable des données utilisateur dès lors que l'email est concerné. Enfin, vérifier les adresses dans les bases de fuites connues via Have I Been Pwned peut compléter ta prévention de la fraude lors de la création de nouveaux comptes.