Comment configurer SPF, DKIM et DMARC sans se tromper ? #

On va aller droit au but : tant que vos emails ne sont pas correctement authentifiés avec SPF, DKIM et DMARC, une partie finira en spam, sera rejetée, ou nourrira les tentatives de phishing sur votre nom de domaine. La bonne nouvelle, c’est que tout se joue dans vos enregistrements DNS, donc sur terrain connu pour quiconque a déjà touché à une zone DNS.

SPF, DKIM, DMARC : ce que vous devez comprendre avant de toucher au DNS #

Avant d’éditer la moindre entrée TXT, il faut avoir la photo globale. SPF vérifie qui a le droit d’envoyer des emails pour votre domaine. DKIM ajoute une signature numérique aux messages, liée à une clé publique stockée dans le DNS. DMARC, lui, regarde les résultats SPF/DKIM et décide ce qu’on fait d’un email douteux, en lien avec le champ « De » (From).

À lire Grille tarifaire création site internet : à quoi s’attendre vraiment

Si on simplifie, SPF gère les serveurs autorisés, DKIM protège l’intégrité du message, DMARC applique la politique DMARC et envoie des rapports. Les registres comme l’Afnic, les guides techniques type It-Connect ou Cloudflare rappellent tous la même chose : ces protocoles sont des standards d’authentification email qui s’appuient sur les DNS records. Sans eux, une boîte de messagerie moderne ne fait pas vraiment confiance à votre domaine.

Pourquoi tant d’emails finissent en spam sans authentification #

Résultat concret, parfois brutal : vous envoyez une newsletter propre, texte travaillé, visuels légers, lien de désinscription clair… et malgré tout, chez Gmail et Outlook, la majorité finit en dossier spam. Sur Yahoo, certains messages sont carrément rejetés. Rien à voir avec votre contenu, le problème vient de l’authentification des emails.

Les fournisseurs de services email se servent de ces standards d’email security pour mesurer la délivrabilité des emails et la réputation du domaine. Un domaine sans SPF, DKIM ou DMARC se retrouve vite dans la même catégorie que celui des spammeurs, tout simplement parce qu’il n’apporte aucune preuve technique sérieuse sur l’origine des messages. On ne va pas se mentir : lancer des campagnes sans ces réglages, c’est tirer dans le noir.

Comprendre SPF sans jargon inutile #

SPF, pour Sender Policy Framework, répond à une question très simple : « Quels serveurs ont le droit d’envoyer des emails au nom de mon domaine ? ». Techniquement, vous créez un enregistrement TXT dans la zone DNS, de type :

À lire Site sur mesure ou thème prêt-à-l’emploi : lequel naît vraiment SEO-ready ? Julien Jimenez tranche

v=spf1 ip4:203.0.113.15 include:service-email.com mx ~all

On y trouve des mécanismes comme ip4 (adresse IPv4 autorisée), mx (serveurs de messagerie de votre domaine), include (on délègue la gestion à un fournisseur externe, typiquement un outil d’emailing). Là où les choses se corsent, c’est la limite technique : le protocole SPF limite à 10 consultations DNS (lookups). Quand on empile les « include: », on arrive vite à cette limite.

Dans ce cas, on parle de « flattening » : l’idée est de remplacer des « include » par des IP directes ou par une version simplifiée de l’enregistrement pour éviter les requêtes en cascade. On peut trouver que beaucoup d’entreprises sous-estiment ce point, alors qu’il suffit d’un SPF trop long pour basculer en « permerror » chez certains fournisseurs de messagerie.

DKIM, la signature qui protège vos messages en transit #

DKIM, DomainKeys Identified Mail, ajoute une signature DKIM au message. Le serveur d’envoi signe le contenu avec une clé privée, et publie la clé publique dans un enregistrement TXT de type selector._domainkey.votredomaine.fr. À la réception, le serveur de messagerie vérifie que la signature correspond toujours au contenu.

À lire Créer un SaaS sur-mesure avec de l’IA : cadrage, MVP, coûts d’inférence et budgets

Si le message est altéré pendant le transport (ajout de contenu suspect, manipulation de certains champs), la signature ne colle plus et le contrôle échoue. C’est là que les sélecteurs DKIM entrent en jeu : ils permettent de gérer plusieurs clés pour un même domaine, par exemple un sélecteur différent pour la messagerie interne et pour la plateforme d’emailing.

Si la clé publique est mal copiée dans le DNS, rien ne fonctionne. Vous pouvez envoyer autant de tests que vous voulez, les en-têtes afficheront « dkim=fail ». On doit générer les clés proprement, respecter la syntaxe (souvent du RSA sur 1024 ou 2048 bits), et publier l’enregistrement à l’endroit précis demandé par le fournisseur de services email ou par le serveur de messagerie.

