Choisissez l'itinéraire d'envoi Dotdigital avant de toucher DNS
L'authentification Dotdigital doit être limitée au produit exact et à l'identité d'envoi. Ce guide concerne les adresses personnalisées, ou CFA, dans Dotdigital Marketing. Il n'établit pas de paramètres équivalents pour chaque application connectée, un autre produit Dotdigital ou un compte dont l'accès aux fonctionnalités n'a pas été vérifié. Commencez par le flux commercial, l’adresse From proposée et la personne responsable de son domaine.
Le courant du fournisseur conseils sur les domaines de marque décrit les approches déléguées et auto-hébergées par NS. Cela nécessite un nouveau sous-domaine dédié ou domaine similaire et ne prend pas en charge l'utilisation simultanée d'un CFA sur une autre plateforme. Cela fait de la sélection de domaine une décision architecturale et non un changement de nom cosmétique d'une adresse de campagne.
Inventoriez toute utilisation existante avant d’approuver le nom proposé. Demandez s'il contient des messages transactionnels, une gestion des rebonds, des liens de suivi ou une ancienne archive de campagne. Une migration proposée peut affecter bien plus que le message suivant. Gardez le propriétaire de chaque dépendance et les conditions de transition acceptables visibles au lieu de supposer que tous les services utilisant un domaine similaire appartiennent au même flux de travail.
Décidez qui gérera le DNS d’envoi
Créer un CFA inclut l'utilisation d'un sous-domaine détenu, l'achat d'un domaine d'envoi ou l'ajout d'un alias à un domaine d'envoi existant. L'option de sous-domaine documentée nécessite un fournisseur DNS qui permet la délégation nécessaire. Un achat ou des frais de compte constituent une décision d’approbation distincte ; ce manuscrit ne fait ni l'un ni l'autre.
Pour le choix de l'hébergement, conservez l'identité du fournisseur DNSSEC qualification. Sa page de domaine de marque indique qu'un parent utilisant DNSSEC doit utiliser l'approche auto-hébergée plutôt que de déléguer le sous-domaine à Dotdigital Marketing. Ne transformez pas cette contrainte de compatibilité en conseil pour affaiblir la sécurité du parent. Confirmez l'accord prévu par l'organisation avec le propriétaire du domaine et l'étendue réelle du support produit.
Un transfert interne doit spécifier qui conserve chaque enregistrement après la configuration. Une zone déléguée et une zone auto-hébergée ont des responsabilités de changement différentes. Le résultat utile est une délimitation des responsabilités et un contact de rétablissement, et non l’hypothèse selon laquelle un statut vert supprime le besoin d’une future propriété.
Suivez précisément la séquence de vérification auto-hébergée
Pour un CFA auto-hébergé, le guide de vérification nécessite que l'adresse existe d'abord dans Marketing. Le chemin documenté est le menu Compte, Paramètres, E-mail, Adresses d'expédition, puis Vérifier l'adresse choisie. Cette vue fournit les enregistrements DNS du domaine d'envoi. Les valeurs doivent provenir de ce compte plutôt que d’un exemple présenté dans cet article.
Une fois les enregistrements approuvés publiés, le flux de travail documenté revient à Verify et inclut ensuite une étape de confirmation. Lisez l’accusé de réception affiché et obtenez toute approbation requise avant de l’accepter. La source indique que les enregistrements CAA sont facultatifs et exclus de ce contrôle de vérification ; un statut réussi ne doit donc pas être décrit comme une validation DNS exhaustive.
Lorsque la vérification échoue, conservez l’erreur exacte et comparez l’ensemble d’enregistrements attendu avec ce qui est publié. Le fournisseur répertorie parmi ses contrôles les enregistrements manquants, les enregistrements MX ou A supplémentaires et les problèmes de formatage. Ne répondez pas en supprimant tous les enregistrements inconnus. Déterminez d’abord si le domaine d’envoi proposé était véritablement dédié et si un enregistrement inattendu prend en charge une dépendance active.
Distinguer la vérification du fournisseur du courrier aligné
Vérification du fournisseur et du destinataire DMARC L'évaluation répond à différentes questions. Le premier concerne la configuration attendue du service ; la seconde concerne un message réel et ses identités authentifiées. RFC 9989 section 4.4 fournit le alignement cadre. Conserver le domaine From visible, authentifié SPF identité et tout ce qui est pertinent DKIM domaine de signature séparé jusqu'à ce que la relation soit établie.
Un passage Signature DKIM n'identifie pas nécessairement le propriétaire du domaine auteur. RFC 6376 sections 1.2 et 3.5 distinguer les champs d'identité de signataire et de signature. Inspectez les valeurs d et s réelles et le résultat du destinataire de confiance plutôt que de traduire un nom d'affichage de marque en preuve de signature de domaine client.
De même, SPF évalue une identité SMTP plutôt que de simplement lire l'adresse d'expéditeur visible. RFC 7208 section 2.4 explique cette identité. N'ajoutez pas d'autorisation générique au domaine parent uniquement parce que Dotdigital apparaît dans un inventaire. Déterminez l'identité d'enveloppe utilisée par l'itinéraire configuré et suivez les instructions applicables générées par le produit.
Concevoir la vérification du message autour du flux commercial
Le test d'acceptation proposé doit provenir du même workflow marketing que celui qui enverra la véritable campagne. Un message créé manuellement à partir d'un système différent n'établit pas le comportement du CFA. Utilisez un message de test non sensible et une boîte aux lettres de réception approuvée, puis conservez suffisamment de preuves d'en-tête brutes pour reconstruire la comparaison d'identité sans créer de copies inutiles du contenu du message.
Conservez la publication, la vérification du fournisseur, l'authentification des messages, l'alignement et le traitement final sur des lignes distinctes. Pour chaque ligne, enregistrez le résultat attendu, l'observation réelle, l'horodatage et le réviseur. Laissez les observations indisponibles explicitement vides. Un destinataire voyant le nom de la marque ne remplace pas ces vérifications, et un résultat dans la boîte de réception ne constitue pas une promesse concernant toutes les campagnes futures.
Définissez une condition d'arrêt avant de modifier quoi que ce soit : des différences d'identité inexpliquées, une dépendance de domaine conflictuelle ou une erreur de vérification qui ne peut pas être réconciliée avec les enregistrements prévus. Transmettez le problème spécifique au propriétaire responsable. Évitez de résoudre l'incertitude en affaiblissant la politique DMARC plus large de l'organisation ou en déplaçant des services non liés au cours du même changement.
Exercice de sélection de domaine fictif et porte de libération
Lors d'une séance de planification fictive, une équipe propose de réutiliser un sous-domaine déjà attribué au courrier transactionnel. Son examen sélectionne à la place une nouvelle proposition de sous-domaine d'envoi dédié et demande au propriétaire DNS d'évaluer l'arrangement auto-hébergé car le parent est signé. Aucun domaine n'est délégué, aucun enregistrement n'est généré et aucun message n'est envoyé. L'exercice explique la décision, pas son exécution.
Les preuves d'origine demeurent : les preuves actuelles de configuration de première partie de Dotdigital et une table d'identité des messages reçus provenant du produit et de l'itinéraire exacts. La porte de mise en service est la suivante : confirmer l'identité actuelle du produit et la documentation appartenant au fournisseur ; tester un message réel ou des enregistrements publiés. Indiquez honnêtement les fonctionnalités de domaine personnalisé non prises en charge. La documentation actuelle est conservée, tandis que l'applicabilité du compte, les observations originales, l'approbation humaine de la PME, l'examen visuel en direct et l'autorisation de publication restent ouverts.