Inventaire des domaines par serveur et application
L'authentification SocketLabs doit être revue pour le serveur ou le sous-compte qui envoie réellement le message. Commencez par une liste d'applications, visibles à partir des domaines et de la configuration SocketLabs utilisée par chaque application. Incluez des sous-domaines distincts, des marques client et des itinéraires de secours. Une seule marque fonctionnelle ne constitue pas une preuve suffisante pour un serveur qui envoie au nom de plusieurs organisations.
Le fournisseur exige des domaines d'envoi vérifiés et documente une erreur lorsqu'une adresse n'est pas autorisée. Il prend en charge la vérification de la propriété via un processus de confirmation d'adresse ou des fonctionnalités d'authentification DNS éligibles, tout en notant que la configuration et le plan du compte affectent l'application des contrôles du domaine d'envoi. Domaines d'envoi SocketLabs, ajout et vérification d'un domaine d'envoi.
Autorisation distincte de soumission de l’authentification chez le destinataire. Un domaine peut être autorisé à envoyer sans le domaine client souhaité DKIM ou l'identité de l'enveloppe utilisée. Enregistrez-les en tant que contrôles indépendants et obtenez l'autorisation du propriétaire du domaine avant d'autoriser l'identité d'un client ou d'un partenaire.
Choisissez la méthode DKIM avec le propriétaire de la clé
SocketLabs documente trois méthodes : une clé TXT fournie par le client, une clé TXT générée par le fournisseur et une clé TXT gérée par le fournisseur. CNAME. Le choix change qui gère les clés et comment elles sont conservées sur les serveurs. Son aperçu actuel indique que la signature nécessite une correspondance avec l'identité From. Présentation de SocketLabs DKIM , les trois méthodes de signature.
Enregistrez la décision avant le début des travaux DNS . Pour une méthode gérée par le fournisseur, identifiez qui peut modifier la configuration de signature. Pour une méthode contrôlée par le client, identifiez le dépositaire de la clé privée et le processus de rotation approuvé. Une feuille de calcul remplie de clés ne constitue pas un enregistrement de propriété acceptable. La feuille de travail doit contenir une référence de preuve et une personne responsable, et non des documents secrets.
Ne choisissez pas automatiquement la méthode la plus complexe car elle expose davantage de contrôles. Préférer l'approche accompagnée qui répond aux exigences de l'organisation et qui peut être maintenue par ses opérateurs réels. Si la politique nécessite un arrangement particulier de gestion des clés ou une identité de signature inhabituelle, obtenez la confirmation du fournisseur avant de présenter la configuration comme prise en charge.
Configurer la méthode de signature sélectionnée
Pour la signature CNAME , le guide officiel décrit un enregistrement DNS délégué et une vérification côté compte avant d'activer la fonctionnalité. Le guide CNAME répertorie dkim. _domainkey sous le domaine d'envoi pointant vers dkim._domainkey.email-od.com . Comparez cette paire documentée publiquement avec les instructions du compte courant ; n'écrasez pas un poste occupé sélecteur simplement parce que l'exemple correspond à son nom. Si l'hôte DNS ne peut pas prendre en charge le trait de soulignement requis dans le propriétaire CNAME , le guide oriente les utilisateurs vers l'approche TXT plutôt que vers une orthographe inventée. Guide de signature SocketLabs CNAME.
Vérifiez si le propriétaire du sélecteur prévu est déjà utilisé par un autre service. Un CNAME ne peut pas être collé en toute sécurité sur un sélecteur non lié. Demandez plutôt une alternative prise en charge ou une migration approuvée. Conservez l'enregistrement existant, ses services dépendants et la décision de modification dans le ticket d'implémentation.
Le guide TXT fait la distinction entre la génération de clés dans la plateforme et l'apport d'une paire de clés. Il nécessite la clé publique dans DNS et vérifie cette clé avant d'enregistrer les paramètres pertinents. Le flux de clé générée conserve son composant privé dans le compte. Guide de signature SocketLabs TXT.
Utilisez un workflow de gestion des secrets approuvé si la méthode sélectionnée implique l’importation de matériel privé. Publiez uniquement la clé publique. Enregistrez le domaine et le sélecteur exacts et inspectez la valeur TXT logique résultante après toute division de chaîne de l'éditeur DNS. Le guide des clés générées indique que la clé publique n'est plus disponible sur le portail après une publication et un enregistrement DNS réussis. Conservez l'enregistrement public et sa provenance avant de fermer le ticket d'installation, sans conserver la clé privée dans le lot de révision.
Configurer le domaine de rebond en tant que mappage distinct
SocketLabs implémente le domaine client SPF grâce à son modèle de domaine de rebond personnalisé sans nécessiter d'ajout au visible-From existant Enregistrement SPF. Son guide spécifie un CNAME du sous-domaine de rebond sélectionné vers tracking.socketlabs.com . Plusieurs entrées de rebond peuvent être configurées ; le courrier sans correspondance utilise la valeur par défaut sélectionnée ou la solution de secours du fournisseur. Guide de rebond personnalisé SocketLabs, configuration et plusieurs domaines de rebond personnalisés.
Choisissez un nom inutilisé avec l'administrateur DNS et confirmez le mappage pris en charge sur le serveur actuel. Conservez intacte la configuration de messagerie entrante ordinaire du domaine. Un nom d'hôte de rebond est une identité de livraison d'application et ne doit pas être confondu avec la boîte aux lettres de réponse d'un utilisateur ou le point de terminaison de suivi du site Web.
Enregistrez la correspondance prévue pour chaque domaine From, puis enregistrez le comportement par défaut. Les valeurs par défaut méritent un examen commercial explicite sur un serveur multimarque : une livraison réussie peut toujours révéler une identité de marque ou de fournisseur inattendue. Ne déduisez pas le mappage actif à partir des seuls noms de la configuration. L'émis Return-Path est la preuve à comparer plus tard.
Publier et comparer les archives publiques
Exportez les enregistrements DNS pertinents avant d’effectuer la modification approuvée. Confirmez le service faisant autorité et la gestion des noms relatifs par l'éditeur DNS . Inspectez chaque propriétaire publié indépendamment, y compris sa chaîne CNAME ou sa réponse TXT . Un enregistrement DKIM correct ne prouve pas que le nom du rebond est configuré, et un enregistrement de rebond correct ne prouve pas que la signature DKIM est active.
SPF est évalué à l’aide de l’identité de l’enveloppe SMTP , et pas simplement du visible From. Si un autre service a encore besoin de la stratégie SPF du domaine racine, conservez-la. Chez tout propriétaire où une stratégie SPF est requise, maintenez une stratégie et vérifiez la limite de durée des requêtes DNS du protocole. RFC 7208 , sections 2.4, 4.5 et 4.6.4.
Attendez des réponses cohérentes, faisant autorité et récursives lorsque les caches sont impliqués. Si le fournisseur ne peut pas vérifier un enregistrement, enregistrez la valeur émise et les observations DNS chronométrées pour la prise en charge plutôt que de modifier le nom à plusieurs reprises. Une limitation d’hôte DNS doit être gérée via une méthode prise en charge documentée.
Testez chaque correspondance exacte du domaine et du rebond
Envoyez du contenu inoffensif via chaque application matérielle et serveur à des destinataires externes contrôlés. Conservez l’heure, l’ID du message et la référence de l’événement du fournisseur ou de l’application. Testez les sous-domaines séparément plutôt que de supposer qu'une entrée pour le domaine parent les couvre.
L'ancienne page CNAME mentionne PRA et Sender dans sa description d'applicabilité, tandis que la présentation actuelle et la page TXT décrivent une correspondance exacte From. Si l'application utilise un en-tête d'expéditeur distinct ou une autre identité inhabituelle, obtenez des éclaircissements et testez ce formulaire exact. Ne traduisez pas silencieusement ces différentes déclarations en une règle universelle.
Chez le destinataire, enregistrez le From visible, Return-Path , l'identité et le résultat SPF de confiance, tous les d et s DKIM , ainsi que le DMARC résultat. La vérification DKIM utilise le domaine et le sélecteur dans la signature réelle pour localiser la clé publique. RFC 6376 , sections 3.5 et 6.1.
Comparez chaque identité de passage avec le De visible sous le alignement mode. Un sous-domaine de rebond personnalisé peut répondre à un alignement SPF détendu sans respecter une égalité stricte. Un passage aligné Signature DKIM peut satisfaire indépendamment DMARC . Ni une vérification de domaine réussie ni une authentification de domaine du fournisseur ne suffisent pour déduire le résultat complet. RFC 9989 , alignement des identifiants expliqué et évaluation DMARC.
Diagnostiquer la couche défaillante
Pour une erreur d'expéditeur non autorisé, inspectez la vérification et les contrôles de domaine du serveur correct avant de modifier les clés DNS . Pour un domaine de signature inattendu, comparez le De exact avec l’entrée DKIM configurée. Pour un Return-Path inattendu, inspectez la correspondance de rebond et la valeur par défaut. Gardez ces contrôles séparés afin qu’une réparation sur l’un ne cache pas un problème sur un autre.
Si la vérification cryptographique échoue malgré DNS correct, étudiez les modifications apportées au contenu signé ou aux en-têtes le long du chemin. Si l'authentification et l'alignement réussissent mais que le placement dans la boîte de réception est médiocre, étudiez le filtrage du destinataire, sa réputation et l'objectif du message. L'authentification ne garantit pas la livraison et ne rend pas légitime toute utilisation d'un compte autorisé.
Récupération d'enregistrement avant la sortie
Remplissez la feuille de travail du domaine et du serveur SocketLabs (créez un enregistrement de révision distinct avec les champs décrits ici). Conservez une matrice route par route de l'autorisation, de la méthode de signature, de la cartographie des rebonds et des preuves reçues. Identifiez qui peut suspendre l'application ou restaurer une configuration de serveur précédemment approuvée si les tests échouent.
Ne supprimez pas les anciennes clés publiques ni les enregistrements renvoyés lorsque les messages en file d'attente ou d'autres serveurs en dépendent. Planifiez le retrait avec le propriétaire de l'application et testez à nouveau après les modifications apportées au domaine From, au serveur, à la méthode de clé, au rebond par défaut ou au fournisseur DNS .
Cas de diagnostic fictif impliquant une entrée de rebond par défaut
Cas écrit fictif uniquement : SOCK-01 suppose qu'un serveur envoie From news@alpha.example avec l'enveloppe bounces.alpha.example et un résultat SPF réussi. Une deuxième route utilise From news@beta.example mais revient à bounces.alpha.example , également avec pass SPF . Dans le cadre d'un alignement détendu, la première enveloppe stipulée s'aligne ; le second ne le fait pas. Les deux résultats DKIM sont inconnus, donc ni un échec complet du deuxième message ni une réparation réussie ne sont revendiqués. Le propriétaire du serveur doit approuver et vérifier le mappage de la version bêta, puis inspecter son Return-Path et DKIM émis. Aucun test de serveur, DNS ou message n'a été effectué.
L'acceptation reste en attente
Acceptez l'itinéraire lorsque le serveur prévu autorise le domaine, la méthode de signature sélectionnée vérifie, chaque mappage de rebond se comporte comme approuvé et la preuve du récepteur établit la passe alignée requise. L'acceptation de la portée originale, les vérifications en direct des locataires et DNS , l'examen technique indépendant, l'examen visuel et l'approbation humaine de la PME restent en attente pour ce projet non publié.
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.