DMARC, le vrai arbitre entre SPF et DKIM #

DMARC, pour Domain-based Message Authentication, Reporting and Conformance, ne remplace pas SPF et DKIM, il s’appuie dessus. Une fois que le serveur a testé SPF et DKIM, DMARC regarde le résultat et vérifie si les domaines sont alignés avec le « From ». Si ça coince, la politique DMARC décide : on laisse passer, on met en quarantaine, ou on rejette.

Un enregistrement classique ressemble à ça :

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1;

On commence généralement par p=none, mode observation. Les rapports DMARC agrégés, envoyés en XML, contiennent les sources d’envoi, les résultats SPF/DKIM et les volumes de messages. C’est là que beaucoup d’équipes se perdent, parce que ces fichiers sont denses, parfois peu lisibles sans outil de visualisation. Pourtant, c’est le meilleur moyen d’identifier les services qui envoient des emails au nom du domaine sans qu’on s’en soit rendu compte.

Ce qu’il faut préparer avant la configuration #

Si on veut éviter les mauvaises surprises, il faut préparer le terrain. Le piège le plus courant, c’est de n’avoir en tête que la messagerie principale, alors que le domaine sert aussi à des emails marketing, des notifications de ticketing, des factures, des SMS-to-email, etc.

• Lister tous les domaines d’envoi d’emails (domaine principal, sous-domaines marketing, domaines techniques).
• Identifier les services tiers : plateforme d’emailing, CRM, outil de support, ERP, solution de facturation.
• Vérifier les accès au DNS : hébergeur, registrar, fournisseur DNS managé.
• Prévoir une boîte dédiée pour les rapports DMARC.

On sous-estime souvent l’impact d’un CRM ou d’un outil de ticketing. Ces systèmes envoient des messages au nom du domaine, et si vous oubliez de les intégrer dans la configuration SPF ou dans les signatures DKIM, leurs emails seront mal authentifiés et abîmeront la réputation d’email globale.

Configurer SPF pas à pas dans votre zone DNS #

Résultat attendu : au bout de la configuration, chaque email sortant provient d’une IP ou d’un service explicitement listé dans votre SPF. Pour y arriver, la méthode reste assez simple, à condition de rester rigoureux.

• Inventorier les serveurs et services d’envoi (IP, MX, outils d’emailing).
• Écrire un enregistrement TXT SPF unique, en respectant la syntaxe.
• Limiter les « include » pour rester sous le seuil des 10 lookups DNS.
• Tester l’enregistrement avec un outil de vérification SPF, jusqu’à obtenir un « spf=pass » dans les en-têtes.

Exemple pour un domaine simple, messagerie interne + plateforme d’emailing :

La pose des enregistrements dans la zone DNS est montrée pas à pas ici :

v=spf1 mx include:service-email.com ~all

Ici, « mx » indique que les serveurs de messagerie déclarés dans le DNS sont autorisés à envoyer, et « include » délègue à un fournisseur qui gère ses propres IP. Le ~all reste plus tolérant que -all, souvent utilisé au début quand on n’est pas certain d’avoir tout couvert. Mieux vaut garder sous la main au moins un outil de test SPF pour vérifier la résolution complète des includes et voir si on frôle la limite de lookups.

Mettre DKIM en place sur votre serveur ou votre outil d’envoi #

Pour DKIM, la démarche ressemble à un mode d’emploi assez carré : générer la clé, publier la clé publique, activer la signature, puis tester. On ne gagne rien à bricoler, chaque caractère compte.

• Générer une paire de clés (publique/privée) depuis votre serveur de messagerie ou votre ESP.
• Créer l’enregistrement TXT dans le DNS, au nom du sélecteur fourni.
• Activer la signature DKIM dans les réglages du serveur ou de l’outil d’envoi.
• Envoyer un email de test et analyser les en-têtes (Authentication-Results).

Un enregistrement type :

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA...

Si la clé publique est tronquée ou si vous la placez au mauvais endroit (mauvais nom de sous-domaine, mauvais type d’enregistrement), la vérification échoue systématiquement. On voit parfois des projets où tout le monde pense que DKIM est actif, alors que les emails signés utilisent un autre domaine que celui visible dans le From. Résultat : DMARC chute, et personne ne comprend pourquoi.

D’où l’intérêt de lire attentivement les en-têtes, même si ce n’est pas l’exercice préféré des équipes marketing.

DMARC : partir en surveillance avant de bloquer #

Sur DMARC, je défends toujours la même approche : commencer en « p=none », analyser les rapports, ajuster, puis seulement après monter vers « quarantine » et « reject ». Passer directement en rejet, sans phase d’observation, c’est prendre le risque de bloquer des emails légitimes.

