Emails de votre landing page dans les spams : ce que SPF, DKIM et DMARC changent vraiment

Un visiteur remplit le formulaire d’une landing page, clique sur « envoyer », voit s’afficher un message de remerciement — et repart convaincu que tout s’est bien passé. Côté coulisses, deux emails devraient partir à ce moment précis : une notification pour l’équipe commerciale, et une confirmation pour le visiteur. Le problème ne se voit ni dans le formulaire, ni dans les logs de l’outil d’envoi, qui affiche fièrement un statut « envoyé » : l’email a bien quitté le serveur, mais il n’est jamais arrivé dans la boîte de réception visée. Il dort dans un dossier spam, ou a été purement et simplement rejeté par le serveur destinataire. Le lead pense avoir été ignoré. L’équipe commerciale ignore qu’un lead existe. Personne ne sait qu’il y a un problème, jusqu’à ce qu’un client mécontent le signale — ou, plus souvent, jamais.

Deux emails, deux points de rupture invisibles

Une landing page qui capte des leads fait reposer une bonne partie de sa valeur sur deux emails automatiques que personne ne relit avant l’envoi. Le premier est la notification interne : « nouveau lead reçu », envoyée vers la boîte de l’équipe commerciale ou vers le CRM. Si elle finit en spam, la conséquence rejoint directement ce que détaille notre article sur le délai idéal de rappel d’un lead : le chronomètre tourne, mais personne ne le sait. Le second est l’email de confirmation envoyé au visiteur — reçu de rendez-vous, lien de téléchargement d’un lead magnet, accès à un essai gratuit. S’il finit en spam, le prospect qui vient pourtant de s’engager activement conclut souvent que l’entreprise ne répond pas, et abandonne avant même le premier échange. Les deux pannes sont silencieuses : rien dans l’interface de la landing page ni dans le tableau de bord de l’outil d’envoi ne les signale.

SPF, DKIM, DMARC : ce que ces trois sigles vérifient vraiment

Les serveurs de messagerie (Gmail, Outlook, les serveurs d’entreprise) ne se contentent plus de filtrer sur le contenu d’un email : ils vérifient, avant même de l’ouvrir, si le domaine qui prétend l’envoyer en a réellement l’autorisation. SPF (Sender Policy Framework) est un enregistrement DNS qui liste les serveurs autorisés à envoyer des emails pour un domaine donné — sans lui, n’importe quel serveur peut prétendre écrire « au nom de » ce domaine. DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email, prouvant qu’il n’a pas été modifié en chemin et qu’il provient bien du domaine déclaré. DMARC (Domain-based Message Authentication) relie les deux : il indique au serveur destinataire quoi faire quand SPF ou DKIM échouent — ignorer, mettre en quarantaine (spam), ou rejeter — et renvoie un rapport sur les tentatives d’usurpation. Sans ces trois éléments correctement publiés dans les enregistrements DNS du domaine, un email légitime ressemble, aux yeux d’un filtre antispam moderne, à s’y méprendre à une tentative d’usurpation.

Un problème plus courant qu’on ne le pense

Ce n’est pas une inquiétude théorique réservée aux grandes entreprises. Une étude de mesure à grande échelle menée par Sourena Maroofi, Maciej Korczyński et Andrzej Duda, publiée en 2021 dans IEEE Transactions on Network and Service Management (disponible sur Google Scholar), a scanné les enregistrements SPF et DMARC de plus de 236 millions de domaines à travers le monde : les auteurs constatent qu’une large part de ces domaines, y compris des domaines à forte visibilité, publient des enregistrements SPF ou DMARC absents, incomplets ou mal configurés — ce qui laisse la porte ouverte aussi bien à l’usurpation qu’au simple échec silencieux d’un email pourtant légitime. Une autre étude, menée par Hang Hu et Gang Wang (Virginia Tech) et présentée en 2018 au USENIX Security Symposium (disponible sur Google Scholar), a testé en conditions réelles 35 fournisseurs de messagerie populaires : les auteurs montrent que le traitement d’un email mal authentifié varie fortement d’un fournisseur à l’autre, et que même quand un avertissement s’affiche à l’utilisateur, celui-ci l’ignore dans la grande majorité des cas. Autrement dit : on ne peut compter ni sur une configuration par défaut fiable, ni sur la vigilance du destinataire pour rattraper le problème après coup — la seule variable qu’on maîtrise vraiment est la configuration du domaine d’envoi, en amont.

