Restreindre les instructions à la signature de SpamTitan Gateway
TitanHQ publie un Configuring spécifique DKIM dans la procédure SpamTitan Gateway. Cet article suit cette limite de produit. Cela ne suppose pas que SpamTitan Cloud, Skellig, un déploiement entrant uniquement ou chaque édition de service géré expose les mêmes contrôles. Confirmez la version installée, les fonctionnalités sous licence et l'itinéraire sortant réel avant d'approuver une modification de signature. Un domaine répertorié pour la réception de courrier ne constitue pas, en soi, une preuve que les messages sortants traversent la passerelle ou reçoivent une signature de domaine client.
Le Procédure de passerelle contient à la fois les étapes de signature DKIM et une discussion distincte sur les enregistrements de stratégie DomainKeys hérités. Ce mélange constitue une limite de mise en œuvre importante. Le flux de travail moderne de clé de signature peut être expliqué à partir de la source, mais l'étape de politique héritée nécessite une confirmation du produit actuel. Ne convertissez pas silencieusement l'ancienne terminologie DomainKeys en un DMARC exigence ou affirmation selon laquelle la publication d'une politique o= établit une protection de domaine moderne.
Identifiez le relais de domaine et la propriété de la clé
La navigation documentée est Configuration du système, Relais de messagerie, DKIM . La page répertorie les relais de domaine. Modifiez le domaine souhaité et ouvrez l'onglet CLÉ DE DOMAINE. La procédure demande un sélecteur nom qui distingue cette clé des autres clés de domaine. Choisissez une étiquette via le processus de dénomination approuvé par l'organisation et vérifiez l'utilisation existante avant de la publier. Une étiquette prévisible n'est pas un secret, mais la réutilisation d'un sélecteur occupé peut écraser une dépendance dont un autre expéditeur a encore besoin.
La source décrit la génération d'une nouvelle paire de clés et propose également un champ de clé privée existante. Ce guide ne demande, ne collecte ni ne recommande de copier une clé privée dans un ticket ou un document partagé. La génération ou l’importation de clés est une action administrative autorisée distincte. Le guide répertorie 1024 bits et 2048 bits options et recommande le choix le plus long. Confirmer la configuration prise en charge et les exigences cryptographiques actuelles pour le produit déployé ; ne rétrogradez pas simplement parce qu'un éditeur DNS affiche une longue valeur publique de manière gênante.
Publier la clé publique générée sans copier l'exemple
Après Générer, la source dirige l'administrateur vers l'onglet OPTIONS et le matériel DNS TXT . Publiez la clé publique réelle sous le nom formé à partir du sélecteur sélectionné, _domainkey et du domaine de signature. La grande clé publique imprimée dans la documentation est une illustration et non un enregistrement réutilisable. Enregistrez le propriétaire choisi et une référence contrôlée à la valeur publique émise dans la demande de modification. Aucun matériel privé n'appartient au DNS public.
TitanHQ discute de la suppression du formatage superflu de l'affichage copié. Interprétez cela comme la gestion de la présentation de l'éditeur, et non comme une édition arbitraire des octets clés. RFC 6376 , section 3.6.2.2 spécifie les enregistrements de ressources TXT pour le stockage des clés. Un outil DNS peut afficher plusieurs chaînes entre guillemets dans un seul Enregistrement TXT; qui est différent de plusieurs enregistrements concurrents ou de guillemets littéraux insérés dans la valeur. Demandez à l'administrateur DNS de vérifier l'enregistrement logique réel et le nom complet du propriétaire plutôt que d'accepter une capture d'écran d'une zone de saisie comme preuve finale.
Gardez la politique héritée et le mode de test séparés de DMARC
La procédure du fournisseur décrit également un enregistrement TXT dans _domainkey suivi du domaine, avec les valeurs o=- ou o=~ , sous Policy Records. Il appelle explicitement cette stratégie DomainKeys. Il ne s’agit pas de l’emplacement de la stratégie DMARC et ne remplace pas une clé publique de sélecteur DKIM . Étant donné que la procédure combine ces éléments historiques, vérifiez si cette étape de stratégie est applicable à la version actuelle exacte de Gateway avant de l'ajouter. Préservez la question non résolue dans le dossier de sortie plutôt que d’inventer une exigence moderne.
Le guide décrit séparément un indicateur de test DKIM , t=y, dans l'enregistrement de clé. Ne confondez pas cela avec une instruction pour placer un déploiement DMARC en mode test ou avec une preuve que les destinataires accepteront tous les courriers. DKIM , DMARC et la gestion des récepteurs locaux ont une sémantique distincte. RFC 9989 , section 4.4 explique le alignement requis entre une identité d'authentification de passage et le domaine de l'auteur. Une déclaration de politique existante selon laquelle le courrier est signé n'établit pas qu'une signature particulière valide ou s'aligne.
Vérifiez avant d’activer et planifiez délibérément la rotation
Le flux de travail OPTIONS de TitanHQ utilise Verify pour récupérer l'enregistrement DNS TXT et le comparer avec les informations configurées de la passerelle. Une fois la vérification réussie, Enable active la signature DKIM pour le domaine. Considérez-les comme des points de contrôle distincts. Une clé publiée ne prouve pas que la signature est activée, tandis qu'une option de signature sélectionnée ne peut pas valider un enregistrement public manquant ou incompatible. Conservez le résultat de la vérification et son heure sans le décrire comme un test d'acceptation du récepteur.
La documentation recommande une rotation périodique des clés. Un plan de rotation pratique nécessite plus qu'un intervalle de calendrier : identifiez les sélecteurs actifs, les clés générées, les messages en file d'attente, la mise en cache DNS , les opérateurs autorisés et les conditions de restauration. Ne supprimez pas l'enregistrement public précédent simplement parce qu'une clé de remplacement a été générée. Déterminez ce qui chevauche les besoins réels du chemin de messagerie et conservez les preuves à l’appui de cette décision. Ce manuscrit n'a pas mesuré la durée de vie des files d'attente ni testé le comportement de transition du produit installé, ces détails d'implémentation restent donc ouverts.
Vérifiez le message sortant final plutôt que l'étiquette de filtrage
Un exercice d'acceptation autorisé séparément devrait distinguer le transit de la passerelle, la signature, la validation et l'alignement. Examinez les champs d= et s= de la signature, le domaine d'auteur visible et les résultats d'authentification du récepteur de confiance. RFC 6376 , section 3.5 définit les champs de signature. Vérifiez les classes de messages qui peuvent emprunter différents chemins, tels que le courrier de boîte aux lettres ordinaire, les notifications d'application et le trafic transféré. Le fait qu'un message entrant ait été analysé par SpamTitan ne dit rien de concluant sur la façon dont un message d'application sortant a été signé.
SPF est un examen distinct. RFC 7208 , sections 2.4 et 4.6.4 décrire son COURRIER DE limites d’évaluation dépendant de l’identité et du DNS. Cette source ne fournit pas d'inclusion SPF sortante universelle pour chaque déploiement de SpamTitan, donc aucune n'est inventée ici. Obtenez l’infrastructure d’envoi autorisée réelle et examinez une politique complète pour cette identité. Le succès de l'authentification reste distinct du placement dans la boîte de réception, de la sécurité du contenu ou de l'approbation du destinataire d'une demande de paiement.
Diagnostic fictif et feuille de travail d'acceptation vierge
Une société d'ingénierie fictive, Alder Instruments, publie une nouvelle clé de sélection mais laisse la signature désactivée en attendant une fenêtre de maintenance. Sa liste de contrôle interne marque DKIM comme terminé car la vérification a réussi. Un examen ultérieur révèle que la liste de contrôle confondait l'accord DNS avec la signature active. La correction proposée consiste à séparer l'approbation d'activation, l'état de configuration observé et la preuve du futur récepteur. Il ne s'agit pas de publier l'exemple de clé de la documentation ni d'ajouter un enregistrement de stratégie hérité à la place. Aucune recherche réelle de système, de message ou DNS ne sous-tend ce scénario.
- Produit de passerelle, version, route sortante et relais de domaine : ______
- Propriété du sélecteur et dépendances existantes : ______
- Référence de propriétaire/valeur publique générée et modification DNS approuvée : ______
- Décision de garde de clé privée, sans éléments secrets : ______
- Décision d’applicabilité de la stratégie DomainKeys héritée : ______
- Vérifier le résultat et activer l'approbation/état ultérieur : ______
- Chevauchement de rotation, restauration et conservation du sélecteur précédent : ______
- Signature fiable du message reçu et preuve d'alignement : ______
- Exceptions restantes, réviseur et propriétaire de la version : ______
Les preuves originales de mise en œuvre, l'applicabilité actuelle de la source, l'examen du sujet humain, l'acceptation de la voie de production, l'accessibilité visuelle et la libération du propriétaire restent ouverts. Aucune clé n'a été générée, aucun paramètre modifié, aucun enregistrement DNS publié ou aucun message envoyé. Les exigences plus larges de mise en œuvre du catalogue ne peuvent pas être considérées comme complètes à partir de ce seul flux de travail documentaire.