Comment lire les résultats SPF, DKIM et DMARC dans un en-tête d'e-mail

Les en-têtes d’e-mails contiennent souvent des résultats SPF, DKIM et DMARC. Ces mécanismes fournissent des preuves sur les domaines et les systèmes impliqués dans la prestation. Ils n’inspectent pas tous les types de tromperies et ne prouvent pas qu’un message, un expéditeur ou un lien est sûr.

Ce guide explique le résumé des résultats produit par le Once Email analyseur d'en-tête d'e-mail. L'analyseur lit le texte collé localement dans le navigateur. Il n’effectue aucune recherche de DNS, de réputation, de malware ou de politique en direct.

SPF : ce système était-il autorisé pour un domaine enveloppe ?

Sender Policy Framework permet à un domaine de publier quels systèmes sont autorisés à envoyer en utilisant une identité SPF. Un système de réception compare l'expéditeur qui se connecte à cette politique publiée et enregistre un résultat tel que pass, fail, softfail, neutral ou none.

SPF n'est pas simplement une vérification de l'adresse qu'une personne voit dans le champ visible De. DMARC utilise le résultat SPF pour l'identité SMTP MAIL FROM, puis évalue si son domaine s'aligne sur le domaine de l'auteur visible.

Le transfert peut compliquer SPF car le serveur de transfert devient le système qui se connecte au destinataire final. Un résultat SPF échoué a donc besoin de contexte ; cela ne constitue pas en soi un verdict complet sur le message.

DKIM : une partie signée du message a-t-elle été validée ?

DomainKeys Identified Mail ajoute une signature cryptographique associée à un domaine de signature. Un récepteur récupère la clé publique du DNS et vérifie si les champs d'en-tête et le corps signés sont toujours valides.

Un laissez-passer DKIM est la preuve que le matériel signé est validé pour le domaine de signature. Cela ne garantit pas que le nom d'affichage est honnête, que chaque élément visible a été signé ou qu'un site Web lié est sûr. Les systèmes de messagerie peuvent également légitimement modifier les messages de manière à briser une signature.

DMARC : l'identité authentifiée s'aligne-t-elle sur le domaine d'auteur visible ?

DMARC s'appuie sur SPF et DKIM. Il compare un domaine SPF ou DKIM authentifié avec le domaine dans l'adresse d'expéditeur visible et applique la politique publiée et la politique du destinataire du propriétaire du domaine.

La spécification actuelle de l'IETF, RFC 9989, explique que DMARC authentifie les identifiants au niveau du domaine et ne traite pas les attaques par nom d'affichage ni n'analyse le contenu des messages. Il a remplacé l'ancien RFC 7489 en mai 2026.

Ce qui a changé dans la révision DMARC 2026

La RFC 9989 ne prouve pas que chaque système de messagerie a soudainement changé de comportement en 2026. Elle consolide la définition actuelle du protocole, rend explicitement obsolètes les RFC 7489 et RFC 9091 et sépare les formats d'agrégation et de rapport d'échec dans des spécifications complémentaires. La règle pratique de lecture reste stable : un pass DMARC signifie une identité SPF ou DKIM alignée autorisée à utiliser le domaine auteur visible. Il ne s’agit pas d’un score de réputation, d’un contrôle d’identité de la personne qui a rédigé le message ou d’une analyse des liens et des pièces jointes.

Cette distinction est importante lors de l'interprétation des « nouvelles exigences DMARC » dans les annonces de produits. Un fournisseur peut modifier sa politique de livraison ou ses exigences en matière d'expéditeur en masse indépendamment du protocole de base. Par exemple, les consignes de l'expéditeur de Gmail (https://support.google.com/mail/answer/81126?hl=en) appliquent différentes exigences d'authentification en fonction du volume d'envoi. Traitez la politique du fournisseur, la validation du protocole et la sécurité des messages comme trois couches distinctes.

Une réussite DMARC signifie qu'au moins un chemin d'authentification pris en charge a été transmis avec l'alignement requis. Cela ne signifie pas que l'auteur est personnellement vérifié, que le compte n'a pas été compromis ou que le message est inoffensif.

Lecture des résultats de l'authentification

Un en-tête simplifié pourrait ressembler à ceci :

Authentication-Results: mx.example;
  spf=pass smtp.mailfrom=mailer.example;
  dkim=pass header.d=mailer.example;
  dmarc=pass header.from=mailer.example

Examinez ces valeurs ensemble :

1. Quel serveur a écrit le champ Authentication-Results ?
2. Quel domaine a réussi le SPF ?
3. Quel domaine a signé avec DKIM ?
4. Quel domaine apparaît dans l'adresse De visible ?
5. DMARC signale-t-il un alignement, un échec ou une absence de politique ?
6. L’itinéraire de livraison est-il pertinent pour l’expéditeur que vous attendiez ?

Les en-têtes peuvent contenir plusieurs champs de résultat car plusieurs systèmes ont traité le message. Le résultat du destinataire de confiance le plus récent est souvent le plus pertinent, mais pour décider quel intermédiaire est fiable, il faut connaître le fournisseur de boîte aux lettres et le chemin de livraison.

Pourquoi un pass n'est pas une garantie de sécurité

Un attaquant peut authentifier un domaine qu'il contrôle. Le compte d'un expéditeur légitime peut être compromis. Un message correctement authentifié peut toujours contenir une demande trompeuse, une pièce jointe malveillante ou un lien dangereux.

Les Directives de l'expéditeur Gmail exigent différents contrôles d'authentification en fonction du volume d'envoi et décrivent l'authentification comme une mesure de délivrabilité et anti-abus. Ils ne transforment pas l’authentification en un verdict général sur la sécurité du contenu.

Si un message demande des informations d'identification, de l'argent, une action urgente ou des fichiers sensibles, vérifiez la demande via un canal de contact connu. Ne vous fiez pas uniquement au nom De ou à un résultat d’authentification vert.

Utilisez l'analyseur avec prudence

Collez uniquement les champs d'en-tête, pas le corps du message ni les pièces jointes. Comparez le résumé de l'analyseur avec le contexte dans lequel le message est arrivé. Considérez les preuves manquantes, mal formées ou contradictoires comme un motif de vérification supplémentaire et non comme une preuve automatique de fraude.

Pour une réponse à un incident, une configuration de domaine ou des décisions à fort impact, utilisez l'affichage des messages d'origine de votre fournisseur de boîte aux lettres et consultez un administrateur de messagerie qualifié ou un professionnel de la sécurité.