SPF, DKIM et DMARC apporter différentes preuves sur un e-mail. SPF évalue une source de connexion par rapport à la politique d'envoi d'un domaine évalué. DKIM vérifie une signature associée au domaine sur le matériel de message couvert. DMARC associe une identité authentifiée transmise au domaine dans From et applique son cadre politique.
Ils travaillent ensemble car aucun résultat vert ne répond à toutes les questions d’identité. Une implémentation utile suit le message via le service d'envoi, les dépendances DNS et le système de réception, en préservant ce que chaque vérification a réellement établi.
Donnez à chaque chèque sa propre question
- Mécanisme : SPF ; Réponse à la question : cette source de connexion satisfait-elle à la politique d'envoi de l'identité évaluée ? ; Limite importante : cette identité n'a pas besoin d'être visible depuis le domaine
- Mécanisme : DKIM ; Réponse à la question : Cette signature associée au domaine est-elle vérifiée par rapport au contenu du message couvert ? ; Limite importante : la vérification n'établit pas que chaque partie du message ou de la demande est sûre
- Mécanisme : DMARC ; Réponse à la question : une identité de passage éligible correspond-elle à From et quelle politique d'évaluation s'applique ? ; Limite importante : le traitement des récepteurs inclut des preuves au-delà DMARC
Les contrôles sont liés, mais il ne s’agit pas de trois exemplaires du même test. Un système peut publier les trois types d'enregistrement DNS alors qu'une application envoie toujours sans la signature prévue ou alignement de domaine.
Suivez SPF depuis la connexion d'envoi
Pour le COURRIER DE contrôle d'un message ordinaire avec une adresse de retour sous enveloppe non vide, RFC 7208 §2.4 spécifie que SPF évalue la source d'envoi à l'aide de l'identité MAIL FROM. Le destinataire consulte la politique publiée de ce domaine, qui peut faire référence à d'autres données de politique.
C'est pourquoi l'identité est importante avant toute modification DNS . Ajout d'un service à example.com Enregistrement SPF ne peut pas réparer une évaluation SPF qui utilise réellement un domaine contrôlé par le service ailleurs. Établissez d’abord ce que le message et l’itinéraire utilisent.
Sous RFC 7208 §2.3 et RFC 7208 §2.4, SPF peut également évaluer HELO, et sa spécification définit la gestion d'un chemin inverse nul. Ces cas ne justifient pas la substitution d'un domaine arbitraire dans les champs d'affichage du message. Conserver l'identité évaluée avec le résultat.
Un pass SPF ne crée pas de signature sur le contenu du message. Ses preuves portent sur la source évaluée et l'identité à ce point de réception.
Suivez DKIM de la signature à la vérification
Un système d'envoi applique un Signature DKIM en utilisant une clé privée. Sous RFC 6376 §3.6.2.1, la vérification utilise du matériel public trouvé via le domaine de signature de cette signature et sélecteur. La clé privée appartient au système de signature autorisé, pas DNS public.
La signature et la publication doivent fonctionner. Une clé publique au bon nom ne prouve pas que l'application a signé ses messages avec elle. A l’inverse, une signature actuelle n’établit pas que sa clé peut être récupérée ou que la vérification réussit après la livraison.
Sous RFC 6376 §3.7, DKIM protège le matériel couvert par son calcul de signature défini. Une passerelle qui modifie le contenu pertinent après la signature peut affecter la vérification. Le guide d'enquête sur le hachage corporel explique comment retracer une panne particulière sans deviner que chaque erreur DKIM nécessite une nouvelle clé.
Utilisez DMARC pour connecter des preuves à De
DMARC évalue le domaine dans l'adresse De, à l'aide de la stratégie et des relations d'alignement applicables. Sous RFC 9989 §5.3.5, une réussite au niveau du message avec une stratégie applicable et des vérifications terminées peut provenir soit d'une identité SPF alignée réussie, soit d'une signature DKIM alignée réussie.
Cette condition de réussite ne constitue pas une recommandation de configurer un seul mécanisme. RFC 9989 §8 les exigences de participation à part entière comprennent l'alignement SPF et DKIM , le reporting et la publication des politiques. Sous RFC 9989 §7.4, publication de domaines p=reject ne doit pas s'appuyer uniquement sur SPF et doit appliquer des signatures DKIM valides.
Les fournisseurs de boîtes aux lettres peuvent également imposer leurs propres exigences en matière d'expéditeur. Consignes de Google relatives aux expéditeurs groupés, par exemple, appelez SPF , DKIM et DMARC . Séparez le résultat au niveau du message d’un protocole de la conformité à l’ensemble de la politique d’envoi d’un fournisseur.
Comprendre pourquoi les chemins peuvent survivre différemment
Ce qui suit est un exemple synthétique et non un test de compte. Un service de notification produit un résultat SPF aligné avec succès et une signature DKIM alignée avec succès pour son itinéraire direct.
Considérons maintenant deux changements à cet itinéraire :
- Un service de transfert modifie la source de connexion vue par le récepteur final. Le résultat SPF antérieur ne constitue pas une garantie de l’évaluation ultérieure. Si le contenu signé pertinent est préservé, la signature DKIM alignée d'origine peut toujours être vérifiée.
- Une passerelle modifie le contenu signé après l'étape de signature. DKIM peut échouer au prochain récepteur, tandis que SPF dépend de la route de connexion finale et de l'identité évaluée.
Aucun des deux résultats n’est inévitable pour chaque intermédiaire. Inspectez l’itinéraire réel, les identités et les résultats de la vérification. Cette différence explique pourquoi les deux mécanismes offrent des chemins distincts utiles sans pour autant les rendre universellement fiables à travers toutes les transmissions ou modifications.
Conserver les preuves de configuration séparées des preuves de message
Un petit enregistrement de niveau de service est plus utile qu'un statut inexpliqué à l'échelle du domaine. Cette matrice d'acceptation fictive illustre la distinction :
- Observation du service : le courrier des employés possède une clé DKIM publique ; Preuves encore nécessaires : Preuve que le domaine sélectionné signe et vérifie via son itinéraire réel
- Observation du service : le courrier de facturation passe SPF pour un domaine de fournisseur ; Preuves encore nécessaires : sa relation avec From et tout chemin DKIM aligné
- Observation du service : Le courrier marketing a une politique DMARC valide ; Preuves encore nécessaires : preuves réelles de signature, d'authentification et de contexte politique
- Observation du service : un message reçu passe les contrôles appropriés ; Preuves encore nécessaires : son propriétaire commercial et son utilisation approuvée, évalués séparément
Pour chaque service, conservez la configuration prise en charge, les identités importantes et un message reçu original représentatif. Sous RFC 8601 §7.1, utiliser les résultats du système de réception fiable ; une assertion de passe insérée par un expéditeur non fiable ne peut pas remplacer le travail du destinataire.
Le inventaire des expéditeurs connecte ces enregistrements aux propriétaires. Le Flux de travail d'enregistrement DMARC joint la publication à la vérification des messages et des rapports.
Préserver les limites du résultat combiné
Comme portée de signature dans RFC 6376 §3.7 et la manipulation du récepteur dans RFC 9989 §5.4 Comme le montre l'exemple, ces contrôles ne cryptent pas le message pour le destinataire, n'établissent pas la véracité de son contenu et ne garantissent pas le placement dans la boîte de réception. La sécurité du transport et la protection du contenu sensible des messages sont des préoccupations distinctes.
Un service autorisé compromis peut toujours envoyer du courrier authentifié. De même, un résultat technique valide n’établit pas que l’organisation a approuvé ce compte d’application particulier ou cette demande commerciale.
Le résultat combiné utile est donc précis : le récepteur a évalué les identités réelles de la source et de la signature, a trouvé le chemin de passage aligné requis pour From et a pris en compte la politique appropriée. Conservez cette preuve avec le service et l'itinéraire qui l'ont produite. Trois enregistrements configurés constituent une dépendance de départ ; une communication vérifiée et maintenue est le résultat de l’exploitation.
Conserver une conclusion limitée
Dans la matrice d'acceptation fictive, une clé publique ne fait que clôturer la preuve de publication. Un pass SPF fournisseur-domaine doit toujours vérifier sa relation avec From. Pour tout pass DMARC revendiqué, conservez la politique applicable et le chemin de passage spécifique aligné, puis séparez l'approbation du compte et la sécurité du contenu. Aucune configuration de service ou test de message n'a été effectué ici.