Message suspect : ce que SPF, DKIM et DMARC permettent de conclure

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une alerte de phishing affiche des contrôles d’authentification positifs. Faut-il la clôturer ? Pas sur cette seule observation. L’analyste doit savoir quel contrôle a réussi, quelle identité il concerne et qui a produit le résultat.

Nous proposons une méthode d’investigation indépendante de la solution de messagerie : séparer les observations techniques, la qualification du message et la décision opérationnelle. Le livrable n’est pas une couleur verte supplémentaire, mais une conclusion dont un autre analyste peut vérifier les limites.

1. Identifier le résultat auquel vous pouvez vous fier

Commencez par récupérer la copie originale disponible dans le périmètre autorisé, avec ses en-têtes complets. Notez le mode de collecte, le destinataire concerné et l’heure de réception. Une capture de l’interface ou un texte recopié ne suffit pas pour examiner le parcours du message.

Le champ Authentication-Results transmet des résultats d’authentification. Sa provenance doit être établie : un nom de service familier peut être forgé, et la première ou dernière occurrence n’est pas automatiquement fiable. Source : RFC 8601, sections 5 et 7

Faites confirmer cette provenance par l’équipe messagerie et recoupez-la avec les traces de la passerelle. Sinon, consignez l’incertitude.

Conservez l’original dans l’espace d’investigation prévu. Évitez de déposer le message complet dans un analyseur public ou un assistant externe sans autorisation : en-têtes, pièces jointes et contenu peuvent exposer des informations qui n’ont aucun rapport avec le contrôle recherché.

2. Nommer l’identité évaluée par chaque mécanisme

Les trois mécanismes ne répondent pas à la même question :

SPF vérifie l’autorisation du serveur émetteur pour l’identité SMTP évaluée, MAIL FROM ou HELO. Ce n’est pas une validation de la personne affichée dans le message. Source : RFC 7208, section 2
DKIM vérifie une signature associée à un domaine sur les parties couvertes du message. Le domaine signataire peut être distinct de celui de l’auteur. Ne traduisez pas ce résultat par « toutes les parties du message sont intactes ». Source : RFC 6376
DMARC relie le domaine du champ From à une identité authentifiée alignée. Lorsqu’une politique DMARC s’applique, une réussite SPF sur MAIL FROM ou une signature DKIM valide suffit si l’alignement requis est satisfait. Source : RFC 9989, section 4.4

Dans le dossier, notez les domaines exacts plutôt qu’un résumé « expéditeur vérifié ». Gardez chaque résultat avec le mécanisme concerné. Si l’outil ne montre pas les identités ou l’alignement évalués, demandez les éléments manquants avant d’en tirer une conclusion.

3. Revenir à ce que le message demande réellement

Une authentification réussie peut accompagner un message malveillant, notamment depuis une origine compromise. Elle ne suffit pas à déclarer le contenu sûr. Source : RFC 8601, section 7.2

Exemple entièrement fictif : une demande de modification de coordonnées bancaires arrive avec une authentification positive. L’analyse doit encore établir si cette demande correspond à une opération attendue et si son auteur présumé la confirme. Le résultat technique n’autorise ni le paiement ni la clôture automatique de l’alerte.

Pour vérifier une demande suspecte, le NIST recommande d’utiliser des coordonnées déjà connues ou obtenues indépendamment, pas celles fournies dans le message. Source : NIST, Phishing

Nous recommandons de conserver séparément les observations sur le domaine, le nom affiché, l’adresse de réponse et l’action sollicitée. L’analyse des liens ou des pièces jointes suit le circuit sécurisé de l’organisation ; elle ne nécessite pas de les ouvrir depuis la session de travail de l’analyste.

4. Examiner les relais avant d’interpréter un échec

Un transfert peut perturber SPF ; une modification par un intermédiaire peut affecter DKIM. Ces difficultés sur les flux indirects sont documentées : un échec ne démontre pas, à lui seul, une intention malveillante. Source : RFC 7960, sections 2.2 et 2.3

Notre recommandation : reconstituer le parcours connu avec les équipes responsables. Identifiez un éventuel service intermédiaire et cherchez à quel stade le résultat change. Ne transformez pas une hypothèse de transfert légitime en exception générale pour un domaine ou une passerelle.

ARC permet de transporter des évaluations d’authentification entre intermédiaires. Une chaîne valide ne prouve ni la fiabilité de ses participants ni l’innocuité du message. Conservez distinctement le résultat DMARC du destinataire et une éventuelle décision locale fondée sur ARC. Source : RFC 8617, section 9

Gardez aussi le résultat d’évaluation séparé du traitement effectif : boîte de réception, quarantaine ou rejet. Dans le dossier, documentez la règle appliquée et sa justification lorsque ces éléments sont accessibles. Une livraison réussie n’est pas le verdict de l’investigation.

5. Tester les conclusions sur des messages d’exercice

Voici six situations pédagogiques à préparer avec l’équipe messagerie, uniquement dans un environnement autorisé. Les conclusions attendues reprennent les distinctions précédentes :

SPF positif mais non aligné, sans DKIM valide aligné : ne pas conclure à une réussite DMARC.
SPF négatif, DKIM valide et aligné : une réussite DMARC reste possible.
DMARC positif, demande inattendue : poursuivre la qualification du contenu et du contexte.
Résultat positif de provenance inconnue : rechercher une preuve fiable, sans conclure.
Message relayé, DMARC négatif et ARC valide : conserver les deux observations et examiner la décision locale.
Erreur temporaire d’évaluation : conserver cet état distinct, sans le convertir en réussite ou en échec définitif.

Pour chaque exercice, fixez à l’avance la preuve à retrouver et la décision attendue du N1. Faites relire le dossier par un autre analyste. L’objectif est de vérifier la méthode de qualification, pas de mesurer une performance de détection avec quelques messages.

6. Produire une conclusion que la relève peut reprendre

Notre fiche de décision tient en six points :

Objet examiné : copie de référence, destinataire, date et mode de collecte.
Provenance : service ayant évalué le message et éléments qui fondent cette confiance.
Résultats : mécanismes, identités, alignement, erreurs et relais pertinents.
Qualification : faits favorables ou défavorables, contexte métier et inconnues restantes.
Décision : action autorisée, périmètre, responsable et raison de cette action.
Vérification : résultat observable recherché et prochain contrôle si une incertitude subsiste.

Si un assistant IA prépare cette fiche, nous recommandons d’exiger une référence précise pour chaque observation et de conserver les inconnues. Une réponse fluide ne doit pas transformer une donnée absente en contrôle réussi.

Le critère de sortie est simple : un collègue peut retrouver les observations, comprendre ce qu’elles établissent et expliquer ce qu’il reste à décider. L’authentification devient alors une preuve correctement délimitée, pas un raccourci vers la clôture.