Trois semaines. Trois semaines sans une seule réponse aux relances commerciales, dans une PME lyonnaise d'une quinzaine de personnes qui, jusque-là, décrochait deux ou trois affaires par mois grâce à ses devis envoyés par mail. Rien n'avait bougé. Le site tournait. La boîte de réception recevait normalement les demandes entrantes, les newsletters, les factures fournisseurs. Le problème était ailleurs, et complètement invisible depuis l'intérieur : les messages partaient, l'interface affichait « envoyé », et ils atterrissaient dans le dossier indésirable de tous les destinataires.
Il y a quelque chose d'assez cruel dans cette panne-là. Un site en carafe, ça se voit tout de suite. Un email qui part en spam ne déclenche aucune alerte, aucun message d'erreur, aucun rebond. Le silence, c'est tout.
Et pourtant l'email reste, année après année, le canal digital le plus rentable qui existe. Le seul aussi dont l'infrastructure demeure totalement opaque tant qu'elle fonctionne correctement. Ce que la plupart des dirigeants découvrent au moment de la crise, c'est que le problème n'est ni le contenu de leurs messages, ni leur logiciel de messagerie. C'est une question de propriété. De gouvernance. Et concrètement, de trois enregistrements DNS que presque personne n'a jamais regardés.
Le malentendu fondateur : votre adresse email n'appartient pas à votre boîte mail
Commençons par démonter une idée reçue qui explique à peu près 80 % des situations bloquées.
Quand vous ouvrez Gmail ou Outlook et que vous voyez votre adresse contact@votreentreprise.fr, vous avez l'impression naturelle que cette adresse « vit » là. Qu'elle appartient à ce service. C'est faux. Cette adresse appartient à votre nom de domaine, et votre messagerie n'en est qu'un locataire, autorisé à s'en servir.
Nom de domaine, hébergeur, registrar, messagerie : quatre acteurs distincts
Quatre rôles, souvent confondus, parfois tenus par quatre sociétés différentes.
Le registrar détient le nom de domaine. C'est chez lui que la propriété est enregistrée, c'est lui qui facture le renouvellement annuel. L'hébergeur stocke les fichiers du site et sert les pages. La zone DNS, elle, peut être gérée chez le registrar, chez l'hébergeur, ou chez un tiers comme Cloudflare. Enfin le service de messagerie, Google Workspace, Microsoft 365, OVH, ou la messagerie incluse dans un hébergement mutualisé, gère les boîtes et les envois.
Quatre acteurs. Quatre contrats, parfois. Et un seul point de vérité.
Le point de bascule : qui a la main sur la zone DNS
Voilà le nœud. La délivrabilité ne se règle pas dans l'interface de votre messagerie. Elle se joue dans la zone DNS de votre domaine, cet annuaire public qui indique au monde entier où pointer et, surtout, qui a le droit d'écrire en votre nom.
Celui qui édite cette zone détient le pouvoir réel. Il peut autoriser un nouvel outil d'emailing, en révoquer un autre, ou casser toute votre chaîne d'envoi par une virgule mal placée.
Et dans un nombre de dossiers assez déprimant, ce n'est ni le dirigeant, ni son prestataire actuel. C'est l'agence qui a fait le site en 2016 et dont plus personne n'a le numéro.
Cas typiques rencontrés en audit
Quelques configurations vues et revues :
- Le domaine est enregistré au nom personnel d'un ancien webmaster freelance, injoignable depuis deux ans. Techniquement, l'entreprise ne possède pas son propre nom.
- Le DNS est géré chez l'hébergeur du site, mais la messagerie a migré vers Microsoft 365 il y a trois ans sans que les enregistrements d'authentification suivent.
- Deux enregistrements SPF coexistent dans la zone, posés à six mois d'intervalle par deux prestataires qui ne se sont jamais parlé. Résultat : les deux sont invalides.
- DKIM est bien activé côté messagerie, l'interface affiche un joli voyant vert, mais la clé publique n'a jamais été publiée dans le DNS. La signature existe et n'est vérifiable par personne.
Aucun de ces cas ne produit d'erreur visible. C'est bien le problème.
Pourquoi vos emails finissent en spam : les vraies causes, dans l'ordre
Autant le dire tout de suite : la hiérarchie des causes n'est plus du tout celle qu'on répète dans les articles de 2012. Le mot « gratuit » en objet, les majuscules, les points d'exclamation en série, tout cela pèse encore un peu, mais très marginalement. Le filtrage moderne fonctionne autrement.
L'authentification manquante ou incohérente
Cause numéro un, et de très loin.
Depuis février 2024, Gmail et Yahoo ont durci leurs exigences de manière significative : tout expéditeur doit être authentifié, et les émetteurs de volume doivent en plus publier une politique DMARC. Ce n'était pas une suggestion, c'était une bascule.
Le changement de fond est là. Le filtre ne se demande plus d'abord « ce message est-il suspect ? » mais « qui l'envoie, et cette personne a-t-elle le droit ? ». On est passé d'une logique de contenu à une logique d'identité. Si l'identité n'est pas vérifiable, le contenu n'a même pas besoin d'être examiné.
La réputation de l'adresse IP et du domaine
Deux réputations distinctes, souvent mélangées.
La réputation de l'adresse IP est celle du serveur qui émet. En hébergement mutualisé, cette IP est partagée avec des dizaines, parfois des centaines d'autres clients. Vous subissez leurs erreurs. Un voisin de palier envoie une campagne sur une base achetée, et vos devis en pâtissent le lendemain.
La réputation de domaine, elle, vous appartient. Elle vous suit partout, même si vous changez d'hébergeur ou de service d'envoi. Elle se construit lentement, sur des mois, à partir de signaux cumulés.
C'est la seconde qui compte le plus aujourd'hui. Et c'est aussi la plus longue à réparer.
Les signaux d'engagement
Les fournisseurs de messagerie observent le comportement de vos destinataires, et ils en tirent des conclusions.
Taux d'ouverture. Réponses. Messages déplacés manuellement hors des indésirables (excellent signal). Marquages spam (signal désastreux). Adresses mortes qui rebondissent en série.
Et puis il y a les spam traps, ces adresses pièges semées par les fournisseurs et les organismes anti-spam. Certaines sont d'anciennes adresses réelles, abandonnées puis recyclées en piège. Toucher une seule de ces adresses suffit parfois à faire basculer un domaine. Devinez d'où elles viennent, dans neuf cas sur dix ? Des bases de données achetées.
Les causes de contenu, les dernières de la liste
Elles existent, mais pas là où on les cherche.
Ce qui pèse vraiment : un ratio texte/image déséquilibré, typiquement un message entièrement composé d'une seule grande image. Les liens raccourcis, massivement utilisés par les spammeurs. Les domaines de tracking non alignés avec le domaine expéditeur. L'absence de version texte dans un message HTML. Les pièces jointes, particulièrement les formats exécutables ou les archives.
Rien à voir avec le vocabulaire employé, donc.
Les erreurs d'infrastructure invisibles
Enfin, la catégorie la plus ingrate, celle qui ne se diagnostique pas depuis une interface web.
Un reverse DNS absent sur l'IP émettrice. Un nom HELO incohérent avec le domaine annoncé. L'absence de chiffrement TLS lors de la transmission.
Et un cas particulièrement fréquent, rarement identifié : le formulaire de contact du site qui envoie le message depuis l'adresse du visiteur. Votre serveur émet donc un message prétendant venir de jean.dupont@gmail.com, sans la moindre autorisation de Gmail pour le faire. C'est une usurpation involontaire, elle échoue systématiquement à l'authentification, et elle abîme la réputation du domaine à chaque soumission de formulaire. La correction est simple : envoyer depuis une adresse du domaine et placer l'adresse du visiteur en champ de réponse. Encore faut-il y penser.
SPF : déclarer qui a le droit d'envoyer en votre nom
Le principe en une phrase
SPF est une liste publique des serveurs autorisés à émettre du courrier pour votre domaine. Elle est publiée dans le DNS, et le serveur destinataire la consulte à chaque message reçu pour vérifier que l'expéditeur figure bien dans la liste.
Une liste d'invités à l'entrée d'une soirée, en somme. Vous n'êtes pas dessus, vous n'entrez pas.
Anatomie d'un enregistrement
Prenons un exemple réel, du type de ceux qu'on rencontre chez une PME équipée normalement :
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.42 mx ~all
Décomposons. v=spf1 annonce la version. Les mécanismes include délèguent l'autorisation à des tiers, ici Google Workspace et une plateforme d'envoi transactionnel. ip4 autorise une adresse IP précise, souvent celle du serveur applicatif maison. mx autorise les serveurs déclarés comme récepteurs du domaine.
Reste la terminaison, et c'est elle qui compte le plus.
~all signifie « softfail » : les serveurs non listés échouent, mais le destinataire est simplement invité à s'en méfier. -all signifie « hardfail » : tout ce qui n'est pas dans la liste doit être rejeté.
Le softfail est un pansement confortable. On le pose « en attendant », on se dit qu'on durcira plus tard, et six ans passent. Il n'engage à rien et ne protège pas grand-chose. À un moment, il faut trancher.
Les trois pièges classiques
Le double SPF. Deux enregistrements TXT commençant par v=spf1 dans la même zone ne s'additionnent pas. Ils s'annulent. La norme impose un enregistrement unique, et deux valent une configuration invalide. C'est probablement l'erreur la plus fréquente, et la plus facile à commettre quand deux prestataires interviennent sans se coordonner.
La limite des dix résolutions DNS. Chaque mécanisme include, a ou mx déclenche une requête DNS supplémentaire, et certains include en contiennent eux-mêmes d'autres en cascade. Au-delà de dix, l'enregistrement devient invalide et tout échoue. On y arrive plus vite qu'on ne croit : Google Workspace, un CRM, une plateforme d'emailing, un outil de facturation, un service de signature électronique, et le compte est bon.
L'outil oublié. Il y a toujours un service qui envoie silencieusement depuis votre domaine et que personne n'a déclaré. Le logiciel de recrutement. L'outil de prise de rendez-vous. Le module de relance de factures impayées. Ils fonctionnaient très bien tant que rien n'était durci, et ils tombent tous ensemble le jour du passage en hardfail.
Ce que SPF ne protège pas
Point capital, et souvent mal compris.
SPF valide l'enveloppe technique du message, le Return-Path, celui qui sert aux rebonds. Il ne valide pas l'adresse affichée à votre lecteur dans le champ « De ».
La conséquence est vertigineuse : un usurpateur peut parfaitement passer le contrôle SPF avec son propre domaine, tout en affichant votre nom et votre adresse à l'écran. SPF est satisfait, l'authentification est techniquement validée, et le destinataire lit un message frauduleux qui semble venir de vous.
C'est exactement ce trou que DMARC vient combler. Nous y venons.
DKIM : signer cryptographiquement chaque message
Le principe
DKIM ajoute une signature cryptographique à chaque message sortant. Le serveur émetteur signe avec une clé privée qu'il garde secrète, et publie la clé publique correspondante dans le DNS. Le serveur destinataire récupère cette clé publique et vérifie la signature.
Deux garanties d'un coup. L'origine, d'abord : seul le détenteur de la clé privée a pu signer. L'intégrité, ensuite : si le message a été altéré en route, la signature ne correspond plus.
Sélecteurs, clés, rotation
Le sélecteur est un identifiant qui permet de publier plusieurs clés en parallèle. Concrètement, votre messagerie signe avec un sélecteur, votre plateforme de newsletter avec un autre, votre outil transactionnel avec un troisième. Chacun a sa clé publiée à une adresse DNS distincte, et tous coexistent sans se gêner.
Sur la longueur de clé, la recommandation actuelle est de 2048 bits. Le 1024 bits reste techniquement accepté, mais il n'est plus considéré comme robuste. Un détail pratique à connaître : un enregistrement TXT est limité en longueur, et une clé de 2048 bits dépasse cette limite. Elle doit être découpée en plusieurs segments que le serveur DNS recolle. Certaines interfaces de gestion le font automatiquement, d'autres pas, et c'est une source classique de clés publiées mais illisibles.
Quant à la rotation périodique des clés, tout le monde la recommande, presque personne ne la pratique. Une fois par an constitue déjà une bonne hygiène.
Pourquoi DKIM survit là où SPF casse
Voici l'argument qui devrait clore tout débat sur « SPF suffit-il ? ».
Imaginez un message envoyé à contact@client.fr, adresse qui redirige automatiquement vers une boîte Gmail personnelle. Au moment de la retransmission, c'est le serveur du client qui émet, pas le vôtre. SPF échoue mécaniquement : ce serveur ne figure évidemment pas dans votre liste d'autorisation.
DKIM, lui, tient. La signature voyage avec le message et reste valide tant que le contenu n'a pas été modifié.
Même chose pour les listes de diffusion et les alias professionnels, très répandus dans les grandes structures et les collectivités. S'en tenir au seul SPF, c'est accepter de disparaître dans tous ces cas de figure.
L'erreur la plus fréquente
Elle mérite son paragraphe.
DKIM est activé dans la console d'administration de la messagerie. Le voyant est vert. Tout le monde est content. Sauf que la clé publique n'a jamais été publiée dans le DNS, ou l'a été pour un seul des services émetteurs.
Résultat : les messages partent signés, personne ne peut vérifier la signature, et le résultat est identique à une absence totale de DKIM.
La règle est simple : vérifier chaque flux séparément. La messagerie principale. La newsletter. Le transactionnel. Le CRM. La facturation. Cinq flux, cinq vérifications, pas une seule vérification globale qui ne prouve rien.
DMARC : la politique qui donne du sens aux deux premiers
Le rôle d'arbitre
DMARC ne vérifie rien de nouveau. Il ne remplace ni SPF ni DKIM, il les orchestre.
Son apport tient en deux points. D'abord, il exige que SPF ou DKIM s'aligne avec le domaine visible par le lecteur, ce fameux champ « De » que SPF seul ignorait. Ensuite, il indique aux serveurs destinataires quoi faire en cas d'échec, et leur demande de rendre des comptes.
C'est l'arbitre qui manquait.
La notion d'alignement, le point que tout le monde saute
Si vous ne deviez retenir qu'un paragraphe technique de cet article, ce serait celui-ci.
L'alignement, c'est la correspondance entre le domaine que voit votre lecteur et celui qui a été authentifié techniquement. Il existe en mode strict, où les domaines doivent être rigoureusement identiques, et en mode relâché, où un sous-domaine est accepté.
Prenons le cas qui fait échouer la moitié des DMARC en production. Vous envoyez votre newsletter depuis une plateforme d'emailing. Le champ « De » affiche newsletter@votreentreprise.fr, parfait. Mais le Return-Path technique, lui, pointe vers bounces.plateforme-emailing.com, parce que c'est cette plateforme qui gère les rebonds.
Le contrôle SPF passe : le serveur émetteur est bien autorisé pour le domaine plateforme-emailing.com. Mais l'alignement DMARC échoue, parce que ce domaine n'a rien à voir avec celui affiché au lecteur.
Le SPF est valide, et DMARC échoue quand même. C'est la cause numéro un des configurations dont on dit « on a tout mis, ça ne marche pas ».
La solution existe : configurer un domaine d'envoi personnalisé chez la plateforme, généralement un sous-domaine de type mail.votreentreprise.fr. Toutes les plateformes sérieuses le proposent. Encore faut-il savoir qu'il faut le demander.
Les trois politiques et la progression recommandée
DMARC propose trois niveaux, et l'ordre dans lequel on les traverse n'est pas négociable.
none : on observe, on ne bloque rien, on collecte des rapports. C'est le mode d'apprentissage.
quarantine : les messages non conformes partent en indésirables.
reject : ils sont purement et simplement refusés par le serveur destinataire.
Une montée en charge réaliste ressemble à ceci. Publier une politique none avec collecte des rapports, et laisser tourner plusieurs semaines. Six à huit, idéalement, pour couvrir les envois mensuels et les outils qui ne s'expriment qu'à la clôture comptable. Analyser ce que révèlent les rapports. Corriger les flux non alignés, un par un. Puis passer en quarantine sur une fraction du trafic, grâce au paramètre de pourcentage prévu par la norme, avant de généraliser. Et enfin, seulement enfin, basculer en reject.
Passer directement en reject sur un parc mal cartographié, c'est couper la facturation automatique, les notifications applicatives, les confirmations de commande et les formulaires du site, tout cela le même matin, sans prévenir personne. Ça s'est vu. Ce n'est pas une expérience à recommander.
Les rapports agrégés : le seul outil de cartographie honnête
Ce point est sous-estimé, et c'est dommage, parce qu'il constitue souvent le vrai livrable d'un audit de délivrabilité.
En publiant une adresse dans le paramètre RUA de votre enregistrement DMARC, vous demandez aux grands fournisseurs de vous envoyer quotidiennement un rapport de tout ce qui a été émis en votre nom. Tout, sans exception.
Les premières semaines réservent des surprises. On découvre un outil de sondage utilisé une fois par le service marketing en 2021 et jamais désactivé. Un prestataire RH qui envoie les bulletins de paie depuis le domaine de l'entreprise sans que la DSI en ait connaissance. Un serveur en Europe de l'Est qui usurpe le domaine depuis des mois.
Aucune interface, aucun inventaire déclaratif, aucune réunion ne donnera cette photographie-là. Seuls les rapports le font, parce qu'ils décrivent le réel et non l'organigramme.
BIMI et l'après-DMARC
Un mot rapide sur la suite, parce que la question revient souvent en réunion.
BIMI permet d'afficher le logo de votre marque directement dans la boîte de réception de vos destinataires, à côté du message. C'est un gain de reconnaissance immédiat, et un bénéfice concret d'une politique DMARC en reject, condition préalable indispensable.
Attention toutefois aux contraintes. Le logo doit correspondre à une marque déposée, et la plupart des fournisseurs exigent un certificat VMC, dont le coût annuel se compte en centaines d'euros. Ce n'est pas une case à cocher, c'est un projet. À envisager quand le reste est solide, pas avant.
Le rôle du prestataire digital : arbitrer, pas seulement exécuter
Cartographier avant de toucher au DNS
La tentation est forte, quand un client appelle en urgence parce que ses mails partent en spam, de publier un SPF propre dans l'heure et d'annoncer que c'est réglé.
Mauvaise idée. La première étape est un recensement exhaustif des émetteurs, et il faut aller chercher les oubliés : plugin de formulaire du site, ERP, logiciel de caisse, prestataire RH, outil de signature électronique, système de réservation, plateforme d'avis clients.
Cette liste ne s'obtient jamais du premier coup en réunion. Elle se complète pendant des semaines, au fil des rapports DMARC et des « ah oui, tiens, il y a aussi ça ».
Il faut aussi avoir cette conversation d'entrée de jeu : toute modification DNS mal maîtrisée se paie en messages perdus, et l'expéditeur ne voit strictement rien. Pas d'erreur, pas de rebond, pas d'alerte. Juste des affaires qui ne se concluent pas.
Séparer les flux
Recommandation structurante, et curieusement peu appliquée dans les PME : ségréguer les envois par sous-domaine.
Le transactionnel sur un sous-domaine. Le marketing sur un autre. La correspondance humaine sur le domaine principal.
Le bénéfice est immédiat et durable. Une campagne mal ciblée, un taux de plainte qui grimpe, un incident de réputation, tout cela reste cantonné au sous-domaine marketing. Vos devis et vos réponses commerciales, eux, continuent d'arriver. Sans cette séparation, une seule campagne ratée peut emporter toute la correspondance de l'entreprise.
C'est une décision d'architecture, à prendre tôt. La rétablir après coup demande de reconstruire une réputation de zéro sur chaque sous-domaine.
Documenter et transmettre
Passage plus politique que technique, mais il faut le dire.
Un prestataire sérieux laisse au client la propriété pleine de son nom de domaine, les accès administrateur à sa zone DNS, et une documentation lisible de ce qui a été configuré et pourquoi. Sélecteurs DKIM utilisés, services autorisés dans le SPF, adresse de réception des rapports DMARC, date de dernière rotation des clés.
Garder ces accès pour soi ne fidélise personne. Ça crée une dépendance, ce qui n'est pas la même chose, et ça finit toujours par produire la situation décrite en début d'article : une entreprise bloquée parce que le seul détenteur des clés a disparu.
Un client qui reste parce qu'il ne peut pas partir n'est pas un client satisfait. C'est un client en attente d'occasion.
Surveiller dans la durée
Dernier point, et pas le moindre : la délivrabilité n'est pas un chantier ponctuel qu'on clôture.
Les rapports DMARC doivent être lus régulièrement, ne serait-ce que mensuellement. Les listes noires méritent un contrôle périodique. Et les exigences des fournisseurs se durcissent par paliers, comme février 2024 l'a rappelé brutalement à beaucoup d'entreprises.
Ce qui est conforme aujourd'hui ne le sera pas nécessairement dans dix-huit mois. Une configuration posée et jamais revue est une configuration qui vieillit mal.
Diagnostic : établir en une heure d'où vient le problème
Bonne nouvelle après ces avertissements : poser un diagnostic fiable ne demande ni outil payant ni compétence rare. Une heure suffit, avec un peu de méthode.
Lire les en-têtes d'un message reçu
C'est la vérification la plus rapide, la plus fiable, et paradoxalement la plus négligée.
Envoyez un message depuis l'adresse concernée vers une boîte Gmail ou Outlook. Dans Gmail, ouvrez le message, puis le menu à trois points, puis « Afficher l'original ». Dans Outlook, cherchez les propriétés du message.
Vous obtenez les trois verdicts, écrits noir sur blanc : spf=pass ou fail, dkim=pass ou fail, dmarc=pass ou fail.
Trois lignes qui vous disent en dix secondes où le bât blesse. Pourquoi commencer ailleurs ?
Les vérifications DNS de base
Deuxième couche : interroger directement la zone.
Les enregistrements TXT du domaine racine révèlent le ou les SPF, et permettent immédiatement de détecter un doublon. L'enregistrement du sélecteur DKIM confirme que la clé publique est bien publiée et lisible. Celui de _dmarc affiche la politique en vigueur, si elle existe.
Des outils publics gratuits font ces vérifications en ligne pour ceux qui préfèrent une interface à une ligne de commande. Ils sont nombreux et globalement équivalents, inutile d'en dresser un palmarès.
Le test d'envoi contrôlé
Troisième étape, la plus révélatrice.
Envoyez un message depuis chaque flux réel, pas seulement depuis votre messagerie. Un depuis Outlook. Un depuis la plateforme de newsletter. Un depuis le formulaire du site. Un depuis le module de facturation.
Adressez chacun vers plusieurs fournisseurs différents : Gmail, Outlook, Yahoo, et une adresse professionnelle chez un hébergeur français.
Puis comparez. Si tout échoue partout, le problème est global et sans doute structurel. Si un seul flux échoue, vous avez trouvé le coupable. Si tout passe sauf chez un fournisseur précis, il s'agit d'un problème de réputation localisé, qui appelle un traitement différent.
Vérifier les listes noires
Contrôlez l'IP émettrice et le domaine sur les principales listes de blocage.
Mais attention à la réaction réflexe. Découvrir un listing pousse à demander immédiatement un retrait. Sauf que le retrait ne tient jamais si la cause n'est pas traitée : vous serez relisté dans les jours qui suivent, avec un historique aggravé.
Comprendre l'origine d'abord. Corriger. Demander le retrait ensuite. Dans cet ordre.
Plan de remise en conformité
Étape par étape
La séquence, dans l'ordre, sans raccourci possible.
- Inventaire exhaustif des émetteurs, y compris les services oubliés.
- SPF unique et consolidé, sous la limite des dix résolutions DNS.
- DKIM activé et surtout publié sur chaque flux, vérifié individuellement.
- DMARC publié en politique none, avec adresse de réception des rapports.
- Analyse des rapports pendant plusieurs semaines, sans rien durcir.
- Correction des flux non alignés, un par un, en repassant par l'observation après chaque correction.
- Durcissement progressif : quarantine partiel, puis total, puis reject.
Ordre de grandeur des délais
Autant être honnête sur le calendrier, parce que les promesses de résultat immédiat font plus de dégâts qu'autre chose.
La propagation DNS prend de quelques minutes à quarante-huit heures selon les valeurs de cache configurées. La phase d'observation DMARC demande six à huit semaines pour être exploitable, moins ne couvre pas les cycles mensuels. Et la reconstruction d'une réputation de domaine dégradée se compte en mois, avec une montée en volume progressive.
Un dossier propre depuis le départ, avec un parc simple, peut être conforme en trois semaines. Un parc complexe où trois prestataires sont passés demandera plutôt un trimestre. C'est ainsi.
Ce qu'il ne faut surtout pas faire
La liste noire des mauvaises idées, chacune vue au moins une fois.
Empiler les enregistrements SPF au lieu de les fusionner. Publier une politique reject sans phase d'observation préalable. Changer de nom de domaine pour « repartir à zéro », ce qui revient à jeter aussi tout le capital SEO et la reconnaissance de marque, pour un problème parfaitement réparable. Acheter une base de contacts, méthode la plus rapide connue pour toucher un spam trap. Et démarrer un domaine neuf par un envoi de dix mille messages, ce qui déclenche à peu près tous les signaux d'alerte existants en une seule opération.
Conclusion : la délivrabilité est une question de gouvernance
SPF, DKIM et DMARC ressemblent à des réglages techniques réservés aux administrateurs système. Ils sont en réalité la traduction, en langage DNS, d'une question tout à fait stratégique : qui a le droit de parler au nom de votre entreprise ?
Tant que cette réponse reste floue, tant que personne ne sait vraiment quels outils émettent, ni qui détient les accès, ni ce que contient la zone DNS, ce sont les filtres qui tranchent. Et ils tranchent par défaut dans le sens de la prudence, c'est-à-dire contre vous.
Revenons à cette PME lyonnaise du début. L'origine de la panne tenait en une ligne : un second enregistrement SPF ajouté par un prestataire pour brancher un nouvel outil de devis, sans voir que le premier existait déjà. Deux SPF, donc aucun SPF valide. Le durcissement de Gmail a fait le reste, et trois semaines de prospection sont parties aux indésirables sans qu'aucun voyant ne s'allume.
La correction a pris vingt minutes. L'identifier en a demandé beaucoup plus, faute d'avoir jamais cartographié qui envoyait quoi.
Si vous ne savez pas répondre, là, maintenant, à la question « quels services envoient des emails en mon nom ? », il est probablement temps de faire auditer votre configuration d'envoi. Ce n'est ni long ni coûteux, et cela vaut mieux que de découvrir le problème en comptant les devis restés sans réponse.
