L'authentification e-mail expliquée : SPF, DKIM et DMARC pour les défenseurs

L'e-mail reste le vecteur de livraison numéro un pour le hameçonnage, la compromission de messagerie d'entreprise et les logiciels malveillants, et presque tout repose sur une seule faiblesse : l'adresse From: que voit le destinataire est triviale à falsifier tant que vous ne publiez pas les bons enregistrements d'authentification. Cet article s'adresse à la blue team. Il explique SPF, DKIM et DMARC sous un angle purement défensif : ce que chaque contrôle prouve, comment les trois s'imbriquent, comment lire la télémétrie qu'ils produisent et comment amener votre domaine à une politique d'application sans casser le courrier légitime.

Pourquoi l'usurpation d'e-mail est si facile par défaut#

SMTP a été conçu à une époque de confiance mutuelle et n'a aucune vérification d'identité intégrée. Chaque message porte deux identités d'expéditeur : l'expéditeur d'enveloppe (le MAIL FROM utilisé pendant la transaction SMTP, aussi appelé Return-Path) et le From d'en-tête que les clients de messagerie affichent réellement. Un attaquant peut fixer les deux à sa guise. Sans enregistrements d'authentification, un serveur récepteur n'a aucune base cryptographique ou de politique pour rejeter un message se prétendant issu de votre domaine. Les trois standards ci-dessous ajoutent cette base, chacun couvrant une lacune différente.

SPF : autoriser l'infrastructure d'envoi#

Sender Policy Framework (SPF) est un enregistrement TXT DNS qui liste les adresses IP et hôtes autorisés à envoyer du courrier avec votre domaine dans l'expéditeur d'enveloppe. Un récepteur consulte v=spf1 ... pour le domaine d'enveloppe et vérifie si l'IP connectée est autorisée. L'enregistrement se termine par un mécanisme all : -all signifie échec strict (rejeter le non listé), ~all échec léger (accepter mais marquer) et +all est dangereux et ne doit jamais servir. SPF a deux limites importantes : il valide l'expéditeur d'enveloppe, pas le From visible, et il casse au transfert car le relais devient la nouvelle IP connectée. Il plafonne aussi à dix requêtes DNS, si bien que des chaînes include: tentaculaires peuvent basculer un enregistrement en permerror en silence.

DKIM : signer cryptographiquement le message#

DomainKeys Identified Mail (DKIM) attache une signature numérique aux messages sortants. Votre plateforme de messagerie signe des en-têtes choisis et le corps avec une clé privée ; la clé publique correspondante est publiée dans le DNS à selecteur._domainkey.votredomaine. Un récepteur recalcule le hachage et vérifie la signature, prouvant que le contenu signé n'a pas été altéré en transit et qu'il a été signé par une clé que votre domaine contrôle. Comme la signature voyage dans le message, DKIM survit à la plupart des transferts, contrairement à SPF. Faites tourner les sélecteurs périodiquement, utilisez des clés d'au moins 2048 bits et retirez les anciens sélecteurs pour qu'une clé historique divulguée ne puisse être détournée.

DMARC : alignement, politique et rapports#

DMARC lie SPF et DKIM au From d'en-tête que les utilisateurs voient réellement, via un concept nommé alignement. Un message passe DMARC s'il passe SPF et que le domaine SPF s'aligne au From, ou s'il passe DKIM et que le domaine DKIM s'aligne : un seul suffit. La politique DMARC est un enregistrement TXT DNS à _dmarc.votredomaine avec la politique p=none (surveillance seule), p=quarantine (envoyer au spam) ou p=reject (refuser). Point crucial, DMARC demande aussi des rapports : agrégés XML via rua= et, quand c'est proposé, échantillons forensiques via ruf=. Ces rapports sont votre télémétrie de détection principale.

La surface d'attaque que ces contrôles couvrent#

Comprendre ce contre quoi vous vous défendez aide à régler la politique. L'usurpation de domaine exact falsifie votre propre domaine dans le From et c'est précisément ce que DMARC en application arrête. Les domaines cousins ou ressemblants (enregistrer un nom visuellement similaire) ne sont pas couverts par votre enregistrement DMARC et exigent une surveillance de marque et une sensibilisation. L'usurpation du nom d'affichage garde une adresse légitime dans l'enveloppe mais fixe un nom trompeur, ce que l'authentification ne peut détecter et qui nécessite des avertissements côté client. Connaître ces limites évite un faux sentiment de sécurité une fois DMARC en reject.

Détection : lire les rapports agrégés DMARC#

Les rapports agrégés (RUA) arrivent quotidiennement en XML depuis chaque récepteur, résumant les comptes de messages groupés par IP source, résultat SPF, résultat DKIM et disposition DMARC. Injectez-les dans un analyseur ou un tableau de bord hébergé plutôt que de lire du XML brut. Surveillez trois signaux : des IP d'envoi inconnues qui passent ou échouent pour votre domaine (un outil marketing dont personne n'a parlé, ou un attaquant), des sources légitimes qui ratent l'alignement (un service qui signe avec le mauvais domaine) et des pics de volume vers reject, pouvant indiquer une campagne d'usurpation active. Dans votre passerelle et votre SIEM, indexez l'en-tête Authentication-Results pour interroger dmarc=fail, dkim=fail et spf=softfail et alerter sur l'usurpation de vos dirigeants.

Détection : signaux d'en-tête et de journaux#

