Commencez par le voyage et diffusez les identités
Un compte Rejoiner peut envoyer via des parcours automatisés et des diffusions programmées. Identifiez les workflows utilisés avant de demander des modifications DNS . Enregistrez la marque, le propriétaire du compte, l'adresse d'expéditeur prévue, la boîte aux lettres de réponse surveillée et un test contrôlé pour chaque chemin. Utilisez un client test et un contenu inoffensif plutôt que d'inscrire de vrais acheteurs ou de générer de vrais achats à des fins de diagnostic.
Rejoindre Documentation sur les paramètres de messagerie place les détails de l’expéditeur par défaut sous Paramètres et l’onglet E-mail. Il distingue le nom d'affichage, l'adresse de l'expéditeur et l'adresse de réponse. Vérifiez ces valeurs par défaut par rapport au message réel à tester. Un nom d'affichage familier ne permet pas d'établir quel domaine sera authentifié.
La boîte aux lettres de réponse a un objectif différent de celui des domaines de signature et d'enveloppe. Vérifiez que les réponses parviennent à l'équipe prévue, mais ne traitez pas une réponse fonctionnelle comme une preuve d'authentification. Conservez la décision de marque et le tableau d'identité technique ensemble afin que le responsable marketing puisse voir ce que les destinataires rencontreront.
Obtenir le jeu d'enregistrements spécifique au compte actuel
Rejoindre ressource d'authentification décrit l'assistance relative à l'intégrité de l'authentification client. Ses documents publics constituent un contexte utile, mais les sources examinées ne fournissent pas d'informations complètes et spécifiques aux locataires. sélecteur, clé, SPF autorisation, procédure d'enveloppe personnalisée ou séquence d'activation en cours. Ces détails restent en attente jusqu'à ce qu'ils soient fournis pour le compte réel.
Demandez à l'équipe chargée du compte le domaine d'envoi approuvé, les propriétaires et types exacts d'enregistrements DNS , les valeurs publiques attendues. DKIM d=, envelope-domain behavior and any activation requirement. Confirm whether journeys and broadcasts use the same configuration. Request an explicit answer about custom envelope alignement plutôt que de supposer que le choix d'un nom de marque modifie automatiquement le Return-Path.
Ne générez pas de clé DKIM aléatoire à partir d'un didacticiel générique et ne la publiez pas pour Rejoiner. Le service doit posséder la clé de signature correspondante et être configuré pour utiliser l'identité prévue. Ne copiez pas le sélecteur d’un autre client et ne déduisez pas une inclusion SPF d’un fournisseur en amont observé. L'autorité de configuration doit provenir des instructions du compte pris en charge.
Choisir et documenter la limite du domaine d'envoi
Rejoindre Guide des outils Google Postmaster indique que le domaine de l'expéditeur est normalement un sous-domaine réservé au courrier Rejoiner ou marketing. Traitez cela comme un modèle documenté, et non comme un nom d'hôte obligatoire ou une preuve de la configuration actuelle du locataire. Demandez à l'entreprise et aux propriétaires DNS d'approuver le domaine réellement attribué à ce programme.
Notez la relation entre le De visible, le domaine de signature et le domaine de l'enveloppe. Dans le cadre d'un alignement détendu, les domaines associés peuvent être qualifiés différemment que dans le cadre d'un alignement strict. Ne présumez pas que la création d’un sous-domaine marketing garantit la compatibilité avec une politique stricte existante. Résolvez la conception de l'identité avant de configurer une nouvelle adresse de campagne.
Gardez les noms de suivi des sites Web et les enregistrements de surveillance-vérification séparés de l'authentification du courrier. Les instructions du maître de poste de Rejoiner décrivent un message émis par Google Enregistrement TXT pour prouver la propriété du domaine pour ce service de surveillance. La publication de ce jeton n’active pas Rejoiner DKIM et ne fournit pas d’autorisation SPF . Enregistrez l'objectif de chaque entrée DNS afin que le nettoyage futur ne confonde pas l'accès aux analyses avec l'autorisation d'envoi.
Publier uniquement les enregistrements d'authentification approuvés
Enregistrez une base de référence des enregistrements DNS pertinents, leurs noms complets, types, valeurs et TTL. Inclure SPF , DKIM et DMARC dépendances pour le courrier des employés et autres outils marketing. Confirmez quelle zone contient le sous-domaine de l'expéditeur prévu et si l'éditeur ajoute automatiquement son suffixe.
Appliquez chaque enregistrement émis au propriétaire et au type exacts. Comparez la réponse publique résultante avec les instructions du fournisseur, et pas seulement avec l'affichage de l'éditeur DNS . Si un sélecteur ou un alias entre en conflit avec un autre service, recherchez une alternative prise en charge plutôt que de remplacer silencieusement l'enregistrement de l'autre fournisseur. Conservez l'étape d'activation et son horodatage avec le changement.
SPF selon RFC 7208 évalue l'identité SMTP plutôt que le From visible seul. Lorsqu’une stratégie SPF est requise, conservez une seule stratégie chez ce propriétaire et examinez le coût complet des requêtes DNS, y compris les dépendances imbriquées. N'étendez pas l'autorisation du domaine racine simplement parce qu'un article d'authentification générique recommande SPF .
Préserver la politique DMARC , les modes d'alignement et les destinations des rapports existants de l'organisation, à moins qu'une modification distincte approuvée ne soit justifiée. Un nouveau programme marketing doit s'adapter à la conception d'authentification du domaine. Cela ne devrait pas affaiblir silencieusement la protection du courrier des employés ou des services transactionnels non liés.
Éliminer un message qui n'a jamais été envoyé
Avant de diagnostiquer DKIM manquant, vérifiez que le test a généré un e-mail. Le Guide des paramètres de messagerie documente la suppression de domaine et une limite de fréquence à l’échelle du compte pour les parcours et les diffusions. Ces contrôles peuvent empêcher un destinataire de test particulier de recevoir un nouveau message. Examinez les preuves de compte pertinentes avant de modifier DNS ou de déclencher à plusieurs reprises le même événement client.
Le même guide indique que le compte BCC s'applique aux messages de voyage, et non aux diffusions, et prévient que l'engagement BCC peut fausser les rapports. N'utilisez pas un BCC de diffusion manquant comme preuve d'échec de livraison. Envoyez à un destinataire contrôlé via l'itinéraire réel et conservez les preuves de livraison sans cliquer inutilement sur les liens de suivi.
Si un flux de travail est supprimé, plafonné ou n'est jamais déclenché, résolvez cette condition de test via le propriétaire approprié. L'authentification est évaluée sur le courrier qui parvient à un destinataire ; une décision de non-envoi du côté de l'application ne peut pas être réparée en ajoutant un enregistrement DNS . Gardez cette distinction visible dans le journal des problèmes.
Lire les en-têtes des deux flux de travail
Une fois la configuration prête, envoyez un e-mail de parcours contrôlé et une diffusion contrôlée lorsque les deux sont concernés. Capturez l'ID du message, l'heure UTC, From, Return-Path , chaque DKIM d= et s=, ainsi que les résultats d'authentification approuvés du système de réception final. Enregistrez l’identifiant du voyage ou de la diffusion afin que les preuves puissent être reproduites.
Spécification de DKIM définit le domaine de signature et le sélecteur. Inspectez chaque signature et identifiez celle, le cas échéant, qui réussit et s'aligne avec le De visible. Sous RFC 9989, DMARC nécessite un chemin SPF ou DKIM de passage aligné. Un laissez-passer fournisseur-domaine non lié est insuffisant en soi.
Enregistrez le résultat de l'authentification séparément du placement et de l'engagement. Un faible taux d'ouverture ne prouve pas un échec DKIM , et un seul placement dans la boîte de réception ne certifie pas l'intégralité du programme. Lorsqu'un nouveau message échoue, comparez ses identités observées avec la configuration émise par le compte avant de transmettre un en-tête expurgé et l'heure UTC exacte.
Feuille de travail d'acceptation des participants
Entrées indépendantes complètes pour les voyages et les diffusions :
- Propriétaire du compte, de la marque, de l'itinéraire et de l'entreprise : ____.
- Destiné à partir de la boîte aux lettres de réponse et du domaine d'envoi approuvé : ____.
- Ensemble d'enregistrements du fournisseur et comportement de signature/enveloppe pris en charge : ____.
- Propriétaires DNS exacts, types, références de valeur et heure d'activation : ____.
- Politique DMARC existante et modes d'alignement applicables : ____.
- Vérifications contrôlées des destinataires, des déclencheurs, de la suppression et de la fréquence : ____.
- ID du message, heure UTC et identifiant du flux de travail : ____.
- Return-Path , tous DKIM d= et s=, résultats fiables : ____.
- Mécanisme aligné réel et observation du placement : ____.
- Action de récupération, réviseur et questions de capacité en suspens : ____.
Conservez la vérification de la propriété Postmaster dans une ligne de surveillance distincte. Il peut prendre en charge le travail de réputation ultérieur mais ne peut pas remplir les champs d'acceptation de l'authentification.
Diagnostic fictif d'une copie diffusée absente
Exemple fictif uniquement : Juniper Outfitters reçoit des copies BCC de voyage mais pas de BCC de diffusion, puis propose de remplacer son enregistrement DKIM . L'administrateur vérifie la limite BCC documentée et teste la diffusion à l'aide d'un destinataire réel contrôlé. Cette copie montre DKIM aligné et un pass DMARC .
L'équipe laisse DNS inchangé et corrige sa méthode de collecte de preuves. Il vérifie séparément les contrôles de fréquence et de suppression pour les destinataires des tests qui ne reçoivent rien. Aucun compte ou message Juniper n'a été inspecté ; l'exemple montre pourquoi la preuve du flux de travail doit précéder une réparation d'authentification.
Laisser visibles les capacités non résolues
Revérifiez après les modifications de l'expéditeur, les nouveaux flux de travail, la migration DNS ou les mises à jour des clés du fournisseur. Les valeurs DNS spécifiques au compte, la prise en charge des enveloppes personnalisées, la vérification en direct des locataires et des en-têtes, l'examen visuel, l'approbation humaine de la PME et la publication restent en attente. La documentation publique prend en charge les distinctions de paramètres ci-dessus mais ne ferme pas ces portes de mise en œuvre.
Utilisez les conseils sur les produits sans adopter de raccourcis de protocole généraux
La ressource d'authentification générale est l'arrière-plan, et non une clé émise par le compte ou une preuve que le courrier authentifié est sûr. Utilisez les normes de protocole pour l’évaluation de l’identité et les instructions émises par le fournisseur pour la configuration. La diffusion de réussite fictive n'est qu'un résultat indicatif stipulé, et non un test de locataire Rejoiner effectué pour cet examen.
Séparer l’acceptation des messages du déploiement de la politique
Un résultat SPF aligné peut satisfaire une évaluation de message, mais ne justifie pas à lui seul le déplacement d'un domaine entier vers le rejet. RFC 9989 La section 7.4 nécessite DKIM valide pour la publication de domaines p=reject et met en garde contre l'interopérabilité du courrier indirect. Inventoriez tous les expéditeurs légitimes et les itinéraires indirects avant que le propriétaire de la politique n’approuve l’application. Aucune modification DNS , opération de locataire ou test de message reçu n’a été exécuté pour cet article.