Exemple d’enregistrement de départ :

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r;

Ensuite, quand on est sûr que tous les flux d’envoi respectent la politique DMARC et que l’alignement des domaines est maîtrisé, on peut passer à :

v=DMARC1; p=quarantine; rua=mailto:[email protected];

Puis, à terme, à « p=reject » pour les organisations qui veulent une email security plus stricte. Les rapports agrégés jouent un rôle central : ils révèlent les services oubliés, les vieux serveurs encore actifs, les campagnes d’emailing qui utilisent un autre domaine d’envoi. On a parfois des surprises sur des sources qu’on pensait éteintes.

Tester la configuration et lire les en-têtes d’un email #

On peut passer des heures à théoriser. Dans la pratique, le test le plus utile reste extrêmement simple : envoyer un email vers une boîte de test, ouvrir les en-têtes, et regarder si SPF, DKIM et DMARC marquent « pass ».

Dans les en-têtes, la ligne « Authentication-Results » contient des indicateurs du type :

spf=pass, dkim=pass, dmarc=pass

Si SPF échoue, on vérifie que l’IP utilisée est bien dans l’enregistrement, ou que l’include gère ce cas. Si DKIM échoue, direction l’enregistrement TXT du sélecteur, pour contrôler la clé. Si DMARC échoue alors que SPF et DKIM passent, il y a souvent un problème d’alignement : le domaine visible dans le From n’est pas celui utilisé pour SPF ou DKIM.

Un conseil simple : garder à portée de main quelques outils de vérification en ligne, qui affichent les résultats SPF/DKIM/DMARC de façon lisible. Ça évite de se perdre dans des en-têtes longs et peu digestes.

Les erreurs qui ruinent la délivrabilité dès la première semaine #

Les projets échouent rarement sur la théorie, mais sur des détails très concrets. Voici quelques pièges que on observe revenir souvent :

• Un enregistrement SPF trop long, qui dépasse la limite de 10 consultations DNS, et finit en erreur permanente.
• L’oubli d’un service tiers (CRM, ticketing) qui continue à envoyer des emails au nom du domaine sans être déclaré.
• Une clé DKIM mal alignée ou un sélecteur mal renseigné, qui fait échouer la signature.
• Un DMARC « p=reject » activé trop tôt, sans analyse préalable des rapports.
• Des rapports DMARC jamais lus, alors que c’est l’outil le plus précieux pour la gouvernance des emails.

On ne va pas se mentir, la partie « reporting and analytics » n’est pas la plus attirante. Pourtant, c’est là que se joue la capacité à repérer du spoofing, à suivre la email reputation du domaine, et à ajuster les politiques sans tout casser.

Où trouver un accompagnement sur l’authentification #

Quand on n’a pas envie de passer une demi-journée à démêler les subtilités des standards d’authentification des emails, on gagne du temps en s’appuyant sur un guide structuré. C’est justement ce que fait routage-email avec son contenu dédié à SPF, DKIM et DMARC, orienté délivrabilité des emails.

À quel moment passer de la théorie à la configuration réelle ? #

À partir du moment où vous avez identifié vos domaines d’envoi, listé les services, compris le rôle de SPF, DKIM et DMARC, il faut arrêter de rester dans le concept. On gagne plus à créer un enregistrement SPF, une clé DKIM et un DMARC en p=none, puis à envoyer trois ou quatre emails de test, qu’à lire un énième article théorique.

La vraie bascule se fait quand vous ouvrez les rapports DMARC et que vous voyez noir sur blanc les IP et services qui parlent au nom de votre domaine. À partir de là, on passe de la « théorie » à une gouvernance concrète des emails, avec des décisions sur ce qu’on autorise, ce qu’on corrige, et ce qu’on bloque.

Si vous hésitez sur l’ordre des étapes, rien n’empêche de vous appuyer sur un guide comme celui de routage-email pour structurer cette mise en place et éviter les erreurs qui flinguent la délivrabilité dès la première semaine.

Questions fréquentes #

Dans quel ordre configurer SPF, DKIM et DMARC ?

SPF puis DKIM, car DMARC s’appuie sur eux. On publie ensuite DMARC en mode surveillance, le temps de vérifier que les envois légitimes passent, avant d’appliquer une politique plus stricte.

Que se passe-t-il si j’oublie un outil dans SPF ?

Les messages envoyés par cet outil échoueront à la vérification. Selon votre politique DMARC, ils pourront être classés en indésirables ou rejetés. D’où l’intérêt de commencer en surveillance.

Faut-il un enregistrement par sous-domaine ?

Les sous-domaines qui envoient des emails ont besoin de leur propre configuration. DMARC permet toutefois de définir une politique héritée pour les sous-domaines.