Au-delà des rapports DMARC, les défenseurs devraient établir une base des résultats d'authentification normaux. Dans Microsoft 365, le suivi de messages et la valeur compauth exposent les décisions d'authentification composite ; dans Google Workspace, les journaux e-mail BigQuery et l'outil d'investigation de sécurité affichent les verdicts SPF/DKIM/DMARC. Créez des détections pour le courrier entrant qui échoue DMARC mais se prétend d'un domaine interne ou partenaire, pour l'apparition soudaine d'un nouveau sélecteur dans votre propre DNS que vous n'avez pas créé, et pour le courrier sortant de votre domaine signalé en échec par des récepteurs externes : ce dernier est souvent le premier signe qu'un système shadow-IT ou un compte compromis envoie en votre nom.

Atténuation et durcissement : déployer jusqu'à l'application#

Déployez par étapes pour ne pas jeter du vrai courrier. D'abord, inventoriez chaque expéditeur légitime : votre plateforme de messagerie, outils marketing, systèmes de tickets, CRM et paie. Publiez un enregistrement SPF précis terminé par -all, en restant sous la limite de dix requêtes par aplatissement ou suppression des includes inutilisés. Activez la signature DKIM sur chaque source avec des clés 2048 bits et des sélecteurs uniques. Publiez ensuite p=none avec rua= et collectez les rapports quelques semaines jusqu'à ce que chaque flux légitime montre un alignement réussi. Passez à p=quarantine avec un pct faible et montez vers 100, puis enfin à p=reject. Réglez sp=reject pour les sous-domaines et envisagez un MX nul plus DMARC reject sur les domaines non émetteurs pour qu'ils ne puissent être détournés.

Contrôles complémentaires : MTA-STS, TLS-RPT et BIMI#

L'authentification répond à qui a envoyé ceci ; la sécurité de transport répond à a-t-il été livré en privé. MTA-STS permet à votre domaine d'exiger TLS pour le SMTP entrant et de résister aux attaques de rétrogradation, et TLS-RPT signale les échecs de livraison. BIMI permet d'afficher un logo de marque vérifié, mais seulement une fois en application DMARC, ce qui en fait une incitation utile à terminer le déploiement. Aucun ne remplace DMARC ; ils durcissent les couches autour. Traitez-les comme la seconde vague une fois votre politique d'application stable.

Pièges courants#

Les échecs les plus fréquents sont auto-infligés. Publier deux enregistrements SPF cause un permerror et invalide entièrement SPF : vous ne pouvez en avoir qu'un. Dépasser les dix requêtes DNS casse SPF en silence pour les grands écosystèmes. Passer directement à p=reject sans période de surveillance fait disparaître de manière fiable le courrier légitime d'un expéditeur oublié. Oublier la politique de sous-domaine laisse marketing.votredomaine usurpable même si le parent est verrouillé. Et traiter ~all comme équivalent à l'application est une erreur : échec léger plus p=none n'arrête rien. Enfin, ne comptez jamais sur la disponibilité des rapports forensiques ruf : beaucoup de récepteurs ne les envoient plus pour raisons de vie privée, alors bâtissez votre détection sur les données agrégées.

Liste de durcissement#

Utilisez-la comme audit rapide. 1. Exactement un enregistrement SPF par domaine, terminé par -all, sous dix requêtes. 2. DKIM activé sur chaque source d'envoi, clés 2048 bits, sélecteurs tournés et anciens retirés. 3. DMARC en p=reject avec sp=reject et rua vers une boîte ou plateforme surveillée. 4. Domaines parqués et non émetteurs verrouillés avec SPF -all et DMARC reject. 5. La passerelle d'entrée indexe Authentication-Results et alerte sur l'usurpation de dirigeants et les échecs DMARC de domaine interne. 6. MTA-STS en mode enforce et TLS-RPT publiés. 7. Surveillance des domaines ressemblant à la marque et formation des utilisateurs aux attaques de nom d'affichage et de ressemblance que l'authentification ne peut arrêter.

FAQ : DMARC en reject arrête-t-il tout le hameçonnage ?#

Non, et le croire est dangereux. DMARC en reject empêche les attaquants de falsifier votre domaine exact dans le From d'en-tête, ce qui est un gain important et précieux car il protège votre marque et vos propres utilisateurs des usurpations d'apparence interne. Il ne fait rien contre les domaines ressemblants, les astuces de nom d'affichage, les comptes légitimes compromis ou le hameçonnage depuis des domaines tiers. Associez l'application au filtrage d'entrée, à la protection des liens, au signalement par les utilisateurs et à la sensibilisation pour que les techniques restantes soient toujours détectées.

FAQ : l'application cassera-t-elle les transferts et listes de diffusion ?#

Elle le peut, d'où l'importance de DKIM. SPF casse au transfert simple car le relais est une nouvelle IP source, mais une signature DKIM valide survit généralement, donc un DKIM aligné garde le message conforme à DMARC. Les listes qui modifient l'objet ou le corps peuvent casser DKIM ; les listes bien configurées l'atténuent avec ARC (Authenticated Received Chain), qui permet à un intermédiaire de confiance d'attester l'authentification d'origine. Surveillez vos rapports agrégés pour les échecs liés au transfert pendant le déploiement afin de mettre en liste blanche les bons intermédiaires connus avant d'atteindre reject.

Conclusion#

SPF, DKIM et DMARC ne sont pas trois options concurrentes ; ce sont trois couches qui ne protègent qu'une fois combinées et poussées jusqu'à l'application. SPF autorise l'infrastructure, DKIM prouve l'intégrité, et DMARC lie les deux au From visible et vous donne les rapports qui transforment l'authentification e-mail en capacité de détection. Le manuel défensif est direct : inventoriez vos expéditeurs, publiez des enregistrements précis, surveillez les rapports agrégés jusqu'à ce que chaque flux légitime s'aligne, puis montez en reject avec couverture des sous-domaines. Faites cela, ajoutez MTA-STS et la surveillance par-dessus, et vous fermez la porte la plus facile qu'utilisent les attaquants pour usurper votre organisation.