DKIM permet à un domaine de prendre la responsabilité d'un message via une signature cryptographique. Pour comprendre ce que cela signifie pour un e-mail spécifique, commencez par l'original reçu plutôt que par un vérificateur DNS . La chaîne de preuves utile est la signature du message, le domaine de signature et sélecteur, clé publique, résultat de la vérification du récepteur, puis tout DMARC alignement décision.
Lire l'identité qui a été signée
Localisez chacun DKIM-Signature en-tête dans le message d'origine. La valeur d= identifie le domaine signataire et s= identifie son sélecteur. Pour la récupération de clés basée sur DNS, combinez-les en tant que sélecteur. _domainkey.signing-domain. Le domaine signataire peut appartenir à l'organisme de l'auteur, à un relais ou à un service agissant pour son compte. DKIM sépare délibérément la responsabilité de signature de l'auteur apparent. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
Exemple illustratif : From est accounts@example.com et une signature contient d=example.com; s=mail2026. Le vérificateur recherche mail2026._domainkey.example.com . Cet enregistrement DNS fournit du matériel de vérification public. La clé de signature privée reste la propriété du signataire autorisé et ne doit pas être publiée. Cet exemple explique la recherche ; ce n'est pas une vraie signature ou un message testé.
Séparer la présence de la vérification réussie
Un en-tête DKIM-Signature peut être présent et non valide. Une clé DNS peut exister alors que l'application n'envoie aucune signature. La vérification vérifie la structure de la signature, la clé, les en-têtes sélectionnés et la représentation du corps. Les modifications apportées après la signature peuvent le rompre, en fonction de ce qui a changé et du canonisation utilisé. Une chaîne ressemblant à un résumé ne constitue pas une preuve que ces vérifications ont réussi. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
Inspectez le système de confiance du système de réception Authentication-Results ou des journaux équivalents. Découvrez quel service d'authentification a ajouté ce résultat et où les en-têtes de résultats entrants non fiables sont supprimés ou ignorés. Un expéditeur peut insérer un texte de passe d'apparence plausible dans un message, de sorte que le contenu arbitraire Authentication-Results ne constitue pas une preuve. RFC 8601 §1.2, RFC 8601 §7.1.
Connectez le résultat à l'auteur visible
Pour DMARC , comparez un domaine d= vérifié avec succès avec le domaine d'auteur de From. L'alignement DKIM strict nécessite une correspondance exacte sous RFC 9989 §3.2.10; l'alignement détendu utilise la découverte du domaine organisationnel dans RFC 9989 §4.10.2. Le sélecteur et la valeur facultative i= ne sont pas les domaines utilisés pour cette comparaison DMARC . Si plusieurs signatures DKIM sont présentes, une signature alignée peut fournir le chemin DKIM vers la transmission DMARC . RFC 9989 §4.4.1.
Dans l'exemple, d=example.com correspond au domaine From. Si à la place d=service.example.net vérifie, DKIM brut passe mais ce domaine sans rapport n'établit pas d'alignement avec example.com . Ne « corrigez » pas ce problème en modifiant un en-tête reçu : configurez le signataire légitime pour qu'il utilise une identité prise en charge appropriée.
Construire un dossier d’enquête utile
Enregistrez l'heure du message, l'itinéraire, depuis le domaine, chaque paire d/s, le résultat et la raison DKIM fiables, le temps d'observation DNS et le résultat de l'alignement. Protégez le message d'origine car il peut contenir des informations personnelles ou confidentielles. La suppression d'une copie peut invalider sa signature ; conserver un original à accès contrôlé lorsqu’une nouvelle vérification est nécessaire.
Si la vérification échoue, vérifiez si la signature a été activée, si la clé correcte est disponible, si l'algorithme est pris en charge et si le message a été modifié en cours de transit. Les directives cryptographiques actuelles remplacent les valeurs par défaut obsolètes : RFC 8301 §3.1 interdit rsa-sha1 pour la signature et la vérification ; RFC 8301 §3.2 met à jour les directives clés de RSA. N'utilisez pas les choix cryptographiques d'un ancien didacticiel simplement parce que sa syntaxe semble toujours valide. Terminez avec la preuve du résultat reçu, pas seulement la preuve que DNS contient une clé.
Appliquer la distinction
Pour un message hypothétique, écrivez une ligne pour chaque signature : d, s, propriétaire de la recherche, résultat de vérification fiable et alignement. Si la signature example.com échoue alors qu'une signature service.example.net non liée passe, ne combinez pas le premier domaine avec le deuxième résultat. Examinez la signature échouée et évaluez-la SPF séparément avant d'attribuer DMARC . Aucune vérification de message n'a été exécutée pour cet article.