Un fournisseur peut honnêtement signaler que son courrier passe DKIM en signant avec un domaine sans rapport avec votre adresse De visible. Si l'objectif est d'authentifier le domaine d'auteur de votre organisation pour DMARC, demandez une identité DKIM alignée et prise en charge et définissez comment elle sera vérifiée. Une demande générique pour activer DKIM est trop ambiguë.
Commencez par un message contrôlé du service et de l'itinéraire réels. Conservez sa forme brute reçue et le résultat du récepteur de confiance. Cela donne au fournisseur une inadéquation d'identité concrète à enquêter sans supposer que le produit propose une signature de domaine personnalisée sur chaque plan ou transport.
Indiquer les identités séparément
Enregistrez le domaine visible From, expéditeur d'enveloppe identité, SPF résultat, chaque domaine DKIM d, sélecteur et le résultat de la vérification. Mettre alignement dans un champ séparé. RFC 9989 §4.4 traite le succès de l'authentification et l'alignement des identifiants comme des exigences différentes ; un domaine DKIM de passage sans rapport n'est pas aligné car il appartient au fournisseur d'envoi.
L'alignement DKIM strict nécessite une correspondance de domaine exacte sous RFC 9989 §3.2.10. L'alignement détendu compare les domaines organisationnels sous RFC 9989 §4.10.2. Demandez quel domaine le fournisseur peut réellement émettre, puis comparez-le avec votre domaine et votre politique From prévus. Ne demandez pas de valeur DNS particulière avant que le fournisseur n’ait confirmé l’identité et la configuration du compte prises en charge.
Montrez clairement la passe trompeuse
Feuille de travail d’identité illustrative :
- Identité du fournisseur uniquement : From= brand.example ; d=provider.example; assumé le laissez-passer DKIM ; pas alignés, en supposant qu’il s’agit de domaines organisationnels non liés.
- Identité du client : From= brand.example ; d=brand.example; assumé le laissez-passer DKIM ; correspondance de domaine exacte.
Supposons les résultats présentés pour les besoins de cet exemple. Il ne s’agit pas d’une preuve de test de message reçu. Dans le premier cas, DMARC peut toujours passer par SPF aligné, donc ne prétendez pas à un échec global DMARC sans vérifier l'identité de l'enveloppe et le résultat SPF . La feuille de calcul isole la propriété DKIM demandée.
Envoyer une demande technique précise
Demandez au fournisseur si le produit nommé, le plan de compte et l'itinéraire d'envoi prennent en charge un domaine de signature contrôlé par le client et aligné sur l'adresse d'expédition prévue. Incluez les détails de l'API, SMTP , de la campagne ou de l'itinéraire transactionnel, le cas échéant. Demandez si le comportement diffère pour les alias, les sous-domaines et les utilisateurs délégués.
Demandez les noms exacts des sélecteurs, les types et valeurs d’enregistrement DNS , l’étape d’activation et la procédure de vérification. Demandez qui contrôle les clés privées, comment la rotation est effectuée et ce qui arrive aux enregistrements de vérification après le départ. Si un CNAME est requis, confirmez sa cible et sa portée plutôt que de le remplacer par un Enregistrement TXT.
Partagez une feuille de travail d'identité expurgée ou un message de test contrôlé au lieu d'un message client contenant un contenu personnel inutile. Une demande d'assistance d'un fournisseur ne nécessite pas de clé de signature privée ni de mot de passe de boîte aux lettres. Conservez les informations d’identification sensibles hors des tickets ordinaires.
Acceptez les critères d’acceptation avant de changer DNS
Un test d'acceptation utile nécessite un nouveau message provenant de l'itinéraire réel équivalent à la production, une réussite destinée Signature DKIM auprès d’un destinataire de confiance et alignement selon la politique pertinente. Testez séparément les formats et itinéraires de messages importants. Le simple fait de publier des enregistrements DNS ou de voir un badge vérifié constitue une preuve incomplète.
Si le fournisseur ajoute également sa propre signature, inspectez les deux. Plusieurs signatures sont autorisées sous RFC 6376 §4.2, et une signature alignée passante fournit le chemin DKIM sous RFC 9989 §4.4.1. Enregistrez le sélecteur et le domaine d réellement observés plutôt que de vous fier à la première signature affichée par un outil d'en-tête.
Gérer honnêtement les fonctionnalités non prises en charge
Si DKIM aligné personnalisé n’est pas disponible, demandez les alternatives prises en charge et leurs contraintes. Un chemin SPF aligné de passage peut satisfaire DMARC pour un itinéraire direct applicable, mais il ne crée pas DKIM aligné ni ne garantit la résilience via le transfert ; RFC 7208 §10.3 discute des limitations du médiateur SPF . Une identité ou un service d'envoi pris en charge différent peut être nécessaire pour répondre aux besoins de l'organisation.
Clôturez la demande avec l'identité convenue, l'itinéraire, la propriété DNS , le dépositaire de la clé et la preuve du message reçu. Si une fonctionnalité n’est toujours pas prise en charge, enregistrez-la explicitement. Le résultat devrait être une conception d'envoi vérifiable plutôt qu'une promesse que tout pass DKIM prouve l'identité de votre marque.
Enregistrez la prochaine décision
Préparez ces champs avant de contacter le support : produit et itinéraire ; prévu De ; d/s observé et résultat fiable ; mode d'alignement requis ; question de capacité ; instructions DNS générées demandées ; gardien des clés ; questions sur la rotation et la sortie ; et les critères d'acceptation. Supprimez les données personnelles inutiles. Il s'agit d'une liste de contrôle de demande technique, et non d'un ticket envoyé, d'une modification DNS approuvée ou d'une preuve de service configuré.