Portée et configuration spécifique au fournisseur
Simplifiez l'authentification du domaine de l'expéditeur des documents à l'aide SPF, DKIM et DMARC. Son nouvel article sur l'expéditeur en masse clarifie la transition depuis l'ancien k5 Sélecteur DKIM à dkim2048. Utilisez ce comportement actuel lors de l'évaluation d'un domaine plutôt que de traiter une clé historique comme une preuve de la route de signature prévue.
Inventoriez le domaine utilisé dans l'adresse de l'expéditeur et ses enregistrements d'authentification existants. Le guide du domaine de l'expéditeur publie la référence SPF v=spf1 include:carmamail.com ~all . Fusionnez l’inclusion requise avec d’autres services autorisés dans une seule politique. Ne remplacez pas une politique établie et n'adoptez pas la fin de la ligne de base sans examiner l'inventaire d'envoi complet et le budget de recherche.
Pour DKIM , le guide le plus récent indique que Symplify signe avec un Clé de 2048 bits en utilisant le sélecteur dkim2048. Publiez la clé publique du fournisseur actuel au TXT sur dkim2048. _domainkey .<votre-domaine>. Copiez la clé ininterrompue de la source actuelle plutôt que de transcrire une longue clé à partir d'une capture d'écran ou de cet article. Si un éditeur DNS a besoin de plusieurs chaînes de caractères en raison de sa limite de 255 caractères, elles doivent former une seule chaîne logique. Enregistrement TXT. Ne transformez pas les morceaux en enregistrements de clé concurrents indépendants et n'ajoutez pas d'espaces à l'intérieur du matériel de clé publique.
Le fournisseur explique que lorsque seulement k5. _domainkey existe, il continue à utiliser l'ancienne clé jusqu'à ce que dkim2048 soit ajouté. Aucune clé n'étant publiée, Symplify signe en utilisant son propre domaine, et cette signature ne s'aligne pas sur le domaine From du client. C'est pourquoi un laissez-passer DKIM générique ne constitue pas une preuve d'acceptation suffisante. Lisez les valeurs réelles d= et s= sur la campagne reçue.
Publiez ou examinez la politique DMARC applicable. Le fournisseur propose p=none comme point de départ et comme exemple d'adresse de reporting, mais la boîte aux lettres doit être réelle et autorisée. Ne rétrogradez pas une stratégie existante pour refléter un exemple. Symplify propose une vérification de la configuration via domainsetup@symplify.com ; demander à cette équipe est une communication distincte nécessitant une autorisation. L'authentification ne remplace pas non plus l'autorisation du destinataire, l'hygiène de la liste ou un lien de désabonnement visible. Le nouveau guide dit désabonnement en un clic les en-têtes sont ajoutés par le service, tandis qu'un lien visible reste sous la responsabilité du propriétaire du modèle.
La décision qui compte
Confirmez que la signature dkim2048 s'aligne sur le domaine From du client plutôt que d'accepter un laissez-passer DKIM de domaine de fournisseur.
Vérifier les enregistrements publiés et le chemin d'envoi réel
Enregistrez le propriétaire du changement, le produit d'envoi, le domaine, la fenêtre de maintenance approuvée et les réponses DNS antérieures avant de procéder à la modification. Obtenez les valeurs d'enregistrement actuelles à partir du compte nommé ou du flux de travail du fournisseur documenté. Séparez les valeurs fournies par le fournisseur des choix contrôlés par votre organisation, tels que la stratégie DMARC et les destinataires des rapports. Les boîtes aux lettres MX existantes, les enregistrements TXT de vérification sans rapport et les sélecteurs DKIM actifs ne sont pas des candidats au nettoyage simplement parce qu'un nouveau service est ajouté.
Interrogez les serveurs de noms faisant autorité pour chaque propriétaire exact et type d'enregistrement après la publication. Enregistrez l'heure de la requête, le serveur qui répond et la réponse complète. Comparez les chaînes TXT comme une valeur logique où la réponse DNS les divise en chaînes de caractères. Vérifier CNAME cibles ainsi que l'alias de départ. Comparez ensuite une réponse de résolution récursive pour identifier les différences de mise en cache. Une validation réussie du fournisseur constitue une preuve utile de la configuration, mais elle ne permet pas d'établir ce qu'un destinataire réel a reçu.
Envoyez uniquement un test autorisé à un destinataire contrôlé en utilisant l'itinéraire de produit prévu. Conserver le message brut et le système de réception de confiance Authentication-Results. Enregistrez le visible du domaine, SMTP COURRIER DE ou observé Return-Path domaine, chaque valeur DKIM d= et s=, les résultats SPF et DKIM et le résultat DMARC du récepteur. Une vérification SPF ou DKIM réussie prend en charge DMARC uniquement lorsque son domaine authentifié s'aligne sur le domaine De visible dans le cadre de la stratégie applicable. Répondre à et un nom d’affichage de marque ne sont pas des identités d’alignement. RFC 7208 , RFC 6376 et RFC 9989 fournissent la base protocolaire de ces distinctions.
Feuille de travail d'acceptation, limites de récupération et de preuves
Il s'agit d'une feuille de travail d'acceptation originale, et non d'un rapport de tests en direct. Marquez chaque porte en attente jusqu'à ce que des preuves existent : étendue du compte confirmée ; DNS précédent capturé ; nouveau propriétaire/type/valeur exact publié ; vérification du fournisseur terminée ; itinéraire prévu exercé ; identités reçues enregistrées ; authentification alignée confirmée ; les autres expéditeurs ne sont pas affectés. Attribuez une personne et un dossier de preuves à chaque porte. Une porte rouge bloque le déploiement même lorsque le tableau de bord du fournisseur est vert.
Si un test échoue, distinguez d'abord la publication manquante, les données obsolètes mises en cache, la configuration du fournisseur inactif, la mauvaise route sortante et l'authentification non alignée. Corrigez le moindre défaut démontré et testez à nouveau. N'affaiblissez pas DMARC et ne supprimez pas les enregistrements d'autres expéditeurs simplement pour réussir un test. Si une modification endommage le courrier existant, utilisez le plan de récupération approuvé et la configuration capturée avant la modification, en coordonnant toute modification d'expéditeur côté fournisseur ainsi que DNS . Conservez les anciennes clés pendant que les messages en file d'attente ou un chevauchement approuvé en ont encore besoin.
Aucun locataire client, aucun changement faisant autorité avant/après ou aucun message réellement reçu n'était disponible pour ce manuscrit. Les sources retenues soutiennent le flux de travail documentaire ; ils ne satisfont pas au portail des preuves en direct commandé. L’examen par un vérificateur indépendant et l’approbation des PME humaines restent en attente. Ne décrivez pas ce guide comme étant validé sur le terrain et ne le publiez pas comme ayant franchi ces portes.
Traitez la signature de secours comme une preuve incomplète
Le cas écrit SY-01 suppose qu'une campagne a From news@example.org , qu'aucun sélecteur de domaine client n'est publié et que le destinataire hypothétique affiche une signature de passage provenant d'un domaine de fournisseur non lié. Le domaine exact du fournisseur, le sélecteur et le résultat SPF sont délibérément inconnus, donc aucun verdict DMARC complet n'est affirmé. Le propriétaire DNS doit rapprocher l'enregistrement dkim2048 prévu avec le propriétaire de la campagne, puis obtenir un message reçu contrôlé. N'étiquetez pas une passe DKIM générique comme un alignement sur le domaine client ou ne modifiez pas l'application pour masquer l'identité manquante. Aucune campagne, e-mail de vérification ou action DNS n'a eu lieu.
Préserver la limite d’application
La section 7.4 RFC 9989 requiert DKIM valide, et non SPF seul, pour les domaines publiant p=reject, et met en garde contre l'interopérabilité du courrier indirect et des listes de diffusion. Un seul test réussi de message direct ne prouve pas que chaque voie légitime est prête à faire l’objet d’une politique plus forte. Conserver la protection approuvée existante tout en diagnostiquant l’écart réel ; tout changement de politique nécessite sa propre décision.