SPF, DKIM, DMARC : comprendre l’authentification des emails

Une newsletter préparée avec soin, une facture envoyée à temps, une notification de commande bien propre… puis rien. Le mail disparaît, ou finit en spam. Un scénario agaçant, et surtout coûteux quand il s’agit d’un email transactionnel ou d’une campagne marketing.

SPF, DKIM et DMARC ne sont pas des sigles pour faire joli. Ce sont les garde-fous techniques qui aident les serveurs à décider si un message est crédible ou non. Pour une boutique en ligne, des confirmations de commande qui tombent dans les indésirables inquiètent le client. Et une fausse facture envoyée sous son nom relève de l’usurpation d’identité et de la fraude par email.

À lire Réputation IP de l’expéditeur : la protéger et l’améliorer

SPF, DKIM, DMARC : le trio qui décide du sort de vos emails #

Le fonctionnement est assez simple, une fois le jargon écarté. SPF vérifie si le serveur qui envoie le message a le droit de le faire pour votre domaine. DKIM vérifie que le contenu n’a pas été trafiqué en route. DMARC, lui, arbitre : il dit au serveur destinataire quoi faire si SPF ou DKIM échouent.

Tout repose sur le DNS, c’est-à-dire la zone où sont publiées les règles liées au domaine. Le serveur d’envoi expédie le mail, le serveur de réception compare les informations, puis il tranche : accepté, mis en quarantaine ou rejeté.

Pour visualiser le rôle de chaque brique en quelques minutes, cette explication de Mike Chapple est l’une des plus claires du sujet — en anglais mais très visuelle :

À retenir d’emblée : un contenu bien rédigé ne compense pas une mauvaise authentification. Le meilleur objet du monde, le plus beau template, le CTA le plus malin — si le domaine n’est pas propre techniquement, la messagerie le rattrape vite.

SPF : qui a le droit d’envoyer au nom de votre domaine ? #

SPF, pour Sender Policy Framework, fonctionne comme une liste d’autorisation. Un enregistrement TXT publié dans le DNS indique les serveurs ou services autorisés à envoyer des emails pour le domaine. Simple sur le papier. Moins simple quand s’ajoutent un ERP, un outil marketing et un routeur SMTP maison sans documentation.

Exemple classique :

v=spf1 ip4:192.0.2.10 include:_spf.exemple.fr -all

À lire Meilleurs outils SEO : le comparatif pour choisir sans se tromper

Lecture : version SPF, autoriser l’IP 192.0.2.10, autoriser aussi le service inclus, puis refuser le reste avec -all. Côté serveur destinataire, c’est binaire : l’IP correspond ou non. Si elle ne figure pas dans la liste, le test échoue.

Un SPF mal fichu est presque aussi pénalisant qu’un SPF absent. Les erreurs les plus courantes :

• un SPF trop long (trop de include) qui casse ;
• plusieurs enregistrements SPF sur le même domaine ;
• un prestataire ajouté sans mise à jour du DNS ;
• des sous-domaines laissés de côté.

DKIM : signer vos emails comme on signe un contrat #

DKIM, pour DomainKeys Identified Mail, ajoute une signature numérique au message. Comme pour un contrat : sans signature, on doute ; avec une signature vérifiable, on respire. Le principe repose sur une clé privée côté expéditeur et une clé publique publiée dans le DNS.

Le serveur d’envoi signe certains éléments de l’email dans l’en-tête. Le serveur de réception récupère la clé publique et vérifie que la signature colle. Si le message a été modifié en route, le contrôle casse. C’est là que DKIM est précieux : il protège l’intégrité du contenu, pas juste l’adresse affichée.

À lire Outils SEO gratuits : ces petites pages qui récoltent des liens naturels, l’analyse de Jimenez Julien

En pratique, on privilégie une clé de 2048 bits — 1024 bits fait léger aujourd’hui. La clé se génère via le fournisseur SMTP, une console d’administration ou un outil dédié, puis l’enregistrement DNS associé est publié. Ensuite, on surveille : une rotation de clé oubliée ou un changement de prestataire sans mise à jour DNS, et c’est la panne sèche.

Détail qui fâche : certains domaines n’activent pas la signature par défaut. Tout semble en place, mais le mail sort sans signature. Un contrôle des en-têtes suffit à le vérifier.

DMARC : poser des règles claires aux serveurs destinataires #

DMARC est la couche de décision. Ce protocole dit au serveur de réception quoi faire si SPF et DKIM ne passent pas, ou si le domaine visible dans le champ « De : » n’est pas aligné avec le domaine validé techniquement — c’est l’alignement.

