Traitez le courrier électronique et SMTP comme des tests distincts des paramètres partagés
SendPulse documente une liste de domaines authentifiés partagés pour le courrier électronique et SMTP . L'allocation de domaine applicable est la limite supérieure des deux forfaits, et chaque sous-domaine compte séparément ; un domaine de suivi ne consomme pas cette allocation d'authentification. Son guide actuel donne un exemple de plan gratuit d'un domaine de messagerie et de deux domaines SMTP , permettant deux entrées partagées. Confirmez l'allocation du compte réel avant de planifier plusieurs marques ou sous-domaines. Authentification SendPulse Email, Générez vos enregistrements DKIM et SPF.
Les paramètres partagés réduisent le travail DNS en double, mais ils ne prouvent pas que chaque application sélectionne le domaine From prévu. Campagnes de marketing d'inventaire, automatisations et candidatures soumises via SMTP ou une API. Capturez le compte et le domaine prévu pour chaque itinéraire, le propriétaire de l'entreprise, le propriétaire de l'application et l'administrateur DNS . Conservez les informations d’identification de soumission en dehors de cette feuille de travail.
Ce guide couvre les flux de travail publics d'authentification par courrier électronique et SMTP du fournisseur. Il ne suppose pas une allocation de domaine illimitée, une personnalisation sélectionnable indépendamment Return-Path ou des identités finales identiques à travers chaque intégration. Si une exigence commerciale dépend de règles strictes alignement ou un domaine d'enveloppe particulier, obtenez une conception prise en charge auprès de SendPulse avant de vous y engager.
Rechercher un domaine existant avant de générer des enregistrements
Dans Email, le point d'entrée documenté est Paramètres > Paramètres du domaine, suivi de l'activation dans la zone du domaine authentifié. Dans SMTP , utilisez Paramètres SMTP > Paramètres de domaine et la zone du domaine d'envoi. Les deux flux de travail génèrent SPF et DKIM enregistrements pour le domaine saisi. La documentation SMTP indique que l'authentification de courrier électronique existante ne nécessite pas une autre configuration DKIM car les services partagent les paramètres d'enregistrement. SendPulse SMTP DKIM , paramètres d'enregistrement partagé et ajout d'un nouveau domaine.
Ouvrez d'abord le domaine existant lorsqu'il y en a déjà un. Enregistrez son état de connexion actuel et ses valeurs publiques. Ne générez pas un deuxième arrangement simplement parce qu'une nouvelle application utilise SMTP . Si deux comptes ou équipes revendiquent le même domaine, comparez les instructions actuelles émises par le fournisseur et clarifiez la propriété avant de modifier le domaine partagé. sélecteur.
Comptez les domaines nécessaires au déploiement, y compris les sous-domaines authentifiés séparément. Si le compte est à sa hauteur, ne supprimez pas un domaine fonctionnel simplement pour exposer le contrôle Ajouter. Identifiez ce qui utilise ce domaine et choisissez un plan ou une stratégie de domaine avec le propriétaire du compte. Une décision de droit commercial est distincte d’une défaillance DNS .
Réconcilier l'instruction SPF avec la politique existante
Le guide SendPulse SPF instruit les utilisateurs disposant d'un Enregistrement SPF pour ajouter l'autorisation du fournisseur à cet enregistrement plutôt que d'en créer un deuxième. Les noms des guides cités include:mxsspf.sendpulse.com en tant qu’ajout à une politique existante. Confirmer l'applicabilité par rapport aux paramètres de domaine du compte actuel ; les exemples de termes a et mx ne sont pas des ajouts automatiques. Ne copiez pas un exemple de politique complète sur la politique existante. SendPulse SMTP SPF , copiez un enregistrement SPF et ajoutez une entrée sur le site Web du fournisseur DNS.
Exportez les réponses TXT actuelles pour le propriétaire exact avant de les modifier. Répertoriez les autres services qui dépendent de sa politique SPF et identifiez l'identité réelle de l'enveloppe dans un message de base lorsque cela est possible. Le domaine d’entreprise From et le domaine authentifié SPF peuvent différer. La publication d'une inclusion à un sommet arbitraire ne peut pas réparer un échec évalué ailleurs.
Examinez tous les termes SPF interrogeant DNS, y compris les inclusions imbriquées, par rapport à la limite d'évaluation de dix termes. Un enregistrement DNS qui respecte la contrainte de longueur de l'éditeur peut toujours dépasser la limite d'évaluation du protocole. Conservez les autorisations légitimes et le qualificatif de fin approuvé. N'étendez pas les autorisations avec des exemples de mécanismes a ou mx à moins que le propriétaire du domaine n'ait évalué ce qu'il autorise. RFC 7208 , Sélection des enregistrements et limites de recherche DNS.
Si la demande du fournisseur et la politique existante de l'organisation ne peuvent pas être conciliées en toute sécurité, arrêtez avant la publication. Demandez au propriétaire du courrier d'évaluer un sous-domaine d'envoi pris en charge ou une autre conception appropriée. Gardez l'itinéraire de travail existant disponible pendant que cette décision est prise.
Publier la clé publique du compte auprès du bon propriétaire
Les instructions de SendPulse montrent DKIM comme un Enregistrement TXT et distinguer explicitement la clé publique de démonstration de la propre valeur du compte. Le guide illustre le signe. _domainkey en tant que propriétaire TXT ; récupérez le nom complet actuel et la valeur publique à partir des paramètres du domaine plutôt que de traiter une illustration comme preuve pour chaque compte. Ne réutilisez pas le long exemple de clé dans l’article. SendPulse SMTP DKIM , Copie d'un enregistrement de domaine existant.
Inspectez tout enregistrement existant chez le propriétaire du sélecteur proposé. Une clé préexistante peut prendre en charge un compte, un fournisseur ou un itinéraire opérationnel différent. Demandez une résolution prise en charge plutôt que de la remplacer silencieusement ou d'inventer un nouveau sélecteur que le service n'utilisera pas. La conservation d'une copie du dossier public précédent aide le réviseur à évaluer la récupération, mais n'autorise pas la restauration d'une clé obsolète sans coordonner l'état de la signature.
Utilisez le fournisseur DNS faisant autorité, pas nécessairement le registraire de domaine. Confirmez si l'éditeur attend un hôte relatif ou un nom complet. Après l'enregistrement, interrogez le propriétaire complet et comparez la valeur publique complète avec le résultat du compte. Les chaînes TXT peuvent être affichées sous forme de segments ; comparer leur contenu combiné plutôt que d’insérer des espaces entre les fragments.
Seul le matériel de vérification publique appartient au DNS ou à la feuille de travail de mise en œuvre. Les clés de signature privées, les mots de passe SMTP et les secrets API ne sont pas nécessaires pour une révision DNS . Soutenez le domaine concerné et les preuves publiques sans envoyer d'informations d'identification.
Vérifier l'état de la connexion et la sélection de l'expéditeur
La documentation de courrier électronique utilise Vérifier les enregistrements DNS et modifie une entrée réussie en Connecté. Ses instructions de configuration exigent également que le domaine authentifié corresponde au domaine de l'adresse de l'expéditeur. Authentification SendPulse Email, générez vos enregistrements DKIM et SPF et vérifiez l'état de l'entrée.
Vérifiez l’état applicable dans les vues de service et les horodatages d’enregistrement. Si une équipe voit une liste de domaines différente, vérifiez que les deux équipes se trouvent dans le compte prévu avant de modifier DNS . Ne présumez pas que le statut d’un compte prouve qu’un autre compte est prêt.
Inspectez ensuite l'adresse d'expéditeur configurée dans le flux de travail marketing et dans chaque candidature soumise. Examinez les modèles automatisés et les valeurs par défaut des applications qui peuvent conserver un ancien domaine après une migration. Un expéditeur choisi dans un écran d'aperçu peut différer de l'adresse utilisée par une tâche en arrière-plan. Capturez les paramètres réels du flux de travail de type production testé.
Gardez la configuration du domaine de suivi distincte. Un domaine de suivi de marque est utile pour les liens, mais il ne remplace pas le domaine authentifié sélectionné par l'expéditeur. L'enregistrement d'acceptation ne doit jamais déduire l'alignement DKIM ou SPF à partir d'un nom d'hôte de suivi ou d'un message apparemment de marque.
Prouvez les routes Email et SMTP de manière indépendante
Envoyez des messages inoffensifs via une campagne représentative et une soumission de candidature représentative. Ajoutez d'autres cas pour différents domaines De, remplacements d'application ou arrangements de routage. Utilisez des destinataires externes contrôlés et conservez les en-têtes d’origine, l’ID du message, l’heure de soumission et l’identifiant du flux de travail.
Pour chaque cas, enregistrez le From visible, le domaine authentifié SPF, Return-Path et chaque valeur DKIM d= et s=. Le domaine de signature DKIM et le sélecteur identifient la recherche de clé publique ; une clé valide dans DNS à elle seule ne prouve pas le message réel qui l'a utilisée. RFC 6376 , champ d'en-tête DKIM-Signature et extraction des signatures du message.
Utilisez les résultats du récepteur fiable pour distinguer une passe cryptographique d’une passe alignée. DMARC peut passer par un résultat SPF ou DKIM aligné qualifiant, et le mode d'alignement affecte la comparaison de domaine. Enregistrez quel mécanisme fournit le résultat plutôt que d’écrire uniquement « authentification réussie ». RFC 9989 , alignement des identifiants expliqué et évaluation DMARC.
Si la campagne réussit mais pas l'application, comparez d'abord l'expéditeur, le compte et l'itinéraire réels. Ne faites pas pivoter la clé partagée comme première réponse. Ce changement peut affecter un flux marketing fonctionnel tout en laissant intacte l’adresse d’expéditeur incorrecte de l’application.
Diagnostiquer les problèmes d'enregistrement partagé sans perturber les deux services
En cas d'échec de la vérification DNS , inspectez le propriétaire publié, le type d'enregistrement, la valeur complète et le fournisseur faisant autorité. En cas de signature manquante, confirmez que le test a utilisé le domaine authentifié et le compte SendPulse prévu. En cas d'échec de signature, comparez le sélecteur et la clé observés et vérifiez si une autre passerelle a modifié le contenu signé.
Si SPF réussit mais que DMARC échoue, comparez les identités avant d’ajouter une autorisation. Si la soumission SMTP est rejetée avant la livraison, conservez l'erreur de soumission séparée des résultats d'authentification du destinataire. Un problème d’informations d’identification, de quota ou de format d’application ne peut pas être diagnostiqué à partir d’une seule vérification DNS . Conservez les erreurs exactes sans copier les secrets dans le package de support.
Si une exigence d'enveloppe personnalisée n'est pas satisfaite, obtenez les options prises en charge par SendPulse pour le compte exact. Les instructions examinées n'établissent pas que chaque client peut attribuer n'importe quel domaine Return-Path souhaité. N'inventez pas un MX ou CNAME arrangement pour se rapprocher d’une caractéristique qui n’a pas été confirmée.
Récupération de feuille de calcul et échec de test fictif
Remplissez la feuille de travail de domaine partagé SendPulse (créez un enregistrement de révision distinct avec les champs décrits ici) avec un groupe de lignes par domaine authentifié et une entrée de preuve par e-mail ou itinéraire SMTP . Enregistrez l'allocation du plan, la dépendance du sélecteur existant, le résultat DNS , la configuration de l'expéditeur et le résultat du message reçu. Marquez explicitement les inconnues.
Cas écrit fictif SP-01 : supposez que la campagne From courses@example.org a réussi d=example.org, mais l'application de la leçon est soumise From lessons@old.example avec des résultats DKIM / SPF inconnus. Le statut connecté pour example.org n'établit pas l'authentification de old.example . Le propriétaire de l'application doit confirmer l'expéditeur approuvé, comparer l'inventaire du domaine partagé et tester le parcours de cours sans faire tourner la clé de travail. Aucun compte ou message n'a été consulté et aucune correction ou test n'a été effectué.
Avant une modification, décidez comment suspendre chaque flux concerné et restaurer la dernière configuration d'expéditeur approuvée. Coordonnez tout remplacement de clé avec tous les services qui le partagent. Lors du retrait, arrêtez toutes les applications et campagnes dépendantes avant de supprimer les enregistrements d’authentification. Retestez après des modifications de plan, une migration de compte, des modifications d'hébergement DNS ou de nouvelles routes d'application.
Fermez uniquement la portée testée
L'acceptation nécessite le droit de domaine correct, les enregistrements émis par le compte, DNS public valide, le statut du fournisseur connecté, la sélection de l'expéditeur prévu et la preuve du destinataire fiable pour chaque itinéraire matériel. Une campagne vérifiée ne clôture pas une intégration SMTP non testée. Les vérifications des comptes en direct, DNS et des messages, l'examen technique indépendant, l'examen visuel et l'approbation humaine de la PME restent en attente ; ce projet n'est pas publié et ne revendique pas un déploiement 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.