Sélectionnez d'abord la livraison intégrée ou SMTP personnalisé
La documentation d'authentification des e-mails de Customer.io distingue son service de livraison intégré du SMTP personnalisé. Pour la livraison intégrée, cela nécessite une authentification de domaine à l'aide de SPF et DKIM. Pour SMTP personnalisé, la responsabilité de l'authentification est transférée au fournisseur SMTP plutôt que d'exiger la même configuration d'authentification de domaine dans Customer.io. Il s'agit de la première décision du plan de configuration.
Enregistrez l'espace de travail, l'itinéraire de livraison, le domaine prévu et les catégories de messages. Identifiez si une migration ou une exception amène certains messages à utiliser un autre transport. Une seule application peut orchestrer plusieurs chemins de livraison, de sorte qu'un domaine d'envoi vérifié dans un chemin ne constitue pas une preuve de chaque message déclenché par cette application.
Ce guide décrit le flux de travail intégré documenté et les limites du SMTP personnalisé. Il n'affirme pas qu'un espace de travail Customer.io particulier est configuré, que des informations d'identification ont été saisies ou qu'un destinataire a reçu un message test. L’acceptation plus large de la mise en œuvre reste ouverte. Authentification des e-mails Customer.io
Utiliser les enregistrements de sous-domaines générés
Le service intégré fournit des enregistrements d'authentification de domaine liés au domaine d'envoi sélectionné. Customer.io explique que sa configuration utilise un sous-domaine spécifique à Customer.io, illustré par un identifiant cio spécifique au compte, plutôt que de reprendre le domaine racine. Conserver les noms et valeurs de propriétaire réellement générés à partir de l'espace de travail ; l'illustration n'est pas une valeur à copier dans la zone de chaque client.
La documentation sépare explicitement cette configuration SPF de la stratégie SPF du domaine racine. N'ajoutez pas une inclusion Customer.io devinée à l'enregistrement racine simplement parce que c'est là que d'autres services d'envoi ont été configurés. Mappez le sous-domaine généré par le compte et l'objectif de chaque enregistrement avant de soumettre la modification DNS .
L'administrateur DNS doit vérifier la zone faisant autorité, les enregistrements existants et les conventions de l'éditeur pour les noms complets. Examinez l’ensemble complet d’enregistrements proposés, et pas seulement la clé publique qui semble la plus manifestement liée à DKIM . Un plan réussi préserve l’infrastructure de messagerie indépendante tout en établissant les dépendances spécifiques au fournisseur prévues. Nous ne reprendrons pas votre domaine racine ; authentification manuelle
Choisissez un workflow de publication contrôlé
Customer.io documente à la fois une option d'authentification automatique et une publication DNS manuelle. Un assistant automatique peut impliquer l'accès à un fournisseur DNS ; cet accès est une décision de sécurité distincte et non une autorisation implicite accordée en lisant un guide de configuration. Ce manuscrit propose un examen manuel de la modification générée afin que le propriétaire DNS existant puisse approuver et appliquer les enregistrements prévus via des contrôles établis.
Copiez les types d'enregistrement, les noms de propriétaires et les valeurs exactement à partir des instructions du domaine sélectionné. Conservez l'état avant et une référence de changement. Pour les données DKIM TXT longues, distinguez plusieurs chaînes de caractères entre guillemets au sein d'une seule. Enregistrement TXT à partir de plusieurs enregistrements indépendants. Ne tronquez pas une clé pour l'adapter à une limite d'interface supposée et ne publiez pas plusieurs enregistrements de clé contradictoires car un affichage enveloppe le texte.
La cible d'acceptation correcte est les données publiées au nom prévu. Les captures d'écran d'un éditeur DNS peuvent prendre en charge l'historique des modifications, mais elles n'établissent pas par elles-mêmes ce qu'un récepteur externe peut récupérer. Authentifiez votre domaine manuellement ; FAQ sur les fournisseurs DNS; RFC 1035 , section 3.3.14
Réconcilier les paramètres d’alignement DMARC avant l’activation
Les conseils de livraison intégrés de Customer.io nécessitent des paramètres aspf et adkim assouplis pour la configuration documentée. Il note également que l'omission alignement les balises utilisent des valeurs par défaut assouplies. Si le niveau actuel de l'organisation DMARC La politique exige explicitement un alignement strict, traitez cela comme un conflit de conception nécessitant la décision du propriétaire du domaine, et non comme une balise à supprimer avec désinvolture afin de satisfaire une liste de contrôle de produit.
Utilisez la terminologie du protocole avec précaution. L'adresse de l'auteur visible se trouve dans le champ De de la RFC5322 . SPF évalue les identités SMTP , notamment COURRIER DE, tandis que DKIM possède un domaine de signature identifié par d=. DMARC compare l'identité de passage pertinente avec le domaine de l'auteur sous le mode d'alignement applicable. Le chemin de retour et l’adresse De visible ne doivent pas être échangés dans la feuille de calcul des preuves.
Un changement de politique peut affecter d’autres courriers utilisant le même domaine. Tenez compte de l’inventaire des expéditeurs existant, de la conception des sous-domaines et des exigences de sécurité avant de décider comment adapter l’itinéraire. L'exigence du fournisseur ne prouve pas que l'assouplissement de la politique d'une organisation soit autorisé ou approprié dans tous les cas. Détendez vos balises aspf et adkim; RFC 9989 , section 4.4; RFC 7208 , section 2.4
Demander une vérification et séparer le suivi des liens
Une fois les enregistrements requis publiés, utilisez Vérifier le domaine dans Customer.io. La documentation indique que la vérification a lieu sur demande plutôt que via une interrogation continue. Une équipe attendant que l'interface découvre automatiquement un changement peut donc confondre une vérification non demandée avec une panne DNS . Enregistrez l’heure du contrôle et le résultat réel avant d’enquêter davantage.
Le suivi des liens de marque est une autre configuration avec son propre domaine et CNAME exigences de vérification. Ce n’est pas identique à l’authentification de la signature de l’e-mail ou de l’identité de l’enveloppe. De même, SMTP personnalisé peut toujours impliquer une configuration de domaine de suivi distincte, même si le fournisseur SMTP gère l'authentification du courrier. Conservez ces indicateurs d’état dans des lignes distinctes de la feuille de calcul.
Lorsqu'une vérification échoue, comparez d'abord l'espace de travail, le domaine et la liste d'enregistrements générés sélectionnés avec la modification DNS réellement proposée. Ne modifiez pas de manière répétée des enregistrements racine non liés ou ne modifiez pas une politique DMARC simplement parce qu'un statut de suivi est incomplet. Faites remonter le composant spécifique non résolu avec des preuves minimisées. Vérifier le domaine ; SMTP personnalisé et conseils de suivi des liens
Feuille de travail d'acceptation pour un transfert d'espace de travail
Utilisez cette feuille de travail proposée pour éviter que plusieurs indicateurs d’état vert ne soient regroupés en une seule allégation de préparation non étayée.
- Inventaire de transport : répertorie les diffusions intégrées, les exceptions SMTP personnalisées et les messages attribués à chaque itinéraire.
- Domaine d'envoi : conserve l'espace de travail sélectionné, le domaine d'origine et les identifiants de sous-domaines réellement générés.
- Plan DNS : enregistrez chaque propriétaire, type et valeur requis, la zone faisant autorité et la référence d'approbation.
- Décision d'alignement : enregistrez les paramètres aspf/adkim existants et la résolution par le propriétaire du domaine de tout conflit d'alignement strict.
- Vérification du fournisseur : conserve l'heure à laquelle le domaine de vérification a été demandé et le résultat renvoyé.
- Contrôle de suivi : enregistrez séparément si un domaine de suivi de marque est utilisé et quelle vérification s'applique.
- Preuve du message : conservez un échantillon autorisé réduit avec les identités de l'auteur, de l'enveloppe et de la signature ainsi que des résultats de validation fiables.
- Propriété de la version : identifiez qui examinera les modifications d'itinéraire, supprimera les dépendances inutilisées et approuvera la préparation à la production.
Cette feuille de travail est un contrôle proposé original. Aucune de ses lignes n'est complétée par l'existence de ce manuscrit.
Diagnostic fictif : en attente d'un contrôle qui n'a jamais été demandé
Une plateforme éducative fictive publie les enregistrements générés pour son itinéraire Customer.io intégré. L'administrateur vérifie l'interface plusieurs heures plus tard et constate que le domaine n'est toujours pas vérifié. En supposant la racine Enregistrement SPF est faux, un collègue propose d'y ajouter un autre mécanisme. La demande de modification ne contient aucune preuve reliant cette stratégie racine au sous-domaine généré.
L'examinateur confirme à la place que personne n'a sélectionné Vérifier le domaine après la publication. L'étape suivante proposée consiste à demander la vérification documentée, à inspecter son résultat réel, puis à enquêter uniquement sur les enregistrements non résolus. Le suivi de la marque reste une tâche distincte et incomplète, et aucune réclamation n'est faite concernant l'alignement des messages reçus jusqu'à ce qu'un échantillon autorisé soit examiné. Ce diagnostic fictif ne signale pas un événement de compte réel, une requête DNS en direct ou un test réussi.