Étendez le travail à Gainsight NXT
Ce guide couvre le flux de travail du service de messagerie Gainsight NXT décrit dans sa documentation Customer Success. Ne réutilisez pas la procédure sans vérifier la portée de Gainsight PX, Community ou d'un autre produit. Une marque d'entreprise commune n'établit pas un transport de courrier commun.
Enregistrez le locataire de production, le domaine de l'expéditeur, l'adresse d'expéditeur visible, le programme Journey Orchestrator et le propriétaire DNS avant de commencer. Déterminez si le transport actuel est SendGrid ou Mailgun . Gainsight documente les deux et prévient que le changement de fournisseur de messagerie d'une organisation existante peut fausser Email Analytics. Un commutateur de transport n’est pas une étape de dépannage DNS de routine.
L’objectif n’est pas de supprimer uniquement une étiquette de marque. Il s'agit de connecter un message professionnel spécifique à une identité d'envoi autorisée et de conserver suffisamment de preuves pour diagnostiquer les échecs futurs. Examiner l'utilisation actuelle des noms proposés et les noms de l'organisation. DMARC alignement paramètres avant de demander de nouveaux enregistrements.
Demander la configuration prise en charge
La procédure NXT de Gainsight commence avec Gainsight installé et MDA activé. L'administrateur fournit au support le domaine d'expéditeur demandé et l'ID de locataire de production, trouvés sous Administration > Paramètres de l'application. Le support renvoie le message pertinent CNAME enregistrements. L'équipe DNS les publie, puis le Support et les Opérations valident le domaine.
Utilisez l'ensemble renvoyé comme demande de modification, et non comme suggestion pour copier les valeurs des captures d'écran. Confirmez le locataire, le domaine et le fournisseur exacts auprès du propriétaire du ticket. Séparez les enregistrements d'authentification de domaine des enregistrements de liens de courrier électronique de marque. Les liens de suivi peuvent être nécessaires sur le plan opérationnel, mais un lien de marque fonctionnel ne prouve pas SPF, DKIM ou alignement DMARC .
Avant la publication, rédigez un petit inventaire pour chaque enregistrement demandé : nom complet du propriétaire, type, cible, objectif, utilisation existante et valeur de récupération. Les interfaces DNS diffèrent selon qu'elles acceptent une étiquette relative ou un nom complet. Résolvez cette différence avant de sauvegarder. Ne modifiez pas un existant sélecteur qui appartient à un autre expéditeur simplement parce que la nouvelle valeur apparaît dans la réponse du support.
N'inventez pas de SPF ou de raccourci de sélection
La source NXT décrit SPF géré par SendGrid pour son itinéraire de sécurité automatisé et autorise les demandes de sélecteurs DKIM personnalisés comportant jusqu'à trois caractères. Ces faits n'identifient pas les dossiers de chaque locataire ou de Mailgun . Obtenez des valeurs exactes via le processus pris en charge plutôt que d’ajouter une inclusion SPF racine générique.
SPF est évalué par rapport à l’identité de l’enveloppe SMTP . Une nouvelle autorisation de domaine racine peut ne pas être pertinente si le service utilise un domaine de rebond différent. À l’inverse, la suppression d’une autorisation root existante pourrait bloquer un autre expéditeur légitime. Traitez l'ensemble de la stratégie SPF et ses dépendances comme un changement distinct au niveau du domaine lorsqu'il est réellement nécessaire. Plusieurs politiques SPF candidates chez le même propriétaire ne constituent pas un moyen valable de combiner des services.
Les collisions de sélecteurs méritent une résolution explicite. Demandez un sélecteur pris en charge approprié avant la publication et conservez les enregistrements de l'ancien service jusqu'à la fin de son utilisation. La publication DNS à elle seule ne prouve pas que Gainsight a activé la nouvelle configuration de signature.
Vérifier le transfert du support et le programme réel
Vérifiez d’abord que DNS faisant autorité contient exactement les CNAME renvoyés et que les cibles sont résolues comme prévu. Obtenez ensuite le résultat de la validation du fournisseur. Une confirmation de support clôt le transfert de configuration, mais l'acceptation nécessite également l'envoi d'un véritable message Journey Orchestrator à un destinataire de test autorisé.
Gainsight recommande d'examiner le domaine d'envoi d'un message test et de documenter les sous-domaines gsemail ou gsnemail lors de sa vérification d'authentification. Considérez cet affichage comme un indice utile, et non comme une preuve DMARC complète. Conservez le message brut et les résultats d’authentification du système de réception approuvé. Capture From, domaine d'enveloppe, chaque domaine et sélecteur de signature DKIM , ainsi que le résultat associé à chaque identité.
Cas de diagnostic synthétique : le domaine From est example.com , SPF passe pour gsemail.example.com et DKIM passe pour example.com . DKIM fournit un alignement exact. Sous un alignement SPF strict, le sous-domaine ne correspond pas exactement à example.com , bien qu'il puisse s'aligner en mode détendu. Si un échantillon ultérieur utilise une enveloppe appartenant au fournisseur et ne dispose pas DKIM aligné, une réussite SPF générale ne démontre pas que le message de marque passe DMARC .
Répétez l’acceptation pour chaque flux de travail sensiblement distinct. Un test isolé réussi d’un programme ne prouve pas qu’un autre expéditeur, région ou transport configuré utilise les mêmes identités. Incluez le propriétaire de l'entreprise dans le choix des flux de travail qui nécessitent des échantillons distincts.
Diagnostiquer sans changer de prestataire prématurément
Si DNS faisant autorité est erroné, corrigez les noms, les types ou les valeurs et répétez la validation. Si DNS est correct mais que la signature est absente, renvoyez le locataire exact et la preuve du message au propriétaire du support pour l'activation ou la révision de l'itinéraire. Si l'authentification est valide mais que l'application indique Envoyé sans événement de livraison, examinez l'événement et le système de réception plutôt que de traiter Envoyé comme une preuve de réception dans la boîte de réception.
N’affaiblissez pas une politique DMARC à l’échelle d’un domaine pour dissimuler un programme défaillant. Suspendez ou redirigez le flux de travail concerné dans le cadre d'une décision de récupération approuvée. Conservez les jeux d’enregistrements précédents et la configuration de transport avant modification. Gardez l'accès aux preuves de message conservées sous contrôle, car le contenu du client et les adresses des destinataires peuvent être présents.
Limites d’achèvement et de preuve
L'achèvement signifie une demande d'assistance rapprochée, des modifications DNS approuvées, une validation du fournisseur et une authentification du récepteur observée pour le programme prévu. Enregistrez l’état distinct de chaque étape. Ce manuscrit utilise la documentation de première partie et le raisonnement protocolaire actuellement conservés ; l'exemple d'identité est synthétique. Aucun locataire Gainsight, aucun ticket d'assistance, aucune modification DNS ou aucun message délivré n'a été consulté ou exécuté. Un propriétaire humain doit fournir et examiner les preuves réelles avant de traiter l'itinéraire comme étant une production vérifiée.
Comparez le résultat du soutien avec le programme réel
Le cas écrit GS-01 suppose que le support a validé la configuration example.com approuvée, mais qu'un deuxième programme Journey Orchestrator n'a pas été échantillonné. Son From prévu est success@example.com ; Le domaine de l'enveloppe, DKIM d=/s= et les résultats du récepteur sont tous inconnus. Un lien de marque fonctionnel de ce programme ne peut pas combler ces lacunes. Le propriétaire du programme doit confirmer son expéditeur et son transport, puis collecter un message contrôlé autorisé avant d'étendre le déploiement. Ne changez pas SendGrid et Mailgun uniquement pour résoudre un résultat non observé. Aucun ticket, paramètre de locataire, message ou opération DNS n'a été exécuté.
Préserver la limite d’application
RFC 9989 La section 7.4 nécessite DKIM valide, et non SPF seul, pour la publication de domaines. 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.