SPF, DKIM, DMARC : trois protocoles, trois rôles, un seul objectif

On nous demande souvent « j'ai déjà DKIM, pourquoi ajouter SPF et DMARC ? » comme si les trois faisaient la même chose avec des noms différents. Ce n'est pas le cas : chacun répond à une question précise que se posent les serveurs de réception, et aucun des trois ne peut remplacer les deux autres. Pour une prospection B2B adressée, où chaque email compte, comprendre ce que fait exactement chaque protocole évite de croire qu'on est protégé alors qu'il manque une pièce.

Trois questions différentes posées par la boîte réceptrice

Quand un message arrive chez Gmail, Outlook ou un serveur d'entreprise, le filtre anti-spam ne se demande pas simplement « ce contenu ressemble-t-il à du spam ». Il pose d'abord trois questions techniques, indépendantes les unes des autres, avant même de lire l'objet du message : le serveur d'envoi a-t-il le droit d'agir au nom de ce domaine, le contenu du message a-t-il été altéré depuis son départ, et si l'une des deux vérifications échoue, que doit-on en faire.

SPF répond à la première question, DKIM à la deuxième, DMARC à la troisième. Ce sont trois mécanismes qui vivent dans des enregistrements DNS séparés, vérifiés à des moments différents du transit du message, et qui n'ont pas de recouvrement fonctionnel. Croire que l'un remplace l'autre revient à croire qu'une serrure remplace une alarme parce que les deux protègent la même porte.

C'est cette séparation des rôles qui explique pourquoi les recommandations actuelles de Google et Yahoo pour les expéditeurs exigent les trois, et pas seulement le plus simple à mettre en place.

SPF : la liste des serveurs autorisés à parler en votre nom

SPF (Sender Policy Framework) est un enregistrement TXT publié sur le DNS du domaine, qui liste les adresses IP ou services autorisés à envoyer des emails avec ce domaine dans l'adresse d'expédition. Le serveur receveur compare l'IP d'origine du message reçu à cette liste, sans se soucier du contenu du message ni de son intégrité — il vérifie uniquement la provenance.

Le rôle de SPF est donc strictement réseau : il empêche un tiers d'envoyer un email en se faisant passer pour votre-entreprise.fr depuis un serveur non déclaré. Sa limite structurelle est connue : SPF ne survit pas au transfert d'email. Si un message passe par un serveur relais ou une redirection avant d'arriver à destination, l'IP visible change et la vérification SPF échoue, même si l'envoi initial était parfaitement légitime.

Pour une prospection B2B qui passe par un CRM, une plateforme d'envoi ou un outil de séquençage, SPF est la garantie la plus basique et la plus fragile des trois — utile, mais insuffisante seule.

DKIM : la preuve que le message n'a pas été touché en chemin

DKIM (DomainKeys Identified Mail) fonctionne différemment : il appose une signature cryptographique sur le contenu du message au moment de l'envoi, vérifiable via une clé publique publiée dans le DNS. Le serveur receveur recalcule la signature à partir du message reçu et la compare à celle annoncée — si elles correspondent, le contenu n'a pas été modifié entre le départ et l'arrivée.

Contrairement à SPF, DKIM ne dépend pas de l'IP d'origine et survit donc au forwarding ou au passage par un serveur relais, ce qui en fait un signal plus robuste. Mais son rôle reste limité à l'intégrité du contenu : DKIM ne dit rien sur qui a le droit d'envoyer au nom du domaine, seulement que le message signé n'a pas été altéré.

Un email peut avoir une signature DKIM parfaitement valide tout en provenant d'un serveur non autorisé si SPF n'est pas en place à côté — DKIM prouve l'intégrité, pas la légitimité de l'expéditeur.

DMARC : l'arbitre qui prend la décision finale

DMARC (Domain-based Message Authentication, Reporting and Conformance) n'effectue aucune vérification propre : il s'appuie entièrement sur les résultats de SPF et DKIM, et indique au serveur receveur la politique à appliquer si l'un des deux échoue — ne rien faire, mettre en quarantaine (généralement le dossier spam), ou rejeter le message. C'est le seul des trois protocoles à jouer un rôle de décision plutôt que de vérification.

DMARC ajoute aussi une fonction que SPF et DKIM n'ont pas : les rapports. Le domaine propriétaire reçoit un résumé régulier des tentatives d'envoi en son nom, réussies ou échouées, ce qui permet de repérer une usurpation avant qu'elle ne fasse des dégâts sur la réputation du domaine.

Sans DMARC, SPF et DKIM peuvent tous les deux échouer sur un message frauduleux sans que rien n'indique explicitement au serveur receveur quoi en faire — chaque fournisseur applique alors sa propre logique par défaut, de façon incohérente d'un domaine de messagerie à l'autre.

Ce qui casse concrètement quand un seul manque

Sans SPF, n'importe qui peut techniquement envoyer un message avec votre domaine en adresse d'expédition depuis un serveur non autorisé, et rien ne l'en empêche à la vérification réseau. Les campagnes de phishing qui usurpent des domaines d'entreprises reposent souvent exactement sur cette faille.

Sans DKIM, un message qui transite par plusieurs relais ou passe par un forward perd toute garantie d'intégrité vérifiable, et SPF seul devient insuffisant dès que le chemin de l'email n'est pas direct — ce qui est fréquent avec les outils de prospection qui passent par des passerelles d'envoi tierces.

Sans DMARC, même avec SPF et DKIM correctement configurés, il n'existe aucune instruction claire pour le serveur receveur en cas d'échec de l'un des deux, et aucun rapport ne remonte en cas d'usurpation du domaine. C'est la combinaison la plus sournoise, car SPF et DKIM affichés « OK » individuellement donnent une fausse impression de sécurité complète.

• SPF seul — protège l'origine réseau mais casse dès qu'un forward ou un relais intervient
• DKIM seul — protège l'intégrité du contenu mais ne dit rien sur qui a le droit d'envoyer
• DMARC seul — n'a littéralement rien à arbitrer si SPF et DKIM ne sont pas en place
• Les trois désalignés (domaines différents dans From, Return-Path, signature DKIM) — chaque vérification peut passer individuellement sans que DMARC les considère comme alignées

Ce qu'on vérifie chez LDM avant de considérer un domaine prêt

Avant d'ouvrir une campagne de prospection ciblée sur un domaine, on contrôle les trois protocoles séparément plutôt que de se fier à un score global : SPF valide et unique sur le domaine, DKIM actif avec signature confirmée sur un envoi test, DMARC présent avec un alignement correct entre le domaine du From et celui vérifié par SPF et DKIM. Les trois cases doivent être cochées indépendamment, parce qu'un domaine peut afficher SPF « pass » et DKIM « pass » individuellement tout en échouant à l'alignement DMARC — un piège fréquent avec les sous-domaines d'envoi.

Ce contrôle en trois temps distincts, plutôt qu'un simple coup d'œil global, évite de découvrir après coup qu'un des trois protocoles manquait alors que les deux autres semblaient rassurants.

Questions fréquentes