Les politiques DMARC sont simples : none pour observer, quarantine pour mettre en quarantaine, reject pour refuser. Le piège classique : aller trop vite. Un DMARC strict sans phase d’observation peut bloquer des campagnes, des factures, des mails de support parfaitement légitimes.

À lire Passer de Windows 10 à Windows 11 (guide débutant)

DMARC fournit aussi des rapports. Les rapports agrégés donnent une vue d’ensemble des envois ; les rapports détaillés aident à repérer les sources anormales, les erreurs de signature, les services oubliés. C’est un outil de pilotage, pas juste une case à cocher.

Délivrabilité : ce que les filtres antispam regardent vraiment #

Gmail, Microsoft 365 et les autres grands acteurs ne regardent pas seulement le contenu. Ils observent la réputation de l’IP, le volume d’envoi, les plaintes, la cohérence du domaine — et bien sûr les signaux SPF, DKIM et DMARC. L’authentification des emails pèse lourd dans la balance.

Un site e-commerce qui envoie ses confirmations sans signature DKIM et avec un SPF incomplet part avec un handicap. Avec une configuration complète SPF + DKIM + DMARC, les effets sont souvent visibles rapidement : moins de messages perdus, moins de faux positifs, une boîte de réception plus stable. Pas de magie, juste de la technique propre.

Un relais SMTP déjà armé pour SPF, DKIM et DMARC #

Gérer soi-même un serveur d’envoi implique de tenir la réputation des IP, les enregistrements DNS, la rotation des clés, les tests et les rapports. Pour une TPE, un éditeur de logiciel ou une équipe marketing sans administrateur messagerie dédié, passer par un relais SMTP spécialisé simplifie nettement l’équation : les enregistrements SPF et DKIM sont fournis prêts à publier, la signature est active d’office et le suivi des envois est intégré.

Concrètement, la démarche se réduit à récupérer les enregistrements fournis, les publier dans le DNS, tester les en-têtes d’un envoi réel, puis ajuster la politique DMARC. Moins d’erreurs DNS, un déploiement plus rapide, une maintenance allégée.

Comment SPF, DKIM et DMARC fonctionnent ensemble #

SPF vérifie l’autorisation d’envoi. DKIM vérifie l’intégrité du message. DMARC tranche et applique la politique. Le trio fonctionne parce que chaque brique couvre un angle différent — bien plus robuste qu’un contrôle isolé.

Le scénario mental à garder : un message part du serveur, SPF vérifie l’adresse IP, DKIM teste la signature, DMARC compare les résultats au domaine visible, puis le serveur destinataire accepte, met en quarantaine ou rejette. Si un maillon lâche, l’usurpation devient beaucoup plus difficile.

Mettre en place SPF, DKIM et DMARC sans se planter #

Première étape : inventorier toutes les sources d’envoi. Vraiment toutes — site web, CRM, logiciel de facturation, outil marketing, support client, prestataires externes. Ensuite, configurer le SPF avec les bonnes IP et les bons services, puis activer DKIM avec une clé de 2048 bits si possible.

Pour DMARC, la montée en puissance se fait par paliers :

• démarrer en none et observer les rapports ;
• corriger ce qui casse (sources oubliées, alignement) ;
• passer en quarantine, puis en reject quand tout est propre ;
• garder une trace écrite de chaque changement DNS.

Erreurs fréquentes à éviter #

Le classique absolu : plusieurs enregistrements SPF sur le même domaine — ça casse. Autre erreur fréquente : un DMARC en reject posé trop tôt, sans surveillance des rapports. S’y ajoute la clé DKIM oubliée après un changement de prestataire SMTP, un cas très courant.

Les migrations d’ERP sont aussi piégeuses : on change d’outil, on oublie le DNS, et les mails de relance partent de travers. Même chose après l’ajout d’un nouvel outil marketing. Sans politique d’envoi documentée, l’infrastructure de messagerie devient vite incohérente.

Vérifier sa configuration : les bons réflexes #

Pour tester, commencer par les en-têtes d’un mail envoyé vers une boîte de contrôle : vérifier les lignes SPF, DKIM et DMARC. Puis analyser les rapports DMARC reçus par le domaine — c’est là qu’apparaissent les sources inconnues, les erreurs d’alignement et les services oubliés.

Les équipes techniques regardent les contrôles DNS, les équipes marketing veulent savoir si les campagnes arrivent. Les deux ont raison. Un bon audit relie les deux mondes : configuration propre, suivi des retours, correction régulière. Et ce contrôle est à refaire périodiquement — un domaine statique n’existe pas longtemps.

En cas d’urgence, la marche à suivre est simple : contrôler les DNS, tester un envoi réel, lire les en-têtes, corriger. L’authentification n’est pas un luxe d’expert — c’est le prérequis pour que chaque email légitime arrive à destination.

FAQ #