SPF, DKIM, DMARC : le guide complet de la sécurité des emails

L’email reste le premier vecteur d’intrusion dans les organisations : hameçonnage, fraude au président, faux ordres de virement, diffusion de rançongiciels. Cette exposition tient en partie à une faiblesse d’origine. Le protocole SMTP, conçu en 1982, ne prévoyait ni chiffrement ni vérification de l’expéditeur. N’importe quel serveur peut encore aujourd’hui envoyer un message en affichant l’adresse d’un autre domaine.

Pour corriger ces faiblesses, l’IETF (Internet Engineering Task Force) a standardisé en quarante ans une série de mécanismes complémentaires : SPF, DKIM et DMARC pour l’authentification, STARTTLS, MTA-STS et DANE pour le chiffrement, DNSSEC pour sécuriser le socle DNS sur lequel ils reposent tous. Ce guide explique à quoi sert chacun de ces standards, comment ils s’articulent et quelles décisions ils impliquent pour un responsable sécurité ou un dirigeant. Il ne s’agit pas d’un manuel de configuration, mais d’une grille de compréhension et d’arbitrage.

La sécurité des emails repose sur deux piliers indissociables

Protéger une messagerie revient à répondre à deux questions distinctes.

La première concerne la confidentialité du transport : un email peut-il être intercepté, lu ou modifié pendant son acheminement entre le serveur de l’expéditeur et celui du destinataire ? C’est le rôle du chiffrement en transit.

La seconde concerne l’authenticité de l’expéditeur : le message provient-il réellement du domaine qu’il affiche, et son contenu est-il resté intact ? C’est le rôle des mécanismes d’authentification.

Ces deux piliers ne se compensent pas. Un email parfaitement chiffré mais envoyé par un imposteur reste une attaque d’ingénierie sociale réussie. À l’inverse, un email parfaitement authentifié mais transmis en clair peut être lu par un acteur positionné sur le réseau. Une organisation qui n’investit que dans l’un des deux piliers laisse une brèche ouverte sur l’autre.

Huit standards remplissent chacun un rôle précis

Les acronymes se multiplient, mais chaque standard répond à une fonction claire. Le tableau ci-dessous les résume ; les sections suivantes les détaillent.

SPF, DKIM et DMARC bloquent l’usurpation d’identité

Le protocole SMTP permet d’inscrire n’importe quelle adresse dans le champ « De : » affiché au destinataire. C’est cette liberté qu’exploitent les campagnes d’hameçonnage et de fraude au président. Trois standards, qui fonctionnent ensemble, permettent d’y mettre fin.

SPF déclare les serveurs autorisés à envoyer

SPF (Sender Policy Framework) est un enregistrement publié dans le DNS du domaine qui liste les serveurs et services habilités à envoyer des emails en son nom : la messagerie de l’organisation, mais aussi l’outil de newsletter, le CRM ou la plateforme de facturation. Le serveur destinataire vérifie si l’adresse IP de l’expéditeur figure dans cette liste.

SPF présente trois limites que tout responsable sécurité doit connaître. Il vérifie l’adresse technique de l’enveloppe du message, et non l’adresse « De : » visible par l’utilisateur. Il échoue dès qu’un email est redirigé automatiquement, car le serveur de redirection ne figure pas dans la liste. Enfin, la norme limite à dix le nombre de consultations DNS nécessaires pour évaluer un enregistrement : une organisation qui accumule les prestataires d’envoi dépasse vite ce seuil, et son SPF devient alors invalide sans que personne ne s’en aperçoive.

DKIM signe chaque message

DKIM (DomainKeys Identified Mail) ajoute à chaque email une signature cryptographique. Le serveur d’envoi signe le contenu et les principaux en-têtes (expéditeur, date, objet) avec une clé privée ; le destinataire récupère la clé publique correspondante dans le DNS et vérifie la signature. Si le message a été modifié en route, ou s’il ne provient pas du détenteur de la clé, la vérification échoue.

Contrairement à SPF, la signature DKIM voyage avec le message et survit à la plupart des redirections. Côté gouvernance, deux points méritent une attention particulière : la longueur des clés (2048 bits est aujourd’hui le minimum raisonnable pour RSA) et leur rotation régulière, qui relève de la même hygiène que celle des autres secrets cryptographiques de l’organisation.

DMARC donne l’ordre de bloquer

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la pièce qui transforme SPF et DKIM en protection effective. Pris isolément, ces deux mécanismes constatent une anomalie sans dire au destinataire quoi en faire. DMARC comble ce vide avec trois fonctions.

La première est l’alignement. DMARC exige que le domaine validé par SPF ou par DKIM corresponde au domaine affiché dans le champ « De : ». C’est ce contrôle qui empêche enfin l’usurpation visible. Il suffit que l’un des deux mécanismes soit valide et aligné pour que le message passe. L’alignement peut être relâché (un sous-domaine est accepté) ou strict (correspondance exacte).

La deuxième est la politique, que le propriétaire du domaine choisit parmi trois niveaux :

