Identifiez d'abord Netcore CE ou Netcore Email API
Un label de compte Netcore ne suffit pas pour choisir une recette DNS . Netcore publie des instructions de configuration de domaine distinctes pour sa plateforme d'engagement client (CE) et son API de messagerie. La page de connexion du produit identifie Email API comme anciennement Pepipost. Enregistrez quel produit, locataire ou sous-compte envoie le message et si l'application utilise SMTP , une intégration API ou une campagne CE. N'appliquez pas un ancien article Pepipost sur un écran CE simplement parce que les deux portent le nom Netcore. Connexion au produit Netcore, Configuration du domaine CE, Vérification de l'API de messagerie.
Inventoriez les flux réels destinés aux clients avant d’ajouter un domaine d’envoi. Un reçu, un lien de connexion et une campagne marketing peuvent avoir des propriétaires d'application et des domaines d'origine différents. Pour chacun, conservez un message de référence ou un échec de soumission, l'expéditeur configuré, l'état actuel du domaine et qui contrôle DNS faisant autorité. Les étapes ci-dessous décrivent les branches documentées ; les noms d'hôtes et les valeurs générés par le compte ont priorité sur les exemples.
API de messagerie : séparer la vérification DNS de l'approbation
Le guide de configuration de l'API Email retenu décrit la publication du tableau de bord fourni SPF TXT et unique DKIM Enregistrement TXT, puis en utilisant Vérifier les enregistrements DNS . Si une stratégie existe déjà chez le propriétaire SPF , fusionnez l'autorisation requise dans cette stratégie plutôt que d'ajouter un autre candidat Enregistrement SPF. Ne collez pas un exemple complet de stratégie sur les autorisations d’autres expéditeurs légitimes. Après la vérification DNS , le domaine entre dans un processus d'approbation qui peut inclure des vérifications automatisées et un examen manuel. Un enregistrement DNS vérifié n’établit pas en soi que le domaine est approuvé pour l’envoi. Vérification et approbation du domaine de l'API de messagerie.
Conservez les deux résultats dans des champs de feuille de calcul distincts. Si DNS est correct mais que l'approbation reste en attente, examinez l'état d'examen du compte et les informations commerciales demandées. Des modifications DNS répétées peuvent masquer une configuration fonctionnelle sans traiter l'approbation. À l’inverse, un compte actif ne prouve pas que le domaine ou le sous-compte spécifique de l’expéditeur est prêt.
Le guide explicatif de Netcore décrit également une valeur SPF révisée que l'opérateur doit publier lorsqu'une politique existante est détectée. Comparez cette valeur proposée avec l'enregistrement faisant autorité actuel : une autre équipe a peut-être modifié DNS depuis la première lecture du tableau de bord. Conservez les autorisations intentionnelles et évaluez le chemin de recherche complet. Pour DKIM , utilisez le nom d'hôte et la valeur associés au domaine sélectionné. Des sélecteurs séparés peuvent servir différents services, mais des valeurs contradictoires sur un seul sélecteur ne sont pas résolus en empilant des clés arbitraires. Explication de l'API de messagerie SPF et DKIM, Règles de traitement SPF.
CE : vérifiez chaque ligne DNS générée
La documentation CE spécifie Paramètres → Domaine de messagerie → Ajouter un domaine. Après avoir entré le domaine, l'écran de configuration DNS fournit l'objectif, le type, le nom d'hôte, la valeur et l'état de chaque enregistrement. Les types d'enregistrement peuvent inclure TXT , CNAME et MX ; copiez les lignes réellement fournies pour le locataire plutôt que d'imposer le modèle à deux TXT de l'API Email. Le guide indique que tous les enregistrements générés doivent être configurés et vérifiés. Utilisez Verify, puis terminez le flux en cas de succès. CE Ajouter un domaine de messagerie.
Le même guide CE distingue Succès, En attente, Erreur et Migré. En attente et Erreur ne permettent pas l'envoi. Il avertit également que la modification d'un nom d'hôte après vérification rend le domaine inactif et nécessite une revérification de tous les enregistrements. Traitez les modifications du nom d'hôte comme un changement contrôlé avec un risque d'interruption. La disponibilité des paramètres DNS de téléchargement est utile pour un transfert de preuves ; cela ne constitue pas une preuve que les enregistrements ont été publiés ou qu'un destinataire a authentifié un message.
Ne redirigez pas les flux entrants ordinaires de l'organisation Enregistrements MX simplement parce qu'une ligne générée utilise MX . Identifiez d’abord le propriétaire exact et le but indiqué par le locataire. Un sous-domaine d'envoi ou de rebond peut avoir sa propre configuration DNS . Le texte public examiné ne justifie pas un nom d'hôte CE universel, une cible MX ou un sélecteur DKIM .
Enveloppe personnalisée : la publication et l'activation sont des étapes différentes
L'API Netcore Email documente séparément une coutume Return-Path processus. Il décrit le choix d'un sous-domaine, la publication du mappage CNAME fourni et la demande à l'équipe de livraison d'activer l'enveloppe/ Return-Path personnalisé et DKIM pour le compte. Ce processus documenté signifie qu'un CNAME publié à lui seul ne constitue pas une preuve que les messages ont changé d'identité. Confirmez les instructions actuelles du locataire et l’état d’activation avant de compter sur cette option. L'article conserve le nom de l'ère Pepipost, il ne faut donc pas généraliser sa cible ou son processus de support au CE. Return-Path personnalisé de l'API de messagerie.
Décidez pourquoi l’enveloppe personnalisée est nécessaire. Il peut fournir un chemin SPF aligné uniquement si le domaine d'enveloppe réel répond au domaine From. alignement exigence et SPF passe. Un sous-domaine associé peut répondre à un alignement détendu, tandis qu'un alignement strict nécessite une égalité exacte des domaines. Une démarche vérifiée, alignée Signature DKIM peut déjà fournir le DMARC chemin. Ne supprimez pas les enregistrements DNS requis par le fournisseur simplement parce que DMARC n'a besoin que d'un seul mécanisme de transmission aligné. Règles d'alignement DMARC.
Remplissez la feuille de travail Netcore spécifique au produit
Utilisez une copie par locataire/sous-compte et domaine d'envoi. Copiez chaque ligne DNS générée dans une entrée numérotée distincte plutôt que de regrouper plusieurs objectifs en un seul.
- Produit : CE / API de courrier électronique. Locataire/sous-compte : ______. Candidature ou campagne : ______.
- Destiné à partir du domaine : ______. Expéditeur actuellement configuré : ______. Autorité et opérateur DNS : ______.
- Numéro de ligne généré : ______. But: ______. Propriétaire: ______. Taper: ______. Preuve de valeur exacte : ______. Résultat faisant autorité et heure UTC : ______.
- Autorisations SPF existantes conservées : ______. Évaluation complète de la recherche DNS : ______.
- État DNS du domaine : ______. État d'approbation de l'API, le cas échéant : ______. Date de la preuve : ______.
- Changement de nom d'hôte CE prévu ? ______. Propriétaire de revérification et d'interruption : ______.
- Enveloppe personnalisée demandée ? ______. Propriétaire publié : ______. Confirmation d'activation du fournisseur : ______. Identité de l'enveloppe reçue : ______.
- Flux de travail de test et ID du message : ______. Du domaine : ______. Domaine/résultat SPF : ______. Chaque DKIM
d=/s=/ résultat: ______. - Résultat DMARC du récepteur : ______. Mode d'alignement et chemin de dépassement : ______.
- Vérification de la gestion des rebonds : ______. Itinéraire de restauration : ______. Approbateur de la version : ______.
Règle de diagnostic : l'absence de données faisant autorité est un problème de publication ; une approbation d'API en attente est un problème d'approbation de service ; une enveloppe différente après publication est un problème d'activation ou de routage. Attribuez l'échec au bon propriétaire avant d'effectuer une autre modification.
Diagnostic travaillé fictif : DNS vérifié, ancienne enveloppe
Exemple de formation fictif, pas un résultat de test Netcore. Une application envoie des reçus depuis receipts.example. Son propriétaire a publié l'enregistrement DKIM du compte et demandé une enveloppe personnalisée à bounce.receipts.example. Le message reçu utilise toujours une enveloppe de service indépendante, mais DKIM passe avec d=receipts.example. Le récepteur de confiance signale la réussite DMARC .
La feuille de travail explique les deux résultats : DKIM fournit le chemin de dépassement aligné ; le basculement sur enveloppe personnalisée n’a pas encore fait ses preuves. L'administrateur vérifie si l'activation du fournisseur a eu lieu et si l'application utilise le locataire prévu. Ajout de plus d'autorisations SPF à receipts.example ne modifierait pas l’enveloppe appartenant au service dans ce message. Une fois l'activation confirmée, un nouveau reçu doit montrer l'enveloppe attendue et la gestion réussie du rebond.
Dans un deuxième cas CE fictif, un nom d'hôte vérifié est modifié lors du lancement d'une campagne et le domaine devient inactif. La réponse correcte consiste à effectuer la re-vérification requise et à maintenir l'envoi en pause jusqu'à ce que CE le permette. Un ticket d’approbation de l’API de courrier électronique concernerait le mauvais flux de travail du produit.
Acceptation et récupération
Interrogez les propriétaires d'enregistrements exacts auprès DNS faisant autorité, puis comparez les résultats récursifs avec les horodatages. Inspectez les signatures reçues ainsi que le tableau de bord. Une clé DKIM publiée prouve la disponibilité, et non que l'application a utilisé cette clé ; une soumission réussie d'API prouve l'acceptation par un service, et non le placement dans la boîte de réception. Utilisez une transaction et un destinataire contrôlés, sans véritables jetons de réinitialisation ni données client dans le lot d'avis. Vérification DKIM.
Enregistrez les paramètres DNS et d'application avant modification. Si la nouvelle route échoue, mettez en pause l'expéditeur concerné, restaurez uniquement la configuration modifiée et testez un nouveau message. Vérifiez les envois en file d'attente avant de changer de transport pour éviter les doublons. Gardez les domaines et les campagnes non liés en dehors du changement.
Aucun locataire Netcore en direct, changement DNS ou message reçu n'a été testé pour ce manuscrit. Les feuilles de travail et les exemples sont du matériel de préparation. L'applicabilité actuelle du produit/locataire, les preuves d'activation et d'approbation, DNS faisant autorité, les tests de messages en direct, l'examen visuel et l'approbation humaine de la PME restent requis avant la publication.