Pourquoi vos emails arrivent en spam, et ce qui aide vraiment
Les conseils habituels tournent autour de l'objet. La délivrabilité se décide sur trois enregistrements DNS, la réputation de votre domaine et la qualité de votre liste.
Le scénario est presque toujours le même. La confirmation de formulaire n'arrive jamais chez le client, la newsletter atterrit dans l'onglet promotions ou dans le spam pour la moitié des destinataires, et la première recherche d'une solution mène à une liste de mots à éviter dans l'objet. On enlève donc le point d'exclamation et on reformule "gratuit". Ensuite rien ne change.
Cela tient au fait que ce conseil agit sur le plus petit levier. Un serveur de messagerie qui reçoit un message demande d'abord qui écrit, et seulement ensuite ce qui est écrit. À la première question répondent trois enregistrements DNS et ce que votre domaine a envoyé ces dernières semaines. Rien de tout cela ne se trouve dans l'objet.
Cet article classe les leviers par effet réel. À la fin, vous saurez quel enregistrement toucher en premier.
Le travail paie dans cet ordre
La plupart des listes de contrôle sur la délivrabilité jettent vingt points dans le même sac sans en pondérer aucun. Classée par effet, la question devient plus lisible :
- Authentification. SPF, DKIM et DMARC sont en place et l'alignement tient.
- Chemin d'envoi. Vos emails partent d'un serveur que vos propres enregistrements DNS autorisent à envoyer pour le domaine.
- Qualité de la liste. La liste contient des adresses dont le consentement est documenté, et les retours sont retirés.
- Réputation de l'expéditeur. Volume et fréquence correspondent à ce que ce domaine a envoyé jusqu'ici.
- Contenu. Objet, texte, rapport entre image et texte, nombre et destination des liens.
Le point cinq est celui dont on parle le plus. Il ne compte qu'une fois les quatre précédents en place. Inverser l'ordre revient à peaufiner des formulations dans un message que le serveur destinataire n'arrive de toute façon à attribuer à personne.
Ce que les trois vérifient réellement
On cite les trois d'un même souffle en permanence et on les confond tout aussi souvent. Ils répondent à trois questions différentes.
SPF indique quels serveurs ont le droit d'envoyer
SPF est décrit dans la RFC 7208. C'est un enregistrement TXT sur votre domaine qui liste les serveurs autorisés à remettre du courrier au nom de ce domaine. Le serveur destinataire compare l'adresse IP du serveur qui remet le message à cette liste et obtient une réponse : ce chemin est-il autorisé ou non.
La deuxième erreur la plus fréquente se loge exactement ici. L'évaluation d'un enregistrement SPF ne peut déclencher que dix requêtes DNS au maximum, et chaque service inclus en coûte au moins une. Si vous ajoutez l'un après l'autre le fournisseur de votre boîte, un service de newsletter, un outil de facturation et un système de tickets, vous finissez par dépasser la limite. Le résultat est un permerror, et un enregistrement SPF en permerror ne vaut rien. Dans l'interface DNS, il continue de paraître parfaitement normal.
DKIM prouve que rien n'a été modifié en route
DKIM figure dans la RFC 6376. À l'envoi, une signature cryptographique est ajoutée dans l'en-tête du message, et la clé publique correspondante se trouve dans le DNS de votre domaine. Le destinataire vérifie ainsi deux choses à la fois : le message vient bien de ce domaine, et la partie signée est arrivée sans modification.
DMARC relie les deux résultats à une consigne
DMARC est décrit dans la RFC 7489. C'est l'enregistrement qui transforme deux résultats de contrôle en une décision. Vous y définissez ce que le destinataire doit faire quand la vérification échoue. Il existe trois valeurs : none signifie ne rien faire, quarantine signifie mettre au spam, reject signifie refuser. DMARC ouvre aussi le canal de rapports qui vous dit qui envoie en votre nom.
L'erreur de loin la plus courante sur le terrain : l'enregistrement reste sur p=none pour toujours. Comme point de départ, c'est correct, car la première chose que vous voulez est de voir ce qui part en votre nom. Comme état permanent, c'est une ligne DNS sans effet. Un enregistrement qui va au bout ressemble finalement à ceci :
_dmarc.votreentreprise.fr. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@votreentreprise.fr"L'alignement, le point où la plupart des configurations échouent
Voici ce que presque aucun guide n'aborde. DMARC ne vérifie pas seulement si SPF ou DKIM ont réussi. Il exige en plus que le domaine expéditeur visible corresponde au domaine qui a été vérifié. Cela s'appelle l'alignement, alignment en anglais, et c'est le terme que vous verrez dans les outils.
Dans la pratique, cela se passe ainsi. Vous envoyez votre newsletter via un service d'envoi. Votre propre adresse figure dans le champ expéditeur. Techniquement, c'est pourtant le service qui remet le message, et il dispose d'un enregistrement SPF propre pour son propre domaine. SPF réussit donc. La signature est elle aussi apposée avec le domaine du service. Du point de vue de DMARC, la scène est la suivante : un domaine tiers a été vérifié alors que le vôtre est celui qui s'affiche. L'alignement échoue, DMARC échoue avec lui, et tous les outils de contrôle affichent malgré tout un SPF au vert.
Chez tout prestataire sérieux, la sortie est la même : vous déclarez votre propre domaine dans votre compte chez le service d'envoi et vous publiez dans votre DNS la clé DKIM qu'il émet pour ce domaine. La signature est alors établie au nom de votre domaine, l'alignement tient et DMARC réussit.
Ce que Google, Yahoo et Microsoft exigent des expéditeurs en masse
Depuis février 2024, Google et Yahoo appliquent des exigences aux expéditeurs en masse, soit en gros à toute personne qui envoie plus d'environ 5 000 messages par jour vers des comptes Gmail. Sont exigés SPF, DKIM et DMARC, une désinscription en un clic fonctionnelle dans l'en-tête du message selon la RFC 8058, ainsi qu'un taux de plaintes pour spam inférieur à 0,3 pour cent. Microsoft a annoncé et mis en place des exigences comparables pour Outlook.com en 2025.
Si vous êtes largement en dessous de ce volume, vous ne comptez pas formellement comme expéditeur en masse. Cela ne change rien à la configuration : les trois enregistrements vous coûtent une heure une seule fois, la désinscription en un clic est posée par votre outil d'envoi, et le taux de plaintes dépend de l'état de votre liste à tout volume. La seule différence sous le seuil, c'est que personne ne vous mesure là-dessus.
Trouvez votre cas dans ce tableau
| Symptôme | Cause probable | Comment vérifier |
|---|---|---|
| Les confirmations de formulaire n'arrivent nulle part | Envoi par le chemin PHP par défaut depuis le serveur web, sans SPF et sans signature | Regarder les en-têtes d'un message de test et voir quel serveur l'a remis |
| Gmail accepte les messages, Outlook.com les écarte | DMARC absent ou réglé sur p=none | Interroger l'enregistrement TXT sous _dmarc et lire la valeur après p |
| La newsletter part au spam, les factures non | Deux chemins d'envoi, un seul signé avec votre domaine | Comparer la signature DKIM dans l'en-tête des deux types de messages |
| SPF réussit et DMARC échoue malgré tout | Alignement : le domaine expéditeur visible ne correspond pas au domaine vérifié | Lire la ligne Authentication-Results, spf=pass y côtoie dmarc=fail |
| Les outils signalent un permerror sur SPF | L'enregistrement déclenche plus de dix requêtes DNS | Compter tous les include et retirer les services qui ne servent plus |
| Bonne remise au début, puis spam d'un coup | Volume augmenté trop vite ou taux de plaintes en hausse | Revoir les volumes des dernières semaines et les désinscriptions par envoi |
Pourquoi le premier gros envoi est presque toujours freiné
Les systèmes destinataires tiennent une sorte d'historique pour chaque domaine expéditeur. Un domaine qui n'a rien envoyé pendant des années et qui remet d'un coup 2 000 messages un mardi matin ressemble à un compte piraté. Il est freiné, et la propreté de vos enregistrements DNS n'y change rien.
La sortie s'appelle la montée en charge, warmup dans les outils, et elle n'a rien de spectaculaire. Commencez petit et augmentez le volume sur plusieurs semaines. Démarrez par les destinataires qui ont récemment ouvert, cliqué ou acheté, car c'est leur réaction qui construit votre réputation. Les contacts dont vous n'avez plus de nouvelles depuis longtemps viennent ensuite.
Si le contact le plus récent de votre liste a trois ans, la montée en charge seule n'y suffira pas. Dans ce cas, le travail sur la liste passe avant l'envoi.
Une liste entretenue rapporte plus que toute optimisation de texte
Les listes achetées, les adresses vieilles de plusieurs années et les retours jamais traités vous coûtent plus de délivrabilité que tous les mots suspects que vous avez évités dans vos objets. La raison est simple : chaque message vers une adresse morte et chaque plainte est un signal qui compte directement contre votre réputation.
Les règles sont courtes. Les hard bounces, c'est-à-dire les adresses définitivement non distribuables, sortent immédiatement de la liste. Les soft bounces peuvent être retentés plusieurs fois, puis retirés. Une plainte vaut désinscription immédiate, sans question de confirmation. Les adresses qui n'ont rien ouvert depuis des années sont un risque pour toutes les autres de la liste.
Tout commence par le consentement. À quoi ressemble un double opt-in propre, ce qui doit être journalisé et pourquoi cela aide aussi techniquement, c'est le sujet de l'article sur le double opt-in et le RGPD. Il s'agit ici d'un éclairage pratique et non d'un conseil juridique, pour une évaluation contraignante de votre cas il vous faut quelqu'un d'habilité.
WordPress envoie par le mauvais chemin par défaut
Cela mérite sa propre section, car dans les petits projets c'est la cause isolée la plus fréquente. WordPress envoie via wp_mail, et sans configuration supplémentaire cela aboutit à la fonction PHP mail(), qui remet le message directement au serveur web. Ce serveur web ne figure en général dans aucun enregistrement SPF de votre domaine et ne signe rien non plus. Le message part donc et échoue aux deux contrôles en même temps.
La sortie habituelle consiste à faire passer l'envoi par SMTP ou par l'API de votre prestataire, avec votre propre domaine vérifié. Cela concerne tout ce que votre site envoie automatiquement : confirmations de formulaire, emails de réinitialisation de mot de passe, confirmations de commande et factures. Ces messages comptent davantage pour le client que n'importe quelle newsletter, et ce sont eux qui disparaissent le plus discrètement.
Là où vous perdez votre temps
Reste la question de ce qui subsiste des conseils habituels. Les mots suspects dans l'objet sont le classique du genre, et ils relèvent aujourd'hui largement du folklore. Les filtres pèsent le comportement de l'expéditeur bien plus que des mots isolés. Le mot "gratuit" dans un objet ne pose aucun problème tant que l'expéditeur a une bonne réputation, et il ne sauve rien tant qu'il n'en a pas.
Le travail sur l'objet n'en devient pas inutile pour autant. Il joue simplement sur le taux d'ouverture et pas sur la remise. Séparer ces deux chantiers vous épargne beaucoup de reformulations stériles.
p=none, vous avez des rapports et aucun effet. S'il n'indique rien du tout, vous n'avez même pas les rapports.La newsletter depuis votre propre WordPress, avec la remise en tête
Kurato envoie via votre propre accès prestataire et apporte la désinscription en un clic selon la RFC 8058, le traitement des retours et des plaintes ainsi qu'un indicateur de délivrabilité pour SPF, DKIM et DMARC. Les coordonnées restent dans votre base de données.
Ce que couvre la version gratuite et où commence Pro figure sur la page des tarifs. Une précision honnête : les séquences d'automatisation ramifiées sont encore en chantier dans Kurato.
Questions fréquentes
Quelle est la différence entre SPF, DKIM et DMARC ?
SPF (RFC 7208) indique quels serveurs ont le droit d'envoyer pour votre domaine. DKIM (RFC 6376) pose une signature cryptographique qui permet au destinataire de vérifier que le message vient de votre domaine et n'a pas été modifié en route. DMARC (RFC 7489) relie les deux résultats à une consigne sur ce qui doit se passer en cas d'échec, et met en place les rapports. Seuls les trois ensemble donnent une image complète.
Mon enregistrement DMARC est sur p=none. Est-ce suffisant ?
Comme point de départ oui, comme état permanent non. Avec p=none, rien ne se passe en cas d'échec, vous recevez seulement des rapports. Le sens de cette étape est de voir pendant quelques semaines qui envoie en votre nom. Ensuite la consigne doit passer sur quarantine puis plus tard sur reject, sinon l'enregistrement reste une ligne sans effet.
SPF réussit mais DMARC échoue. Comment est-ce possible ?
C'est presque toujours l'alignement. DMARC exige que le domaine expéditeur visible corresponde au domaine vérifié par SPF ou DKIM. Qui envoie via un service d'envoi sans y vérifier ni signer son propre domaine réussit SPF pour le domaine du service et échoue à DMARC. La solution est la clé DKIM émise pour votre propre domaine.
Est-il utile d'éviter les mots suspects dans l'objet ?
À peine. Les filtres actuels pèsent le comportement de l'expéditeur bien plus que des mots isolés. Un expéditeur à bonne réputation passe sans problème avec le mot gratuit dans l'objet, un expéditeur sans réputation échoue même avec la formulation la plus sage. Le travail sur l'objet paie pour le taux d'ouverture, pour la remise il apporte peu.
Pourquoi les confirmations de formulaire WordPress finissent-elles en spam ?
Parce que sans configuration supplémentaire WordPress envoie via la fonction PHP mail() et que le message part donc du serveur web. Celui-ci ne figure en général dans aucun enregistrement SPF de votre domaine et ne signe rien, si bien que SPF et DKIM échouent en même temps. La voie habituelle consiste à faire passer l'envoi par SMTP ou par l'API de votre prestataire avec votre propre domaine vérifié.