• p=none (observation) : les emails non conformes sont livrés normalement. Ce mode sert uniquement à cartographier les flux légitimes avant de durcir.
• p=quarantine (isolement) : les emails non conformes sont dirigés vers le dossier des indésirables.
• p=reject (rejet) : les emails non conformes sont refusés avant même d’atteindre la boîte du destinataire.

La troisième est le reporting. Les fournisseurs de messagerie envoient au propriétaire du domaine des rapports quotidiens agrégés indiquant quels serveurs ont envoyé des emails en son nom et avec quel résultat. Ces rapports révèlent à la fois les tentatives d’usurpation et les services légitimes oubliés lors de l’inventaire. Les rapports d’échec individuels, également prévus par la norme, sont en revanche très peu transmis par les grands fournisseurs pour des raisons de confidentialité.

Le point essentiel pour un décideur tient en une phrase : un domaine en p=none n’est pas protégé. Il est observé. Seuls les niveaux quarantine et reject empêchent la livraison d’emails frauduleux.

DMARCbis : ce qui change en 2026

Publiée en 2015, la première version de DMARC (RFC 7489) n’avait qu’un statut informationnel. En mai 2026, l’IETF a publié sa révision, connue sous le nom de DMARCbis, en trois documents : RFC 9989 pour le protocole, RFC 9990 pour les rapports agrégés et RFC 9991 pour les rapports d’échec. DMARC devient ainsi pour la première fois un standard officiel de l’IETF (Proposed Standard).

Pour une organisation déjà équipée, la transition est douce : les enregistrements existants restent valides. Les changements notables sont les suivants :

• la balise pct, qui permettait d’appliquer la politique à un pourcentage des messages, disparaît au profit d’un mode test binaire (balise t) ;
• une nouvelle balise np permet de fixer une politique pour les sous-domaines inexistants, une faille que les attaquants exploitaient en inventant des sous-domaines plausibles ;
• la détermination du domaine organisationnel ne dépend plus d’une liste externe (la Public Suffix List), mais d’une consultation directe du DNS ;
• la norme met désormais en garde contre la politique p=reject pour les domaines dont les utilisateurs écrivent sur des listes de diffusion, sauf si le risque a été mesuré et maîtrisé.

Au-delà de la technique, le changement de statut compte : DMARC n’est plus une bonne pratique recommandée, mais un standard de référence. Les exigences des grands fournisseurs de messagerie pour les expéditeurs de gros volumes et les attentes des référentiels réglementaires comme NIS2 s’appuient désormais sur une norme stabilisée.

STARTTLS, MTA-STS et DANE rendent le chiffrement obligatoire

Le second pilier concerne le transport. Lorsqu’un email quitte le serveur de l’expéditeur, il transite par Internet jusqu’au serveur du destinataire. Sans chiffrement, il circule en clair et peut être lu par tout acteur capable d’observer le trafic.

STARTTLS chiffre, mais seulement si personne ne s’y oppose

STARTTLS permet à deux serveurs de messagerie de basculer une connexion initialement en clair vers une connexion chiffrée par TLS. Il est aujourd’hui très largement déployé.

Sa faiblesse est structurelle : le chiffrement est opportuniste. Si le serveur destinataire ne l’annonce pas, l’envoi se poursuit en clair, sans erreur ni alerte. Un attaquant placé entre les deux serveurs peut donc supprimer cette annonce et forcer une transmission non chiffrée : c’est l’attaque par rétrogradation (downgrade). STARTTLS protège contre l’écoute passive, pas contre un attaquant actif.

Une exigence de configuration s’ajoute : les serveurs doivent refuser les versions obsolètes du protocole et n’accepter que TLS 1.2 ou TLS 1.3.

MTA-STS impose le chiffrement via le web

MTA-STS (Mail Transfer Agent Strict Transport Security) permet à un domaine de déclarer publiquement que ses serveurs exigent une connexion chiffrée avec un certificat valide. Cette politique est publiée sur un site web sécurisé et signalée dans le DNS. Un serveur expéditeur compatible la consulte et refuse de transmettre l’email si le chiffrement ne peut pas être établi correctement.

MTA-STS a l’avantage de ne pas exiger DNSSEC, ce qui le rend accessible à la plupart des organisations. Google et Microsoft l’appliquent pour leurs services de messagerie. Sa limite : la politique est mise en cache par les expéditeurs, et le tout premier contact avec un domaine reste exposé.

DANE ancre la confiance dans le DNS

DANE (DNS-based Authentication of Named Entities) va plus loin. Le propriétaire du domaine publie dans son DNS l’empreinte du certificat de son serveur de messagerie. Un serveur expéditeur compatible vérifie que le certificat présenté correspond à cette empreinte ; en cas d’absence de chiffrement ou de certificat non conforme, l’email est mis en attente au lieu d’être transmis.

DANE neutralise ainsi à la fois la rétrogradation et l’usage de certificats frauduleux, même émis par une autorité de certification compromise. Il repose cependant entièrement sur DNSSEC : sans signature des réponses DNS, un attaquant pourrait falsifier l’empreinte publiée. Microsoft le présente comme la référence pour sécuriser les échanges SMTP et le prend en charge sur Exchange Online, en entrée comme en sortie.

