Traitez le domaine d'envoi comme un lancement Sailthru coordonné
Un domaine d'envoi Sailthru a besoin de plus que des enregistrements DNS visibles avant que le courrier de production soit prêt. Le lancement devrait inclure l'authentification de domaine, l'activation du fournisseur, une boîte aux lettres d'expéditeur fonctionnelle et un test de livraison contrôlée. Commencez par le domaine exact après le signe arobase dans l'adresse d'expéditeur prévue. Enregistrez le compte et les messages professionnels qui l'utiliseront, et séparez les campagnes marketing de tout itinéraire transactionnel dont la configuration diffère.
Sailthru nouvelles directives sur le domaine d'envoi appelle à la configuration DNS et à un plan de rampe examiné avec son équipe. Il applique également cet examen à un domaine déjà présent dans un compte mais non activement utilisé. Un domaine dormant avec des enregistrements en place ne doit pas être traité comme ayant une réputation d'envoi établie. La préparation à l’authentification et la préparation au volume de production sont des décisions distinctes.
Ce guide couvre la configuration de l'authentification et la collecte de preuves, et non une promesse de placement dans la boîte de réception ou un calendrier universel de volume d'envoi. Utilisez la configuration approuvée du compte actuel et le contact du fournisseur pour résoudre toute incohérence. La vérification du compte réel, DNS et de l'en-tête reste en attente jusqu'à ce que l'organisation termine la feuille de travail et les tests ci-dessous.
Vérifiez l’alignement strict avant d’effectuer le changement
Lire l'existant DMARC politique et enregistrer son alignement modes avant d’inscrire le domaine. Sailthru Guide de configuration des enregistrements DNS indique explicitement que le strict adkim ou aspf n'est pas pris en charge. Si la politique requise par l'organisation utilise l'un ou l'autre mode strict, traitez la compatibilité comme une décision de conception ouverte avec Sailthru et le propriétaire de la sécurité. Ne supprimez pas ces balises en silence et n’affaiblissez pas la stratégie pour compléter une liste de contrôle de configuration.
Considérez ensemble le domaine de l’expéditeur prévu et les routes de messagerie légitimes de l’organisation au sens large. Un ajustement isolé de la politique d'un domaine partagé peut affecter la messagerie des employés, les applications financières et d'autres services. Si un domaine d'envoi différent est proposé, évaluez son contexte politique et ses implications commerciales avant de l'utiliser. Un sous-domaine ne constitue pas automatiquement une exception sûre à toute préoccupation héritée en matière de politique ou de réputation de l’expéditeur.
Sous RFC 9989, un pass DMARC nécessite une réussite SPF ou DKIM authentification avec une identité alignée sur le domaine From. Les comparaisons détendues et strictes diffèrent, de sorte que la feuille de travail d'acceptation doit indiquer quel mode s'applique. Ne signalez pas une passe d'authentification comme une passe d'alignement simplement parce que le fournisseur a reconnu l'enregistrement DNS .
Préparer le jeu d'enregistrements et inspecter les dépendances
Obtenez les instructions Sailthru actuelles pour le domaine et conservez une base de référence de tous les propriétaires DNS concernés. La configuration publiée comprend une inclusion SPF , deux CNAME DKIM et un domaine de rebond CNAME. Examinez leurs noms complets et leurs cibles par rapport au domaine réel de l'expéditeur. Un expéditeur de sous-domaine nécessite le nom complet correspondant ; l'omission d'une étiquette peut configurer une identité différente de celle utilisée par les campagnes.
Pour SPF , examinez l'intégralité de la police auprès du propriétaire concerné sous RFC 7208. Conservez une politique SPF , conservez les autres expéditeurs requis et tenez compte des termes de requête DNS imbriqués. Une inclusion de fournisseur est une autorisation continue et non un commentaire inoffensif. N'insérez pas tous les exemples historiques provenant de différents guides et ne remplacez pas un qualificatif de terminal existant sans approbation.
Distinguer les tâches DNS par objectif. DKIM vérifie une signature. La configuration du domaine de rebond prend en charge l'identité de l'enveloppe. Les enregistrements de propriété ou de vérification par boucle de rétroaction remplissent leurs propres fonctions. Les domaines de lien et de suivi sont des dépendances opérationnelles distinctes. Une redirection de lien réussie ne prouve pas que DKIM est actif, et un message authentifié ne prouve pas que tous les anciens liens de campagne restent utilisables.
Publiez les délégations DKIM et l'activation complète du fournisseur
Le guide Sailthru actuel spécifie deux CNAME DKIM et exige que le fournisseur termine la configuration avant qu'ils ne deviennent actifs pour l'envoi. Utilisez les propriétaires et les cibles actuels exacts du domaine From et vérifiez les deux enregistrements après la publication. Ne présumez pas que la création d’un système fonctionne apparemment sélecteur est suffisant ou que la présence DNS déclenche automatiquement l'activation.
Inspectez les enregistrements existants aux noms proposés avant de les enregistrer. Un conflit CNAME doit être résolu avec les administrateurs des services dépendants. Ne combinez pas de données incompatibles chez le même propriétaire et n'inventez pas un sélecteur différent sans l'assistance du fournisseur. Vérifiez la gestion automatique des suffixes par l'éditeur DNS et comparez les réponses finales complètes avec les instructions.
Conservez une trace claire de la confirmation d'activation du fournisseur. Demandez à quelle heure les nouveaux messages doivent commencer à utiliser la configuration, puis envoyez un nouveau test après ce point. La réutilisation d'un ancien message peut afficher la configuration antérieure et induire en erreur la révision. Des modifications DNS répétées en attendant peuvent créer plusieurs états de cache qui se chevauchent et rendre le diagnostic plus difficile.
Vérifiez séparément l'identité du rebond et la boîte aux lettres de l'expéditeur.
Confirmez le CNAME du domaine de rebond dans les instructions de configuration du compte et le nom réel Return-Path observé après activation. Un alias publié ne constitue pas une preuve qu'un itinéraire d'envoi particulier l'utilise. Si l'identité de l'enveloppe reçue diffère, conservez le résultat et demandez à Sailthru quelle étape de configuration ou d'approvisionnement contrôle cet itinéraire. Ne modifiez pas la stratégie SPF racine à plusieurs reprises pour compenser une identité d’enveloppe inexpliquée.
Après l'activation du fournisseur, la vérification documentée de l'adresse de l'expéditeur s'effectue via la configuration et les e-mails vérifiés. La boîte aux lettres de l'expéditeur doit pouvoir recevoir le message de vérification. Utilisez une boîte aux lettres contrôlée par l'organisation et identifiez la personne chargée de répondre aux réponses des clients. Un nom d'affichage ou un alias marketing sans boîte de réception fonctionnelle peut créer des problèmes opérationnels même lorsque l'authentification réussit.
Lorsque vous organisez un accès à Google Postmaster ou à une boucle de rétroaction, séparez le dossier technique de l'approbation d'accès. Le guide de configuration comprend les étapes de collaboration avec les fournisseurs, mais le partage de l'accès à la surveillance reste une décision organisationnelle. Accordez uniquement l’accès approuvé aux destinataires vérifiés. Ne placez pas d'informations d'identification ou d'informations de domaine sans rapport dans une feuille de travail de lancement simplement pour accélérer l'intégration.
Prouvez l’alignement en utilisant un véritable parcours de campagne
Envoyez un test inoffensif via le même compte, la même sélection d'expéditeur et le même chemin de traitement que la campagne prévue. Utilisez des destinataires externes contrôlés dont les en-têtes complets sont disponibles. Répétez l’opération pour tout itinéraire transactionnel ou de marque sensiblement différent. Enregistrez l'ID du message, l'heure UTC et la référence de campagne ou de test pertinente, sans conserver le contenu inutile du destinataire.
Capturez le From visible, Return-Path , chaque valeur DKIM d= et s= et les résultats du récepteur de confiance. RFC 6376 connecte le domaine de signature DKIM et le sélecteur à la clé de vérification DNS . Vérifiez si une signature passante appartient à un domaine aligné plutôt que de vous fier à un résultat vert générique. S'il existe plusieurs signatures, identifiez celle qui fournit le laissez-passer concerné.
Comparez le domaine d'enveloppe observé avec la configuration de rebond prévue et le domaine From. Enregistrez si SPF a réussi, s'il s'est aligné et si DKIM a fourni l'alignement indépendamment. Conservez-les dans des champs distincts afin qu'une modification ultérieure d'un mécanisme n'efface pas la connaissance de l'autre. Le succès de l'authentification est une preuve nécessaire, mais le contenu, les attentes du destinataire et réputation de l'expéditeur peut encore affecter la livraison.
Préserver les liens de travail et diagnostiquer de manière précise
Si le déploiement modifie également un domaine de lien, inventoriez les anciennes dépendances de campagne avant de supprimer tout paramètre précédent. Le guide DNS de Sailthru prévient que la suppression d'un ancien domaine de lien peut rompre les liens dans les messages plus anciens. Le nettoyage de l'authentification doit donc être limité aux enregistrements dont le retrait a été approuvé, et non à une purge à grande échelle de tous les noms inconnus liés à Sailthru.
Pour DKIM absents, vérifiez d'abord l'activation du fournisseur et le domaine de l'expéditeur choisi. En cas d'échec de la signature, vérifiez le sélecteur réel, la réponse DNS et toute modification ultérieure du message. En cas d'échec DMARC avec un mécanisme de passage, inspectez l'alignement et le maintien de la compatibilité en mode strict. Pour les courriers qui n'ont jamais été envoyés, inspectez les preuves du compte et de la campagne avant de supposer que DNS est à l'origine du problème.
Gardez la décision de rampe avec le propriétaire de la délivrabilité. Un nouvel expéditeur techniquement authentifié a toujours besoin du plan de volume et de cadence convenu. Ne libérez pas une audience entière parce qu’un test réussit. Enregistrez les preuves de test, les exceptions ouvertes et la correspondance du fournisseur afin que la décision de production puisse être révisée.
Feuille de travail de lancement de Sailthru
- Compte, marque, flux de travail et domaine prévu : ____.
- Propriétaire de l'entreprise, administrateur DNS et contact du fournisseur : ____.
- Politique DMARC existante et décision de compatibilité en mode strict : ____.
- Examen de la politique SPF et évaluation des recherches imbriquées : ____.
- Les deux ont émis des CNAME DKIM et des résultats de recherche publics : ____.
- Configuration du domaine de rebond et Return-Path observé : ____.
- Activation du fournisseur et vérification de l'adresse de l'expéditeur : ____.
- Surveillance des approbations d'accès et de toute modification distincte du domaine de lien : ____.
- Test Message-ID, résultats fiables et mécanisme aligné : ____.
- Plan de rampe, exceptions non résolues et approbateur de version : ____.
Exemple fictif d'une décision de lancement prématurée
Cas écrit fictif uniquement : ST-01 suppose From offers@news.example.org , une politique existante exigeant adkim=s, et des enregistrements DNS sur un expéditeur dormant. Il n’existe aucune exception de compatibilité du fournisseur, aucun plan de rampe actuel ou aucun résultat de message reçu. Le propriétaire du lancement doit résoudre l'incompatibilité documentée en mode strict avec le propriétaire et le fournisseur de sécurité avant la planification du volume, sans modifier silencieusement la stratégie. La présence DNS ne ferme aucune des portes. Aucun domaine, compte ou campagne n'a été inspecté.
Gardez la portée non prise en charge et les portes de libération visibles
Le déploiement avec alignement strict reste en dehors de la configuration prise en charge par ce guide, à moins que Sailthru ne fournisse une résolution actuellement prise en charge. L'examen en direct des locataires, les enregistrements émis par le compte, la vérification DNS et des en-têtes, l'examen visuel et l'approbation humaine de la PME restent en attente. Il s'agit d'une ébauche de mise en œuvre non publiée et non d'un lancement de domaine terminé.
Séparez un message qui passe de la préparation à l'application
RFC 9989 La section 7.4 nécessite DKIM valide pour une publication de domaine p=reject et met en garde contre 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.