Déterminer si Openprovider dessert la zone active
Ce guide concerne la publication des enregistrements d'authentification dans Openprovider DNS . Il ne s'agit pas d'un guide de configuration pour les boîtes aux lettres ou les produits de transfert distincts d'Openprovider. Votre domaine peut être enregistré dans Openprovider pendant que Microsoft 365 , un service de campagne ou un autre fournisseur envoie son courrier. L'expéditeur fournit ses instructions d'authentification ; l'opérateur DNS faisant autorité publie les enregistrements approuvés. Gardez ces rôles séparés lors de l’attribution du travail.
Openprovider prend en charge son propre serveurs de noms et des serveurs de noms externes. Son guide de serveur de noms explique que les zones hébergées en externe doivent être configurées auprès du fournisseur DNS externe, tandis que les zones hébergées par Openprovider sont gérées via la gestion DNS et la présentation des zones DNS . Commencez par la délégation publique réelle et la zone exacte en cours de modification. Un domaine enregistré et une zone visible dans le compte ne suffisent pas à établir une autorité. Guide du serveur de noms Openprovider
Ne changez pas de serveur de noms simplement pour créer un SPF éditeur disponible. Il s'agit d'une migration distincte qui peut affecter le site Web, le courrier entrant, les jetons de validation et DNSSEC. Si un fournisseur externe fait autorité, transmettez les modifications d’enregistrement approuvées à l’administrateur de ce fournisseur. Si Openprovider fait autorité, confirmez que vous modifiez la zone active plutôt qu'un modèle destiné à une utilisation future.
Rassemblez les modifications d'enregistrement du service d'envoi
Demander l'autorisation SPF actuelle émise par l'expéditeur, DKIM propriétaires et valeurs, toutes les instructions d'enveloppe personnalisée et le domaine précis auquel chacune s'applique. Évitez un enregistrement universel appelé paramètre Openprovider SPF : un hôte DNS ne devient pas un expéditeur de courrier autorisé simplement en hébergeant la zone. La même distinction s'applique à DKIM . L'article DKIM d'Openprovider indique que le serveur de courrier expéditeur détermine le contenu de l'enregistrement et que le fournisseur ou l'ingénieur système le fournit. Publication DKIM du fournisseur ouvert
Exportez ou conservez d'une autre manière l'intégralité des jeux d'enregistrements concernés, y compris les noms de propriétaires, les types, les durées de vie et les valeurs. Conservez intacts les jetons TXT non liés. Enregistrez chaque action proposée comme ajout, remplacement ou retrait, avec son propriétaire de service et sa raison. UN sélecteur qui semble ancien peut toujours valider le courrier en file d'attente ou prendre en charge une autre application. L'instruction d'un nouveau service n'autorise pas la suppression de la clé de l'ancien service.
Séparez le propriétaire prévu pleinement qualifié de l’entrée de l’éditeur. Pour DKIM , les étiquettes selector et _domainkey sont essentielles ; ils ne sont pas interchangeables avec le sommet du domaine. Pour DMARC, identifiez le propriétaire _dmarc concerné. Pour SPF , identifiez le domaine réel de l'enveloppe SMTP . Le guide des enregistrements DNS récupérés n’établit pas de convention universelle actuelle d’entrée au sommet. Confirmez la gestion actuelle de l'interface du propriétaire racine et les suffixes ajoutés avant d'enregistrer ; ne supposez pas qu'un champ vide ou @ est accepté dans tous les modes de saisie. Conventions d'enregistrement DNS Openprovider
Publiez SPF en tant que stratégie unique avec un formatage TXT vérifié
Le guide SPF d'Openprovider utilise Enregistrements TXT et demande spécifiquement à ses utilisateurs de placer le contenu entre guillemets droits. Suivez la convention de saisie documentée de l'éditeur actuel, puis inspectez la réponse TXT publiée pour vérifier que le formatage a été interprété correctement. Les guillemets bouclés copiés à partir d’un traitement de texte ne sont pas équivalents. N'ajoutez pas de couches de citations à plusieurs reprises lorsqu'un résolveur affiche déjà des chaînes avec des guillemets. Publication SPF du fournisseur ouvert
La sémantique du protocole est le critère d'acceptation. Il devrait y avoir une politique SPF candidate chez le propriétaire évalué. Un enregistrement TXT peut contenir plusieurs chaînes de caractères jointes pour le traitement SPF , de sorte qu'une division d'affichage ne correspond pas nécessairement à plusieurs stratégies. À l’inverse, deux enregistrements distincts commençant par le marqueur de version SPF ne constituent pas un moyen valide d’héberger deux expéditeurs. Préserver les espaces requis et la séquence complète du mécanisme dans la valeur reconstruite. SPF RFC 7208
L'article SPF général du fournisseur contient un langage simplifié sur la longueur TXT , tandis que son guide des enregistrements DNS décrit explicitement la division d'une grande valeur TXT en chaînes plus petites au sein d'un seul enregistrement. La limite de chaînes de caractères ne doit pas être traitée comme une limite totale d'enregistrement. Confirmez le traitement de l'éditeur actuel et vérifiez la réponse reconstruite. Conseils pour les enregistrements TXT Openprovider Si une valeur longue est rejetée, obtenez les conseils du fournisseur ; ne raccourcissez pas une clé publique et ne divisez pas une stratégie SPF en enregistrements indépendants.
Évaluez les limites de recherche récursive de SPF avant d'enregistrer une stratégie fusionnée. Une politique visuellement courte peut toujours dépasser la limite grâce aux politiques incluses. Ne remplacez pas les mécanismes gérés par le fournisseur par un instantané des adresses IP actuelles, à moins que ce modèle de maintenance ne soit délibérément approuvé et pris en charge. Changements d'aplatissement statiques qui doivent suivre les futurs changements d'infrastructure.
Conservez intacts les types d’enregistrements DKIM et la propriété du sélecteur
Certains services d'envoi fournissent une clé publique TXT ; d'autres fournissent un CNAME alias. Publiez le type fourni auprès du propriétaire du sélecteur fourni. Ne placez pas de cible CNAME dans un champ TXT et ne publiez pas la clé au sommet. Le destinataire dérive la recherche à partir du domaine de signature et du sélecteur du message, c'est pourquoi un enregistrement d'apparence plausible chez un autre propriétaire n'aide pas. DKIM RFC 6376
Openprovider documente les erreurs lorsqu'un CNAME partage son propriétaire avec d'autres données d'enregistrement ordinaires. Si l'éditeur signale un doublon ou un conflit CNAME , inspectez l'ensemble d'enregistrements complet de ce propriétaire exact. Ne supprimez pas l'enregistrement TXT en conflit avant d'identifier l'expéditeur qui en est propriétaire. Demandez au nouvel expéditeur un sélecteur non conflictuel pris en charge ou planifiez une rotation contrôlée. Le conflit est une question de propriété de confiance, et pas simplement un problème de validation des entrées. Conseils sur les conflits Openprovider CNAME
Une clé publique ou un enregistrement de délégation n’entraîne pas le début de la signature par le service d’envoi. Effectuez toute activation côté expéditeur séparément et vérifiez la signature sur un message réel. Ne publiez jamais de clés privées, d'informations d'identification API ou de mots de passe SMTP dans la zone ou la feuille de calcul.
Distinguer DMARC manuel de la délégation hébergée
L'intégration EasyDMARC d'Openprovider décrit deux chemins de gestion : une politique hébergée atteinte via un alias CNAME et une politique TXT gérée manuellement. Il avertit que la cible de délégation indiquée dans un exemple n'est pas la valeur à utiliser ; le panneau de contrôle fournit la cible réelle. Il décrit également la création automatique CNAME dans un flux d'achat ou d'activation éligible à l'aide de serveurs de noms Openprovider. Par conséquent, inspectez le propriétaire _dmarc existant avant d'ajouter quoi que ce soit manuellement. Gestion OpenProvider EasyDMARC
Choisissez un modèle de gestion approuvé. Avec une délégation hébergée, la politique opérationnelle peut changer dans le service hébergé sans modification correspondante dans la zone Openprovider. Attribuez un propriétaire à ce service et conservez ses paramètres de stratégie approuvés. Avec TXT manuel, les modifications doivent être reflétées dans la valeur publiée. Évitez de laisser une stratégie TXT et un CNAME chez le même propriétaire, et ne remplacez pas les destinations de reporting existantes simplement pour suivre un assistant d'intégration.
DMARC évalue le domaine From visible par rapport à la transmission d'identités SPF ou DKIM alignées. La publication est une partie de ce processus ; cela ne prouve pas que les expéditeurs du domaine s'alignent. Gardez le comportement du destinataire distinct de la politique demandée et conservez un inventaire des expéditeurs à l’échelle du domaine avant de renforcer l’application. DMARC RFC 9989
Feuille de travail de publication Openprovider réutilisable
Créez une ligne pour chaque propriétaire modifié et conservez un enregistrement de modification partagé pour le domaine.
- Domaine, serveurs de noms faisant autorité et identifiant de zone active : ______.
- Administrateur DNS , administrateur de l'expéditeur et approbateur des modifications : ______.
- Service d'envoi et sa preuve de configuration actuelle : ______.
- Propriétaire pleinement qualifié prévu et entrée de l'hôte éditeur distinct : ______.
- Type d'enregistrement, valeur approuvée complète et TTL : ______.
- Ensemble d'enregistrements antérieurs et dépendances qui doivent survivre : ______.
- Propriétaire de l'enveloppe évalué SPF et vérification récursive de la politique : ______.
- Propriété du sélecteur DKIM , examen des conflits et activation de l'expéditeur : ______.
- DMARC manuel TXT ou choix CNAME hébergé et propriétaire de la politique : ______.
- Réponse après changement faisant autorité et comparaison récursive : ______.
- Référence du message reçu, De, enveloppe, signatures et résultats fiables : ______.
- Étapes de restauration, nouveau test du propriétaire, vérification visuelle et acceptation humaine : en attente.
Diagnostic fictif d'une collision de sélecteur
Cet exemple est fictif. Un revendeur ajoute un nouveau service marketing à un domaine dont DNS est hébergé par Openprovider. Le nouveau service demande un CNAME à un sélecteur détenant déjà une clé TXT pour un expéditeur de facture. Openprovider rejette le changement comme un conflit. Le revendeur propose de supprimer le TXT car le nouveau guide de configuration indique que le sélecteur est obligatoire.
L'enquête sécurisée identifie l'expéditeur de la facture et confirme qu'il signe toujours les messages sortants avec ce sélecteur. La récupération proposée consiste à demander un sélecteur pris en charge différent auprès du service marketing ou à coordonner une transition de clé vérifiée avec les deux propriétaires. Il ne s’agit pas de supprimer aveuglément la clé de facture. Après une modification approuvée, des factures et des messages marketing distincts seraient testés. Aucune zone, expéditeur ou test réussi n'est représenté par ce scénario.
Clôture avec DNS et preuves de message
Interrogez les propriétaires exacts sur les serveurs de noms faisant autorité après avoir enregistré et conservez les réponses. Comparez une réponse récursive séparément, en reconnaissant la mise en cache. Demandez ensuite à chaque expéditeur concerné de produire un message contrôlé pour une boîte aux lettres indépendante et d'enregistrer les résultats du destinataire fiable. Un validateur DNS uniquement ne peut pas confirmer quel sélecteur l'expéditeur utilise réellement ou si son identité de transmission s'aligne.
Si la récupération est nécessaire, restaurez uniquement l'ensemble d'enregistrements précédent concerné et répétez les tests de flux de travail appropriés. Conservez les preuves des paramètres de stratégie hébergée ainsi que des valeurs DNS , car les premières peuvent changer indépendamment. L'accès au compte actuel, les captures d'écran de l'interface, les captures avant et après faisant autorité, les preuves des messages reçus et l'approbation humaine de la PME restent en attente pour ce guide. Aucune modification DNS ni test en direct n'a été effectué.
Gardez les enregistrements publics séparés des opérations cryptographiques
La publication d'une clé publique ne crypte pas le corps de l'e-mail, ne crée pas de signature et n'établit pas que l'ensemble du message est sûr. Utilisez la norme DKIM pour la sémantique de signature plutôt que l'explication de chiffrement simplifiée de l'article du fournisseur. Vérifiez le contenu signé réel et le résultat du destinataire une fois que l'opérateur expéditeur a terminé l'activation.
Séparer l’acceptation des messages du déploiement de la politique
Un résultat SPF aligné peut satisfaire une évaluation de message, mais ne justifie pas à lui seul le déplacement d'un domaine entier vers le rejet. RFC 9989 La section 7.4 nécessite DKIM valide pour la publication de domaines p=reject et met en garde contre l'interopérabilité du courrier indirect. Inventoriez tous les expéditeurs légitimes et les itinéraires indirects avant que le propriétaire de la politique n’approuve l’application. Aucune modification DNS , opération de locataire ou test de message reçu n’a été exécuté pour cet article.