Le principal risque de DANE est opérationnel : lors du renouvellement d’un certificat, l’empreinte publiée dans le DNS doit être mise à jour de manière coordonnée. Une erreur bloque la réception des emails provenant des expéditeurs qui appliquent DANE.

MTA-STS ou DANE : un choix qui n’en est pas un

Les deux mécanismes peuvent coexister sur un même domaine, et c’est la recommandation la plus robuste : chaque expéditeur applique celui qu’il supporte. Le choix se fait plutôt sur l’ordre de déploiement. MTA-STS est rapide à mettre en place et couvre les grands fournisseurs. DANE apporte une garantie plus forte, mais suppose que DNSSEC soit déjà déployé et maîtrisé.

Dans les deux cas, TLS-RPT complète le dispositif : il permet de recevoir des rapports sur les échecs de chiffrement constatés par les expéditeurs, et donc de détecter une panne ou une attaque.

Ce que le chiffrement en transit ne protège pas

STARTTLS, MTA-STS et DANE protègent l’email pendant son transport entre serveurs. Ils ne le protègent ni sur le poste de l’expéditeur, ni sur les serveurs intermédiaires, ni une fois stocké dans la boîte du destinataire. Pour garantir que seul le destinataire peut lire un message, il faut un chiffrement de bout en bout, comme S/MIME ou OpenPGP. Ces solutions relèvent d’un autre niveau de décision (gestion des certificats utilisateurs, interopérabilité avec les partenaires) et ne remplacent pas les standards décrits ici.

DNSSEC sécurise le socle sur lequel tout repose

Tous les mécanismes présentés dans ce guide publient leurs informations dans le DNS : liste des serveurs autorisés pour SPF, clés publiques pour DKIM, politique pour DMARC, empreintes de certificats pour DANE. Si un attaquant peut falsifier les réponses DNS, il peut contourner l’ensemble du dispositif.

DNSSEC (DNS Security Extensions) signe cryptographiquement les réponses DNS et permet de vérifier qu’elles proviennent bien du propriétaire légitime du domaine. Il est indispensable pour DANE et renforce tous les autres standards. Son déploiement dépend en grande partie du registre et de l’hébergeur DNS ; la question mérite d’être posée explicitement à chaque prestataire.

Les pièges qui font échouer les déploiements

La plupart des domaines ne restent pas mal protégés par ignorance des standards, mais parce que le déploiement se bloque à mi-chemin. Cinq situations reviennent régulièrement.

Rester indéfiniment en p=none. La phase d’observation est nécessaire, mais elle devient un piège lorsqu’elle se prolonge faute de ressources pour analyser les rapports. Le domaine affiche alors une configuration DMARC, sans protection réelle.

Oublier les services tiers. Outils marketing, plateformes RH, logiciels de facturation : chaque prestataire qui envoie des emails au nom de l’organisation doit être déclaré dans SPF et, idéalement, signer avec DKIM. Un inventaire incomplet provoque le rejet d’emails légitimes au passage en reject, et incite souvent à revenir en arrière.

Négliger les domaines qui n’envoient pas d’emails. Les domaines secondaires, les anciennes marques et les domaines réservés pour se protéger du typosquatting sont des cibles idéales, car personne ne surveille leur usage. Ils doivent déclarer explicitement qu’aucun serveur n’est autorisé à envoyer en leur nom (SPF sans serveur autorisé, DMARC en p=reject et, si possible, un enregistrement indiquant qu’ils ne reçoivent pas d’emails).

Ignorer les redirections et les listes de diffusion. Ces flux modifient les messages ou changent leur chemin, ce qui peut faire échouer SPF et DKIM. Le standard ARC (Authenticated Received Chain) permet aux intermédiaires de préserver les résultats d’authentification, mais son support reste inégal. C’est l’une des raisons pour lesquelles DMARCbis appelle à mesurer ce risque avant d’imposer le rejet.

Déployer DANE sans processus de renouvellement. Sans coordination entre l’équipe qui gère les certificats et celle qui gère le DNS, un renouvellement de routine peut interrompre la réception des emails.

De p=none à p=reject : une trajectoire de déploiement

Le passage à une protection effective suit une progression éprouvée, qui s’étale généralement sur plusieurs semaines à quelques mois selon la complexité de l’organisation.

1. Inventorier tous les services qui envoient des emails au nom de chaque domaine de l’organisation, y compris les domaines inactifs.
2. Publier SPF et activer DKIM pour chaque service légitime.
3. Publier DMARC en p=none avec une adresse de réception des rapports, et outiller leur analyse.
4. Corriger les flux légitimes qui échouent, jusqu’à ce que les rapports ne montrent plus que des usages frauduleux ou inconnus.
5. Passer en p=quarantine, en utilisant si nécessaire le mode test prévu par DMARCbis, puis en p=reject.
6. Verrouiller le transport avec MTA-STS et TLS-RPT, puis avec DANE lorsque DNSSEC est en place.
7. Maintenir : chaque nouveau prestataire d’envoi doit être intégré au dispositif avant sa mise en service, et les rapports doivent rester suivis dans la durée.

Questions fréquentes sur la sécurité des emails