Portée du modèle de domaine SendPro actuel
Ce guide utilise le flux de travail actuel du centre d'aide Spotler SendPro pour l'entrée de catalogue associée à SendPro et Flowmailer. Cela ne suppose pas que chaque ancienne interface, intégration ou compte expose des contrôles identiques. Enregistrez le compte, l'édition, l'application source et les domaines de l'expéditeur avant de préparer une modification.
Le guide Domaines sépare trois identités : le domaine de l'expéditeur associé à l'adresse de l'auteur, le chemin de retour domaine utilisé pour la gestion des rebonds et le domaine Web utilisé pour le suivi des clics. Une application source détermine généralement l'expéditeur, tandis qu'une étape de flux dédiée peut le modifier. L'examen de la configuration doit donc inclure le flux de traitement plutôt que de supposer que l'adresse d'origine de l'application d'origine reste inchangée.
Aucun compte, identifiant API, flux ou paramètre DNS n'a été consulté ou modifié pour ce manuscrit. Ses exigences de mise en œuvre et d’applicabilité actuelle restent ouvertes. Domaines
Choisissez le chemin de retour et la présentation du suivi avant de copier les enregistrements
Le fournisseur décrit une configuration standard dans laquelle le domaine Web utilise initialement le même nom que le domaine du chemin de retour. Il prend également en charge leur séparation. Dans le scénario de domaine séparé, le guide appelle MX et SPF au domaine du chemin de retour et un domaine distinct CNAME pour le domaine Web. Une source de domaine de boîte de réception introduit une autre dépendance de réception de courrier.
Ces alternatives expliquent pourquoi une capture d'écran de trois alias ne constitue pas une liste d'enregistrements universelle. Obtenez le plan généré pour la mise en page sélectionnée et enregistrez le but de chaque nom de propriétaire. Ne configurez pas un domaine de boîte de réception simplement pour reproduire un exemple et n'écrasez pas le routage de courrier existant lorsqu'un nom dessert déjà un autre système.
Le guide énonce une contrainte d'alignement strict pour sa configuration de chemin de retour. Traitez cela comme une condition de conception spécifique au fournisseur nécessitant une clarification par rapport à la politique réelle du compte. Ne généralisez pas cela en affirmant que le DMARC le protocole interdit toujours les strictes alignement ou supprimez silencieusement les balises strictes d'un domaine partagé. Domaine du chemin de retour ; Différentes configurations
Distinguer Valider et Enregistrer
Le guide Domaines fait une distinction importante entre la prévisualisation et la validation des modifications. Validate vérifie les valeurs d'entrée actuelles et peut afficher les enregistrements qui seraient requis pour les valeurs modifiées sans enregistrer ces modifications. Enregistrer modifie les valeurs de domaine configurées et met à jour les enregistrements et le statut requis.
Le processus opérationnel proposé consiste à préparer et à examiner la mise en page avant d'approuver une modification enregistrée. Enregistrez si une capture d'écran reflète un aperçu ou la configuration validée. Un aperçu montrant les enregistrements attendus n'établit pas que le compte les utilise actuellement. De même, une modification enregistrée ne prouve pas que DNS a déjà été mis à jour.
Le fournisseur prévient que les modifications du domaine de production peuvent affecter les e-mails entrants et sortants. Conservez un état antérieur, identifiez les sources et les flux actifs et convenez d'un propriétaire de restauration. La suppression de domaine a également des conséquences sur le cycle de vie et doit être examinée séparément d'une vérification de statut de routine. Ce manuscrit n'effectue aucune de ces actions. Modification, sauvegarde, validation et suppression de domaines
Lire avec précision les indicateurs du dossier essentiel et DMARC
Le guide de conformité dirige les utilisateurs vers Configuration > Domaines. Pour sa présentation standard illustrée, il décrit trois CNAME : un pour la gestion et le suivi des rebonds, et deux pour DKIM. Utilisez les enregistrements générés par le compte actuel plutôt que de supposer que ces décomptes exacts couvrent toutes les présentations alternatives.
Le guide nécessite un Enregistrement DMARC pour l'envoi, mais distingue une politique valide manquante d'un avertissement indiquant que rua ne contient pas l'adresse de rapport SendPro. Il affirme que cette dernière peut être suffisante, tout en recommandant l'intégration du reporting. Ne considérez pas une recommandation de partage de rapports comme une autorisation automatique d’ajouter un nouveau destinataire de données. Conservez les modalités de reporting existantes à moins que le propriétaire du domaine n'approuve une modification.
Un enregistrement DMARC suggéré est un exemple de politique et non un remplacement obligatoire de la configuration actuelle de l'organisation. Examinez la politique de domaine applicable et les exigences d’alignement avant de l’accepter. Revérifiez le domaine spécifique de l'expéditeur après la publication approuvée ; un domaine réussi n'établit pas tous les autres domaines ou sous-domaines. Conseils de conformité du domaine de l'expéditeur
Gardez SPF et la soumission de la source séparés de l'identité du domaine
Le guide de configuration décrit un élément SPF facultatif pour l'inspection et la visibilité manuelles et les noms include:spf.flowmailer.net. Cette description de l'interface ne doit pas être interprétée comme une autorisation d'ignorer une politique SPF requise par une disposition différente du chemin de retour. Mappez d'abord l'identité pertinente et les enregistrements générés.
La limite d'évaluation de SPF concerne les termes dépendants du DNS, y compris le traitement imbriqué, plutôt que de simplement compter les inclusions saisies dans l'enregistrement visible. Examinez une politique complète au nom du propriétaire concerné et conservez les autres sources légitimes. N'ajoutez pas de deuxième stratégie SPF pour satisfaire un élément isolé du tableau de bord.
SendPro prend également en charge la soumission de sources via API et SMTP , entre autres options. Les informations d'identification de la source autorisent la soumission ; ils ne prouvent pas eux-mêmes l'alignement de domaine sur le message final. Ce guide ne crée ni n’expose ces informations d’identification. L'acceptation proposée doit relier la source choisie, toute étape du flux de changement d'expéditeur et l'identité d'auteur et de signature finale observée. Guide de configuration; RFC 7208 , section 3.2; RFC 7208 , section 4.6.4; RFC 9989 , section 4.4
Feuille de travail d'acceptation pour les propriétaires d'applications et DNS
Utilisez cette feuille de travail originale proposée pour éviter toute confusion entre l'état de l'aperçu, l'autorisation de soumission et l'authentification du message.
- Champ d'application : compte, édition, application source, protocole de soumission et étapes de flux pertinentes.
- Disposition de l'identité : domaine de l'expéditeur, domaine du chemin de retour et domaine Web enregistrés séparément.
- Aperçu des preuves : plan d'enregistrement généré et s'il reflète les entrées non enregistrées ou les paramètres validés.
- Révision DNS : finalité de chaque alias, TXT ou Enregistrement MX, les dépendances existantes et le propriétaire du changement approuvé.
- Décision politique : alignement DMARC applicable, examen SPF et destinataires de rapport autorisés séparément.
- Statut du produit : résultat réel de la validation par domaine et horodatage après la publication approuvée.
- Acceptation du message : échantillon autorisé réduit montrant les identités de l'auteur, de l'enveloppe et de la signature ainsi que les résultats du destinataire de confiance.
- Cycle de vie : dépendances sources actives, plan de restauration et approbation du retrait des domaines inutilisés.
Il s'agit d'une conception de contrôle vierge. Il ne s'agit pas d'une intégration API terminée, d'une inspection DNS , d'une modification de configuration enregistrée ou d'une transmission test.
Diagnostic fictif : un aperçu a été confondu avec un déploiement
Une équipe d'application fictive modifie ses champs de chemin de retour et de domaine Web, sélectionne Valider et transmet la liste d'enregistrements résultante à un réviseur. Une autre équipe suppose que l'aperçu représente la configuration réelle du compte et marque la migration comme terminée. Les paramètres enregistrés décrivent toujours la mise en page précédente.
La correction proposée consiste à distinguer les preuves d'aperçu d'une modification validée approuvée. Les équipes rapprochent la configuration réellement enregistrée, le plan DNS et le flux d'applications pertinent avant de planifier tout déploiement. Ils préservent également les destinataires actuels du rapport DMARC plutôt que de copier chaque champ d'un exemple.
Après une modification dûment autorisée, des preuves au niveau du message seraient toujours requises. L'aperçu à lui seul ne peut pas prouver l'authentification ou la livraison. Cet exemple fictif ne décrit aucune action SendPro exécutée et ne fait aucune allégation concernant un compte réel.