Séparez l'engagement de compte des autres produits de messagerie Salesforce
Salesforce Account Engagement dispose de son propre workflow de gestion de domaine. Commencez par confirmer que le message est envoyé via Account Engagement, anciennement appelé Pardot, plutôt que par courrier électronique principal Salesforce ou Marketing Cloud Engagement. Une recette DNS pour un autre produit Salesforce peut utiliser des contrôles différents et ne doit pas être importée simplement parce que l'organisation utilise le même fournisseur. Ce guide couvre la vérification du domaine d'envoi de Account Engagement, DKIM et le chemin de retour personnalisé assisté en option par le support.
Répertoriez chaque unité commerciale, marque et domaine prévu utilisé par le compte. Inclut l'expéditeur réel sélectionné par les paramètres de campagne et d'automatisation. Un domaine qui apparaît dans l'adresse de boîte aux lettres d'un utilisateur n'est pas automatiquement configuré pour chaque itinéraire Account Engagement. Désignez un propriétaire marketing et un administrateur DNS pour examiner ensemble l'inventaire avant de modifier les enregistrements d'un domaine partagé.
L'objectif d'acceptation est un message reçu contrôlé avec un mécanisme d'authentification de réussite aligné. La validation de la propriété du domaine, la publication DNS et un statut de gestion verte sont des preuves intermédiaires utiles. Aucun ne prouve à lui seul qu'une campagne spécifique a utilisé l'identité prévue ou qu'un serveur récepteur a accepté son authentification.
Comprendre le chemin SPF par défaut avant de modifier DNS racine
Salesforce's Conseils DNS pour l'engagement de compte indique que le courrier d'engagement de compte passe SPF via son infrastructure d'envoi contrôlée et ne nécessite pas de modification SPF client pour cette configuration par défaut. N'ajoutez pas d'inclusion Salesforce SPF générique au domaine racine de l'organisation simplement parce que le nom du produit apparaît dans un DMARC rapport. Confirmez d'abord l'itinéraire réel et l'identité évaluée.
SPF authentifie le SMTP COURRIER DE identité, avec un traitement séparé pour HELO, sous RFC 7208. Son résultat est distinct de alignement avec le De visible. Une vérification SPF de domaine de fournisseur réussie peut coexister avec SPF non aligné. La modification de la stratégie d'un autre domaine ne modifie pas le domaine d'enveloppe utilisé par un message.
Préservez la politique SPF nécessaire aux autres services de l’organisation. Si une configuration personnalisée autorisée séparément nécessite une modification de stratégie, examinez une stratégie complète chez ce propriétaire, y compris les termes de requête DNS imbriqués et la limite de recherche de protocole. Ne créez pas une seconde Enregistrement SPF ou supprimez les expéditeurs non liés pour faire place à une exigence non vérifiée.
Vérifier la propriété et DKIM en tant qu'enregistrements distincts
Utilisez la gestion de domaine pour identifier le domaine d'envoi d'e-mails prévu et ses entrées DNS attendues. Le Conseils DNS distingue la clé de validation du domaine de sa DomainKey. La valeur de validation établit la propriété de l'envoi ; la valeur DKIM prend en charge la signature des messages. Conservez les deux objectifs dans la feuille de travail plutôt que d'en traiter aucun. Enregistrement TXT contenant une valeur Salesforce comme preuve interchangeable.
Copiez les valeurs du compte réel. Enregistrez le propriétaire complet de l’enregistrement, le type, la valeur et la date de l’instruction avant d’effectuer la modification DNS . Vérifiez si un autre compte Account Engagement ou un autre service dépend déjà du même propriétaire. N'écrasez pas un enregistrement conflictuel, ne réutilisez pas la valeur d'un autre client ou ne modifiez pas un sélecteur à un nom inventé. Demandez de l'aide pour une résolution prise en charge lorsque les arrangements de compte entrent en conflit.
Gardez le domaine d'envoi d'e-mails distinct du domaine de suivi. Salesforce met explicitement en garde contre l'utilisation du domaine identique pour ces deux fonctions. Un nom d'hôte de suivi de marque n'est pas la même chose que le domaine From, même lorsque les deux partagent un parent. Suivez les dépendances de l'inventaire séparément afin que le travail d'authentification ne modifie pas par inadvertance les URL des actifs ou les liens de campagne.
Publiez la DomainKey via le flux de travail documenté
Salesforce's Instructions de mise en œuvre DKIM nécessitent le rôle d'administrateur d'engagement de compte. Dans l'application Lightning, ouvrez Paramètres d'engagement du compte, puis Gestion de domaine. Dans l’interface alternative Account Engagement, le point de départ documenté est Admin. Sous Domaines d'envoi d'e-mails, ouvrez les entrées DNS attendues pour le domaine choisi et copiez la valeur DomainKey pour la publication au format TXT .
Utilisez le propriétaire et la valeur indiqués pour ce compte et ce domaine. L'article actuel indique qu'il faut prévoir jusqu'à 24 heures pour que la signature prenne effet après l'ajout de l'enregistrement. Considérez cela comme une indication de timing du fournisseur, et non comme une garantie que chaque cache ou récepteur DNS sera mis à jour au même instant. Enregistrez l'heure de publication et attendez l'état attendu avant de juger un nouveau test.
Confirmez la réponse DNS publique, y compris le propriétaire exact et pleinement qualifié. Les éditeurs DNS ajoutent parfois le nom de la zone au champ hôte, créant ainsi un suffixe dupliqué lorsqu'un nom complet est saisi. Examinez la réponse obtenue plutôt que de vous fier au formulaire de saisie. Enregistrez toute erreur de gestion de domaine et ses détails afin que l'assistance puisse enquêter sur l'échec réel au lieu d'un statut paraphrasé.
Décidez si un chemin de retour personnalisé est requis
Salesforce's Article d'assistance DMARC décrit DKIM aligné comme chemin DMARC normal et explique que le chemin par défaut chemin de retour le domaine ne s'aligne pas avec le De visible. Il documente également une demande de chemin de retour personnalisé assistée par le support. La limitation indiquée est un domaine de chemin de retour personnalisé fixe par unité commerciale, plutôt qu'un domaine variable sélectionné pour chaque message.
Avant de demander cette option, identifiez les besoins métier. Une organisation qui a besoin SPF aligné ainsi que DKIM doit évaluer la disposition réelle des domaines et le mode d'alignement avec support. Une unité commerciale envoyant des marques indépendantes ne doit pas supposer qu’un chemin de retour fixe peut s’aligner sur chaque domaine From. Gardez cette question de conception ouverte jusqu'à ce que les identités observées et la configuration prise en charge la résolvent.
Obtenez les enregistrements DNS exacts du dossier de support et demandez au propriétaire DNS d’examiner les conflits et les dépendances. Cet article ne fournit aucune cible universelle de chemin de retour personnalisé ni aucun commutateur d’activation. La publication d'enregistrements devinés ou la copie de la configuration du domaine de rebond d'un autre produit peut interrompre un itinéraire de travail sans satisfaire aux exigences.
Testez l’expéditeur sélectionné via le flux de messages réel
Envoyez des messages contrôlés inoffensifs via chaque domaine d'envoi et chaque itinéraire d'unité commerciale sensiblement différents. Utilisez la même sélection d’expéditeurs que pour la campagne ou l’automatisation planifiée. Enregistrez la référence de la campagne, l'ID du message, l'heure UTC et le destinataire du test externe. Si une fonctionnalité d'aperçu ou de test utilise un chemin différent de celui de la production, résolvez cette différence avant de la traiter comme une preuve représentative.
Sur le système de réception approuvé, capturez From, Return-Path et tous les domaines et sélecteurs de signature DKIM . RFC 6376 définit les valeurs d= et s= utilisées pour localiser la clé de vérification publique. Comparez le domaine de signature observé avec le domaine d'envoi configuré. Un enregistrement DNS peut être correct alors qu'un message utilise toujours un expéditeur inattendu ou un autre itinéraire.
Appliquer RFC 9989 aux résultats réels. DMARC peut passer par un passage aligné Signature DKIM ou en passant SPF aligné. Enregistrez quel mécanisme a fourni le résultat et quel mode d’alignement s’est appliqué. Conservez l'authentification SPF , l'alignement SPF , l'authentification DKIM et l'alignement DKIM dans des champs séparés. Cela évite qu’un seul statut vert ne cache une exigence non testée.
Résolvez la limite défaillante au lieu de modifier chaque contrôle
Si le domaine d'envoi n'est pas vérifié, comparez sa clé de validation et son propriétaire DNS exact avec les entrées DNS attendues. Si DKIM est manquant après la période d'activation prévue, confirmez le domaine et le compte sélectionnés, puis vérifiez les erreurs de gestion de domaine. Si une signature échoue, vérifiez le sélecteur et la valeur publique et inspectez tout système en aval qui modifie le message après la signature.
Si DMARC échoue alors que SPF passe, étudiez l'alignement et vérifiez si DKIM aligné a été configuré pour cet expéditeur. Ne considérez pas le succès SPF par défaut comme une promesse de succès DMARC . Si un chemin de retour personnalisé est impliqué, comparez l’identité de l’enveloppe observée avec le paramètre d’unité commerciale fixe et les instructions fournies par le support. Conservez un message d’échec représentatif pour le diagnostic.
Conservez la politique DMARC de l’organisation et les destinations de reporting sous leur propriété actuelle. L'article Salesforce décrit la nécessité d'une surveillance DMARC externe plutôt que d'un engagement de compte collectant ces informations. rapports d'échec. Le travail d’authentification DNS ne doit pas remplacer silencieusement les destinations de reporting ou réduire l’application des règles auprès des expéditeurs non liés. Examinez séparément toute modification de politique proposée avec les propriétaires de messagerie et de sécurité.
Feuille de travail du domaine d'engagement de compte
- Compte, unité commerciale, marque et workflow d'envoi : ____.
- Adresse sélectionnée à partir de et domaine d'envoi d'e-mail configuré : ____.
- Domaine de suivi séparé et ses dépendances existantes : ____.
- Clé de validation et références d’enregistrement DKIM à partir des entrées DNS attendues : ____.
- Réponses DNS publiques, heure de publication et état de gestion : ____.
- Conception de chemin de retour personnalisée par défaut ou assistée par support : ____.
- Limitation du chemin de retour personnalisé et confirmation du support, le cas échéant : ____.
- Testez les identités ID de message, heure UTC, De, Return-Path et DKIM : ____.
- Résultats d'authentification fiables et mécanisme DMARC aligné : ____.
- Exceptions, surveillance du propriétaire et récupération approuvée : ____.
Exemple fictif de succès d' SPF sans alignement
Cas écrit fictif uniquement : AE-01 suppose que l'unité commerciale Nord envoie sous la forme news@example.org et que l'unité commerciale Sud envoie sous la forme news@example.net . Un chemin de retour personnalisé fixe proposé sous bounce.example.org peut s'aligner sur le premier sous un alignement SPF assoupli, mais ne peut pas être supposé s'aligner sur le second sans rapport. Les signatures DKIM et les résultats SPF restent inconnus, donc aucune des deux voies n'a de verdict DMARC affirmé. Les propriétaires de marketing et de messagerie doivent séparer les paramètres de l'unité commerciale et valider l'alignement DKIM par domaine De sélectionné avant de demander une modification SPF racine. Toutes les identités et tous les arrangements sont inventés ; aucun cas de support, requête DNS ou message n’a été exécuté.
Gardez l'achèvement lié aux preuves réelles
Le flux de travail documenté ne vérifie pas les autorisations d'un locataire réel, les valeurs générées ou la capacité de chemin de retour personnalisé. Ces vérifications de compte, la vérification DNS et d'en-tête en direct, l'examen visuel et l'approbation humaine de la PME restent en attente. Ce guide est inédit et ne doit pas être présenté comme une preuve que les campagnes d'une organisation sont authentifiées en production.
Séparez un message qui passe de la préparation à l'application
La section 7.4 RFC 9989 requiert DKIM valide pour la publication d'un domaine p=reject et met en garde concernant l'interopérabilité du courrier indirect. Un seul résultat SPF aligné ne justifie pas en soi le déploiement d’une politique de rejet. Examinez tous les itinéraires légitimes et la propriété des politiques séparément de la configuration de ce fournisseur.