SPF, DKIM et DMARC: un flux de travail d'authentification par courriel
Inspecter SPF, DKIM et DMARC dans un ordre raisonnable sans confondre les DNS publiés avec la livraison réussie.
Inventoriez les services qui vous envoient
Commencez par une liste des systèmes que vous utilisez : un fournisseur de boîte aux lettres, une plateforme de newsletter, un service transactionnel et tout logiciel de support ou de facturation. Pour chacun, enregistrez le domaine visible From, le domaine de retour attendu et le sélecteur DKIM fourni par le fournisseur. Cet inventaire donne le contexte des résultats du DNS. Un document peut sembler plausible isolément tout en omettant un service qui envoie du courrier légitime ou en conservant un service que votre organisation n'utilise plus.
SPF décrit un chemin d'envoi autorisé
SPF évalue une IP d'envoi par rapport à la politique associée au domaine de l'expéditeur d'enveloppes, plutôt que de simplement lire l'adresse visible de From. Sa structure d'inclusion et de redirection peut dépendre d'autres réponses DNS. Utilisez le vérificateur SPF pour inspecter le dossier publié ou collé et son estimation prudente de la recherche. Un comptage statique ne peut pas reproduire complètement chaque évaluation dépendante du message. Si une demande DNS n'est pas remplie, conservez le résultat non concluant au lieu de traiter l'enregistrement non disponible comme un laissez-passer.
DKIM relie une signature à une clé publiée
Un système d'envoi signe le contenu du message avec une clé privée. Les récepteurs utilisent le sélecteur et le domaine de signature pour localiser une clé publique dans DNS, généralement sous selector._domainkey.example.com. Ce vérificateur peut inspecter la publication, les balises communes et l'encodage de base64. Il ne valide pas la structure ou la résistance du module ASN.1 d'une clé RSA. Il ne peut pas vérifier un message sans ce message est signature et le contenu signé. Enregistrez le sélecteur que votre fournisseur utilise réellement; la requête d'un sélecteur deviné peut produire une absence qui dit peu sur un autre sélecteur valide.
DMARC apporte l'expéditeur visible dans la comparaison
DMARC vérifie l'alignement entre le domaine visible From et une identité SPF ou DKIM réussie, et publie une politique de manipulation demandée. Un vérificateur de documents aide à inspecter les étiquettes et la politique; un document généré est une ébauche à examiner en fonction de votre inventaire d'envoi. Ne présumez pas que la modification de la politique corrige un service non aligné. Confirmez d'abord la configuration d'authentification de chaque service, puis utilisez les observations et les conseils du fournisseur pour décider comment traiter les messages qui échouent aux vérifications alignées.
| Vérifier | Utilisations | N'établit pas |
|---|---|---|
| Enregistrement SPF | Politique de l'enveloppe | Visible De l'alignement ou de la mise en boîte de réception |
| Dossier DKIM | Clé de sélecteur et encodage de base publiée | Structure de la clé RSA ou passe de signature de message |
| Enregistrement DMARC | Paramètres d'alignement et politique demandée | Que chaque service d'envoi est aligné |
| En-têtes / rapports | Observations déclarées par le receveur | Authenticité des preuves arbitraires collées |
Utiliser des messages réels et des rapports comme preuves distinctes
Pour une vérification pratique, envoyez un message de test ordinaire par l'intermédiaire de chaque service attendu et inspectez les en-têtes ajoutés par un système de réception fiable. Comparez le domaine visible, le chemin de retour et le domaine de signature avec votre inventaire. Les rapports agrégés du DMARC fournissent une autre vue : sources, nombre de messages et résultats d'authentification déclarés sur une période donnée. Utilisez le lecteur de rapport pour identifier une source à étudier. Un rapport peut résumer les échecs, mais il n'explique pas automatiquement s'il s'agit d'abus, de renvoi ou d'une erreur de configuration légitime.
Garder la portée et la confiance visibles
Les en-têtes collés et les rapports XML sont des données fournies à l'outil; le lecteur n'établit pas leur authenticité. Une ligne d'authentification-Résultats copiée d'une partie non fiable d'un message ne devrait pas l'emporter sur les propres résultats de confiance du fournisseur destinataire. De même, une clé DNS publique prouve la publication, non pas que votre service a signé le message que vous avez inspecté. Tenir un bref registre des preuves contenant le dossier, le message ou le rapport pertinent, le fournisseur et le moment de la vérification avant de tirer une conclusion.
Enquêter sur l'exécution avec une liste de contrôle plus large
La transmission de l'authentification n'est qu'une partie de la livraison du courrier. Gmail publie les exigences de l'expéditeur qui couvrent également l'envoi d'infrastructures, le formatage des messages et les pratiques orientées vers l'utilisateur. Commencer une enquête de livraison avec la réponse exacte du fournisseur de réception et un exemple reproductible. Passez en revue les modifications apportées à votre inventaire d'expéditeur avant de changer de nouveau le DNS. Les outils d'authentification clarifient les dossiers et les observations; ils ne peuvent pas promettre le placement de la boîte de réception, contourner les politiques d'un fournisseur ou déterminer la réputation d'une seule vérification de dossier.