Où ça casse concrètement sur une landing page

• Un service tiers hébergé (Formspree, Zapier, Make) envoie souvent la notification depuis son propre domaine générique, mais affiche votre adresse en « répondre à » : certains filtres antispam considèrent ce décalage comme suspect si le domaine du service n’est pas correctement aligné avec DMARC.
• Un outil d’emailing (Brevo, Mailchimp, ActiveCampaign) demande de vérifier un sous-domaine dédié à l’envoi — une étape facultative dans l’interface, donc souvent ignorée, qui laisse les emails partir sans DKIM ni alignement SPF propre au domaine de la marque.
• Un webhook natif codé dans une route API et relié à un service transactionnel (Resend, Postmark, SendGrid) est la méthode la plus robuste techniquement, mais elle échoue de la même façon si les enregistrements DNS fournis par le service ne sont jamais ajoutés à la zone du domaine — voir notre guide sur le branchement d’un formulaire à un CRM ou un emailing.
• Un domaine tout neuf, acheté pour la campagne, n’a par définition aucune réputation d’envoi construite : même parfaitement configuré, il met plusieurs semaines à gagner la confiance des grands fournisseurs — un point à anticiper avant un lancement, pas après.

Configurer SPF, DKIM et DMARC sans y passer la journée

1. Identifier tous les services qui envoient réellement un email au nom du domaine — outil d’emailing, service transactionnel, CRM, parfois plusieurs à la fois — avant de toucher au DNS.
2. Ajouter l’enregistrement SPF fourni par chaque service dans un seul enregistrement TXT du domaine (un domaine ne peut avoir qu’un seul enregistrement SPF valide, qui doit lister tous les expéditeurs autorisés).
3. Activer DKIM dans chaque service et ajouter les enregistrements CNAME ou TXT fournis — l’étape la plus souvent oubliée, alors que c’est elle qui prouve l’authenticité de chaque email individuellement.
4. Publier une politique DMARC progressive : commencer par p=none pour observer les rapports sans bloquer d’email, puis passer à p=quarantine une fois les sources légitimes toutes identifiées.
5. Tester avant la mise en ligne avec un outil gratuit comme mail-tester.com ou le vérificateur DMARC de MXToolbox, en envoyant un vrai email de test depuis le formulaire de la landing page — pas un email envoyé à la main depuis une messagerie classique.
6. Revérifier à chaque changement d’outil : ajouter un nouvel outil d’emailing sans mettre à jour l’enregistrement SPF casse silencieusement l’authentification de tous les autres.

Le filet de sécurité qui protège même quand un email se perd

Aucune configuration n’est infaillible à 100 % : mieux vaut prévoir un filet plutôt que de dépendre uniquement de la délivrabilité. Stocker chaque soumission côté serveur avant même de tenter l’envoi de l’email — comme le détaille notre guide pour connecter un formulaire à un CRM — garantit qu’un lead reste consultable même si sa notification a disparu en route. Côté visiteur, une page de remerciement claire, affichant les prochaines étapes directement à l’écran plutôt que de tout faire reposer sur l’email de confirmation, évite qu’un problème de délivrabilité se transforme en prospect perdu. Et pour une inscription à une liste email plutôt qu’un simple formulaire de contact, notre comparatif double opt-in ou simple opt-in rappelle qu’un email de confirmation qui n’arrive jamais bloque purement et simplement l’inscription — la délivrabilité y devient un problème de conversion, pas seulement de communication.

Où ça se joue concrètement sur les templates LanderKit

Sur les 10 templates LanderKit (89 € l’unité, 229 € le pack complet), le formulaire est livré volontairement débranché — voir notre checklist technique de mise en ligne — précisément pour laisser le choix du service d’envoi et de son domaine à l’acheteur. Sur le template liste d’attente SaaS (démo), c’est la notification interne qui est critique : chaque inscription non vue en temps réel retarde l’analyse de la demande avant le lancement. Sur le template réservation restaurant (démo), c’est l’inverse : c’est la confirmation envoyée au client qui compte le plus, puisqu’une réservation sans confirmation reçue pousse souvent le client à réserver ailleurs par sécurité. Dans les deux cas, la configuration DNS du domaine d’envoi mérite le même soin que le choix du service lui-même.