Identifiez le domaine et le compte Critical Impact
Critical Impact documente l'authentification de l'expéditeur comme un flux de travail de compte qui produit des instructions DNS spécifiques au domaine, compare les valeurs publiées avec ces instructions, puis démarre l'authentification. Ce guide couvre cet outil d'authentification de l'expéditeur documenté. Il n'établit pas qu'un abonnement particulier expose l'outil, qu'un domaine est déjà autorisé ou qu'un message a passé avec succès les contrôles du destinataire. Ceux-ci nécessitent des preuves de compte et de message. La navigation documentée est Compte, puis Authentification de l'expéditeur ; si l'outil est manquant, le prestataire oriente le client vers son chargé de compte. La disponibilité est donc un prérequis, et non un contrôle que cet article peut assumer. Guide de configuration de l'impact critique
Commencez par le domaine ou le sous-domaine réel destiné à l'envoi. Identifiez son propriétaire d'entreprise, le compte qui l'utilise, l'opérateur DNS faisant autorité et tout autre système envoyant déjà sous la même identité. Le domaine d'un site Web et le domaine visible d'une campagne peuvent différer. Enregistrer l'identité souhaitée avant d'obtenir les instructions DNS permet d'éviter de configurer un domaine parent inutilisé tout en laissant le sous-domaine de la campagne intact. Il s'agit d'une étape de préparation proposée, et non d'une réclamation concernant une fonctionnalité d'inventaire automatisée.
Obtenez les instructions uniques sans les traiter comme des valeurs par défaut réutilisables
La séquence documentée est Ajouter un domaine, entrez le domaine ou le sous-domaine et enregistrez. Sélectionnez ce domaine dans la grille et choisissez Authentifier le domaine pour obtenir ses instructions. L'impact critique décrit un événement unique DKIM Enregistrement TXT pour chaque domaine et un mécanisme ip4 à ajouter à l'existant SPF politique. Ne remplacez pas ces valeurs générées par le compte par un enregistrement copié à partir d'un autre client, d'un autre domaine ou d'une ancienne capture d'écran. Ne remplacez pas l'instruction ip4 documentée par un mécanisme d'inclusion deviné. Explication de l'authentification de l'expéditeur
Conservez les noms de propriétaires générés, les types d'enregistrement et les valeurs complètes ainsi que le compte et le domaine qui les ont produits. Un réviseur doit être capable de distinguer un nouveau dossier demandé d'une modification apportée à un dossier existant. Les éditeurs DNS diffèrent dans leur traitement des noms relatifs et des suffixes de domaine, de sorte que le nom complet prévu doit rester explicite dans la demande de modification. Non sélecteur, l'adresse ou la clé publique dans cet article est une valeur d'implémentation.
L'action Instructions par courrier électronique de l'outil envoie des instructions à l'adresse e-mail de l'utilisateur connecté. Il s'agit d'une action de communication et non d'une simple prévisualisation à l'écran. Décidez si ce destinataire et cette boîte aux lettres sont appropriés avant de les utiliser. Ce guide n'a pas envoyé ces instructions ni contacté un responsable de compte. Le flux de travail du fournisseur est décrit afin qu'un opérateur agréé puisse le planifier. Guide de configuration de l'impact critique
Préserver les expéditeurs existants lors de la préparation des modifications DNS
Critical Impact dit de ne pas supprimer un fichier existant Enregistrement SPF pour ajouter son autorisation. Au lieu de cela, mettez à jour la stratégie existante avec le mécanisme émis. SPF autorise une seule stratégie SPF sélectionnée pour un nom de propriétaire donné ; publier une deuxième politique concurrente n’est pas un moyen sûr de préserver la première. Préservez l'autorisation pour les expéditeurs encore approuvés, vérifiez la syntaxe et l'ordre, et évaluez le chemin de dépendance évalué complet où les mécanismes de recherche DNS sont présents. Un terme ip4 n'est pas une inclusion et n'effectue pas lui-même une recherche DNS , mais d'autres termes dans la politique résultante peuvent toujours entraîner le dépassement des limites d'évaluation. Explication de l'authentification à impact critique RFC 7208
Pour DKIM , utilisez le propriétaire TXT unique et la clé fournis pour ce domaine. Enregistrez si le panneau DNS affiche des citations de présentation ou divise une longue valeur TXT en chaînes de caractères, puis validez l'enregistrement résultant plutôt que d'interpréter une capture d'écran comme une preuve au niveau du fil. La clé publique publiée d'un sélecteur permet de vérifier les signatures correspondantes ; la publication d'une clé ne prouve pas que le service expéditeur a commencé à signer des messages avec elle. Le domaine et le sélecteur de la signature réelle doivent ensuite être vérifiés par rapport à la configuration prévue. RFC 6376
Comparaison séparée, preuve d'activation et preuve de message reçu
La fenêtre contextuelle d'authentification distingue les valeurs DNS existantes des valeurs DNS recommandées. Le guide de configuration de Critical Impact demande à l'opérateur de les comparer et de procéder à l'authentification lorsque les valeurs sont vertes. Une incompatibilité rouge nécessite une enquête : un mauvais propriétaire, une valeur copiée, un enregistrement manquant, une réponse obsolète du résolveur ou une modification incomplète sont différents problèmes. L'explication décrit également les tolérances temporelles et un chemin d'avertissement lorsque les valeurs ne correspondent pas encore. La procédure d'acceptation proposée n'utilise pas cette voie d'avertissement pour déroger à l'exigence de comparaison. Guide de configuration de l'impact critique
Après l'initiation, la documentation décrit un email de notification et un état Authentifié dans la grille du domaine. Ses estimations temporelles sont des informations de planification et non une preuve qu'un enregistrement spécifique deviendra correct à une date limite. Enregistrez l'état et le temps observés au lieu de convertir le temps écoulé en succès. Si les paramètres DNS changent ultérieurement, le fournisseur redirige les utilisateurs vers authentifier le domaine et revérifie les valeurs. Conservez cette dépendance de revalidation dans le runbook opérationnel. Explication de l'authentification de l'expéditeur
L'étiquette Authentifié d'un compte constitue un point de contrôle. Une évaluation ultérieure du message autorisé doit identifier séparément le domaine From visible, l'identité et le résultat SPF , le domaine et le résultat de signature DKIM , et DMARC alignement. DMARC peut passer par un résultat SPF réussi aligné ou un résultat DKIM réussi aligné ; il n’est pas universellement nécessaire que les deux soient réussis. L'authentification ne garantit pas non plus le placement dans la boîte de réception ni ne valide l'intention commerciale d'un message. RFC 9989
Traitez l'exemple DMARC affiché comme une décision politique
L'explication du fournisseur décrit une valeur DMARC actuelle et un exemple de valeur DMARC recommandée dans la fenêtre contextuelle. Un exemple n’est pas l’autorisation de remplacer la stratégie d’une organisation. Examinez tous les itinéraires d’envoi légitimes, signalez les destinations et les conséquences avant d’approuver tout changement de politique. La portée de ce manuscrit est la planification de la configuration et la collecte de preuves, et non une recommandation visant à imposer une politique d'application particulière sur un domaine non examiné. Séparez les décisions DMARC de la copie de la clé DKIM émise ou de la fusion d’une autorisation d’expéditeur. Explication de l'authentification de l'expéditeur
Feuille de travail d'acceptation vierge
- Compte, domaine d'envoi prévu, propriétaire de l'entreprise et disponibilité des outils : ____.
- Instructions générées capturées sur, opérateur DNS approuvé et noms exacts du propriétaire : ____.
- SPF existant préservé, émis ip4 examiné, politique complète vérifiée : ____.
- Valeur TXT DKIM unique et liaison de domaine examinées : ____.
- Valeurs existantes par rapport aux valeurs recommandées, explication de non-concordance et approbation : ____.
- Début de l'authentification autorisée, état du réseau observé et notification : ____.
- Propriétaire de la décision politique DMARC et approbation séparée, le cas échéant : ____.
- Preuve autorisée du message reçu, résultat de l'alignement et itinéraires non résolus : ____.
- Déclencheur de revalidation après des modifications DNS ultérieures et propriétaire de la version : ____.
Diagnostic fictif : la comparaison verte n’était pas le test final
Un organisme de bienfaisance fictif prépare l'authentification pour notices.example . Son opérateur copie dans un premier temps une clé DKIM précédemment émise pour appeals.example . Le réviseur arrête la modification car les instructions sont spécifiques au domaine, récupère l'enregistrement de modification proposé pour le domaine correct et préserve les expéditeurs SPF existants tout en ajoutant l'autorisation émise. Rien dans cette illustration n’est une véritable requête DNS ou une action de locataire.
Dans la revue fictive, la comparaison devient ensuite verte et le compte finit par afficher Authentifié. L'équipe laisse toujours l'acceptation des messages ouverte : un brouillon de campagne utilise un sous-domaine From différent et aucun message reçu n'a établi son identité de signature. Ils corrigent l'inventaire et recherchent une vérification autorisée spécifique à un itinéraire plutôt que de déclarer chaque e-mail organisationnel authentifié. Le résultat utile est une séparation claire entre les instructions DNS correspondantes, l’activation du fournisseur et les preuves du message réellement envoyé.
La libération reste conditionnelle
Les preuves originales requises par le catalogue, l'applicabilité du compte courant, DNS en direct, le comportement des messages reçus, l'examen humain, l'accessibilité visuelle et l'autorisation du propriétaire restent non vérifiés. Ce guide documentaire fournit une proposition de workflow et un diagnostic explicitement fictif. Il ne s'agit pas d'un déploiement terminé, d'une garantie de délivrabilité ou d'une autorisation de modifier DNS , d'envoyer des instructions, de modifier la politique ou de publier l'article.