Campaign Monitor authentifie un domaine d'envoi via la configuration du compte, DNS public et une vérification. Utilisez le domaine exact qui apparaîtra dans l'adresse De, y compris son sous-domaine. Il s'agit d'une configuration spécifique à l'expéditeur : l'authentification de Campaign Monitor n'authentifie pas un autre service qui utilise le même domaine de marque.
Établir l’identité et changer de propriétaire
Confirmez que l'organisation contrôle le domaine prévu et que l'opérateur DNS peut modifier sa zone faisant autorité. Enregistrer l'existant sélecteur, SPF et Enregistrements DMARC. Identifiez les autres expéditeurs légitimes avant d’accepter tout remplacement de politique suggéré. Gardez la personne qui configure les campagnes et la personne qui publie DNS alignées sur le domaine complet, et pas seulement sur une courte étiquette telle que le courrier.
Le guide du domaine d'envoi dit que l'authentification d'un domaine de deuxième niveau n'authentifie pas ses sous-domaines dans la plateforme. Si les campagnes utilisent news.example.com , ajoutez ce domaine exact plutôt que de supposer que example.com couvre le paramètre du compte.
Configurer le domaine et la clé générée
Ouvrez le menu Profil, Paramètres du compte, puis Domaines d'envoi. Choisissez Configurer un domaine d'envoi ou Ajouter un domaine, saisissez le domaine complet et continuez. Publiez le nom et la valeur TXT générés sur DNS faisant autorité, en utilisant la convention de nom complet ou de nom relatif correcte de l'éditeur. Revenez à Campaign Monitor et sélectionnez J'ai ajouté les enregistrements ou Revérifier l'enregistrement si vous revenez plus tard.
Utilisez une clé nouvellement générée pour cette configuration plutôt que d'importer une clé privée existante par commodité. Gardez le matériel de signature privé hors du DNS , des tickets et des feuilles de travail partagées. Si un sélecteur généré entre en collision avec un autre enregistrement actif, résolvez le conflit avant de le remplacer. Les exemples publics ne constituent pas la clé de votre compte.
Préservez DMARC et conciliez soigneusement SPF
Le flux de travail documenté accepte un formulaire valide existant DMARC configuration. Conservez sa politique d'application et ses destinations de reporting, à moins que le propriétaire du domaine n'approuve une modification distincte. Lorsqu’aucune politique ne s’applique, établissez-en une auprès du bon propriétaire. UN p=none Par exemple, il s’agit d’une demande de surveillance, et non d’une application, ni d’une raison pour affaiblir une politique héritée d’un parent.
Campaign Monitor recommande une autorisation SPF facultative à l'aide de include:_spf.createsend.com. Si cette autorisation est appropriée pour votre configuration, fusionnez-la dans la seule stratégie SPF existante plutôt que d'en ajouter une seconde. Conservez les autres expéditeurs légitimes et vérifiez le chemin de dépendance évalué par rapport à la limite de recherche de SPF . Le fournisseur présentation de l'authentification par courrier électronique fournit le contexte, mais l'enveloppe reçue détermine le domaine que le récepteur vérifie réellement.
Un pass SPF pour une enveloppe appartenant à un service n'est pas nécessairement aligné sur votre De visible. Un passage aligné Signature DKIM peut satisfaire DMARC même lorsque ce chemin SPF n'est pas aligné. Ne promettez pas SPF strict alignement simplement parce qu'une inclusion a été ajoutée au domaine From Enregistrement TXT.
Vérifier les enregistrements avant le test de campagne
Interrogez le sélecteur généré sur chaque serveur faisant autorité, puis inspectez les réponses DMARC et SPF applicables. Enregistrez le propriétaire complet, le type, la valeur et l'horodatage. Un éditeur DNS peut diviser une longue valeur TXT en chaînes de caractères au sein d'un seul enregistrement ; ce qui diffère de la publication de plusieurs DKIM enregistrements. Suivez la gestion du fournisseur DNS et comparez la valeur reconstruite.
Si Campaign Monitor ne peut pas vérifier, recherchez un suffixe de domaine en double, un type d'enregistrement incorrect, des caractères clés omis et un désaccord entre le serveur faisant autorité. Le TTL est un contrôle de mise en cache, et non une heure garantie à laquelle chaque validateur se met à jour. Une réponse négative mise en cache peut durer jusqu’au moment où un nouvel enregistrement est créé.
Confirmez que la vraie campagne utilise le domaine prévu
Envoyez une campagne de test contrôlée avec l'adresse d'expéditeur nouvellement authentifiée. Préserver la confiance Authentication-Results, Depuis, Return-Path et toutes les paires DKIM d=/s= . Confirmez qu'une signature transmise s'aligne sur le domaine De sous le mode configuré. Si le test réussit mais qu'une campagne ultérieure échoue, comparez les adresses et les itinéraires des expéditeurs avant de modifier DNS .
Cas illustratif : example.com est configuré, mais une campagne utilise news.example.com , qui n'a jamais été ajouté au compte. Corrigez la configuration du domaine pour l'identité réelle de la campagne ; ne remplacez pas une clé de domaine parent valide pour résoudre la configuration d'une identité différente.
Conserver l’expéditeur en activité jusqu’à son acceptation lorsque cela est possible. Revérifiez après des modifications de compte, de nouveaux sous-domaines d'envoi, des migrations DNS ou une rotation des clés. Avant le retrait, arrêtez les campagnes planifiées et confirmez que les dépendances ne sont plus utilisées. Cet article est un guide documentaire et une proposition de plan de vérification, et non la preuve d'un test Campaign Monitor en direct ou d'une livraison garantie.
Ne confondez pas un écart de portée produit avec un alignement strict
Le cas écrit CM-01 suppose que le produit a configuré example.com mais que la campagne From est news@news.example.com . Stipulez séparément une signature DKIM de transmission de confiance d=example.com, s=demo1. Avec un alignement de domaine organisationnel détendu et ordinaire, cette signature peut s'aligner sur news.example.com ; avec adkim=s cela ne correspond pas exactement. SPF et les autres signatures sont inconnus, de sorte que le verdict global du mode strict n'est pas résolu et ne constitue pas un échec DMARC établi. Aucune des deux prémisses ne prouve que Campaign Monitor a configuré le sous-domaine prévu. Le propriétaire de la campagne doit terminer la configuration exacte du domaine et inspecter la campagne contrôlée qui en résulte avant sa publication. Il s’agit là d’apports fictifs, et non d’une prestation capturée ou d’une raison pour assouplir la politique.
Préserver la limite d’application
RFC 9989 La section 7.4 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.