Commencez par le compte Delivra et l'inventaire de domaines
La page d'aide sur l'authentification publique de Delivra renvoie à des informations détaillées Instructions d'authentification par courrier électronique. Ces instructions décrivent un administrateur de site en coordination avec l'opérateur DNS du domaine, un Sélecteur DKIM et la clé pour chaque domaine d'envoi, ainsi qu'une étape distincte d'activation de la signature. Ce guide couvre ce flux de travail documenté. Il n'établit pas l'accès aux fonctionnalités d'un compte particulier, les valeurs générées ou la configuration terminée.
Identifiez chaque domaine destiné aux adresses d'expéditeur de campagne et mappez-le au compte et au site concernés. Plusieurs boîtes aux lettres sous le même domaine ne nécessitent pas automatiquement des clés de domaine distinctes, tandis qu'un domaine différent ne doit pas hériter de la clé d'un autre domaine par hypothèse. Gardez la portée administrative explicite avant de modifier des enregistrements, en particulier si un site dessert plusieurs marques ou unités commerciales gouvernées de manière indépendante.
Les instructions publiques détaillées n’exposent pas de date de publication fiable dans le texte de l’article capturé. L'applicabilité du compte courant et les éventuelles modifications de l'interface restent ouvertes. Utilisez les enregistrements réellement affichés et la confirmation actuelle de l'administrateur lors de la mise en œuvre du plan. Un exemple de sélecteur à partir d’une capture d’écran n’est pas une valeur générée par le compte, et le manuscrit n’a généré aucune clé ni accédé à aucun locataire.
Fusionner l'autorisation SPF documentée
Les instructions précisent include:ne16.com pour un existant SPF politique et offrir un exemple complet pour les domaines qui n’en ont pas. Examinez ce mécanisme dans l'inventaire complet des expéditeurs légitimes du domaine plutôt que de remplacer les autorisations existantes des employés ou des applications. Le terme mx de l'exemple, le qualificatif d'échec logiciel et le TTL ne sont pas des paramètres universels pour chaque domaine. Gardez la différence exacte approuvée visible dans la demande de modification. Instructions d'authentification Delivra
RFC 7208 , section 3.2 interdit plusieurs politiques SPF sélectionnées chez un même propriétaire. Préservez une seule politique TXT cohérente et examinez les termes dépendants du DNS évalués dans la section 4.6.4, y compris le travail imbriqué. Compter uniquement les inclusions visibles ou les paquets DNS observés est insuffisant. Une politique peut être présente et syntaxiquement valide sans autoriser l'expéditeur réel sur un chemin d'évaluation particulier.
Ne considérez pas 255 caractères comme la longueur totale maximale de la stratégie SPF . La section 3.3 décrit plusieurs chaînes de caractères au sein d'une seule Enregistrement TXT et leur concaténation sans espaces ajoutés. Cela diffère de plusieurs concurrents Enregistrements SPF. Lorsqu'un éditeur divise une valeur longue, vérifiez l'enregistrement logique résultant au lieu de supprimer les autorisations simplement pour respecter une limite de présentation. Il s'agit d'une distinction de protocole et non d'une affirmation selon laquelle chaque éditeur DNS prend en charge le même format d'entrée.
Créez la clé de domaine et publiez sa valeur exacte
La voie d'administrateur documentée est Paramètres, Compte, Clés de domaine, puis Créer une clé de domaine. L'administrateur saisit le domaine, sélectionne une taille de clé et enregistre pour obtenir les instructions DNS . Le transfert inclut le nom de domaine, DKIM Adresse d'enregistrement TXT et valeur d'enregistrement DNS TXT . Ceux-ci vont ensemble : une clé correcte chez le mauvais propriétaire ne peut pas prendre en charge la recherche de sélecteur prévue. Instructions d'authentification Delivra
L'opérateur DNS publie un enregistrement TXT en utilisant l'adresse et la valeur émises. Le guide note que de nombreux fournisseurs n'attendent que le sélecteur. _domainkey dans leur champ hôte, mais cela dépend de l'éditeur. Confirmez le propriétaire complet résultant plutôt que de supprimer ou d’ajouter universellement le domaine. Ne réutilisez pas le sélecteur long de la capture d'écran : la source identifie explicitement ces valeurs comme exemples uniques au compte et au domaine d'envoi.
En cas de non-concordance, comparez l'intégralité de la clé publique générée avec la valeur logique publiée, y compris les espaces accidentels, la troncature et les sauts de ligne. Les instructions suggèrent de générer une clé plus petite pour certaines limitations DNS héritées, mais ce guide ne recommande pas la suppression automatique ou la rétrogradation comme première réponse. Établissez la prise en charge actuelle du fournisseur DNS, les exigences clés de l'organisation et l'effet sur la signature active avant d'autoriser un remplacement. Un problème de représentation et une décision de politique cryptographique sont des questions distinctes.
Activer la signature après la publication
L'étape suivante documentée consiste à revenir à Paramètres, Compte, Clés de domaine et à utiliser Activer la signature lorsque la clé est présente et valide dans DNS . Conserver cette étape d'activation dans le plan de réception. Un ticket DNS complété ne constitue pas une preuve que le compte est en train de signer, et la présence du bouton ne constitue pas une preuve de son utilisation. Enregistrez la confirmation réelle de l'administrateur lorsqu'une implémentation autorisée se produit. Instructions d'authentification Delivra
Les mêmes instructions décrivent les indicateurs d'authentification à côté du nom et de l'adresse de l'expéditeur dans le flux de travail de la campagne. Traitez-les comme des contrôles du fournisseur, distincts des résultats d'un destinataire sur un message. Les indicateurs verts sont une preuve utile de l'opinion du compte, mais ils ne prouvent pas chaque itinéraire de campagne, décision du destinataire ou signature future. La source indique également qu'une authentification incomplète n'empêche pas en soi l'envoi ; l'absence de bloc de plateforme n'est donc pas un critère d'acceptation.
Examiner le chemin de retour personnalisé au niveau du site
Delivra guide de chemin de retour personnalisé décrit une configuration à l'échelle du site, et non une option par compte. Il indique que tous les comptes doivent envoyer à partir du même domaine racine pour cet arrangement partagé. L'étape DNS documentée utilise un sous-domaine de rebond CNAME à lists.n-email1.net ; Le support vérifie et configure ensuite le site et envoie un test de confirmation. Il s’agit de conditions préalables et d’étapes du fournisseur, et non d’actions effectuées ici.
Avant d'approuver une modification partagée, enregistrez chaque propriétaire d'entreprise concerné et chaque exception non résolue. Garder la décision en attente lorsque l'inventaire est incomplet.
Une politique de quarantaine ou de rejet n'est pas la même chose qu'une politique stricte alignement des identifiants. RFC 9989 , section 4.4 définit la relation d'alignement indépendamment de la disposition demandée. Un sous-domaine de rebond peut prendre en charge un alignement détendu avec un domaine d'auteur associé sans établir d'égalité exacte pour un alignement strict. Ne promettez pas une compatibilité d'alignement strict ou la suppression de l'affichage « au nom de » de chaque récepteur basé uniquement sur le CNAME documenté.
Évaluez le message plutôt que l’écran de configuration seul
Un exercice d'acceptation autorisé proposé doit utiliser un contenu inoffensif et enregistrer le domaine réel de l'auteur, l'identité de l'enveloppe, le domaine de signature et le sélecteur. RFC 6376 , section 3.5 définit les champs de signature utilisés pour connecter un message reçu à sa clé DNS . Comparez les résultats du destinataire de confiance avec les identités approuvées et l'itinéraire prévu. Ne téléchargez pas d’informations réelles sur les abonnés ou de contenu de campagne confidentiel sur un vérificateur externe sans autorisation.
DMARC peut passer par un résultat SPF passant aligné ou un résultat DKIM passant aligné. Il ne certifie pas que le message est inoffensif et le courrier authentifié peut toujours être filtré. Un exemple de politique publique n'est pas l'autorisation de remplacer la politique d'application de l'organisation ou d'ajouter un destinataire de reporting. Séparez les décisions politiques à l’échelle du domaine et l’approbation du partage de données de la copie des enregistrements DNS publics émis.
Diagnostic fictif et feuille de travail d'acceptation vierge
Un éditeur éducatif fictif, Maple Folio, publie une clé générée mais ne revient jamais à Activer la signature. Son enregistrement de modification DNS semble complet, tandis que la disponibilité des messages reste non prouvée. L'examen révèle également qu'un chemin de retour proposé couvrirait un site partagé avec une deuxième marque. L'équipe sépare l'activation en attente de la décision de conception à l'échelle du site et demande aux propriétaires autorisés de résoudre les deux avant la publication. Ce scénario fictif ne contient aucune action de compte réelle ni résultat de message.
- Site, comptes, domaines d'envoi et applicabilité actuelle du flux de travail : ______
- La politique SPF existante et approuvée inclut la modification : ______
- Propriétaire DKIM unique, clé publique et preuve de publication : ______
- Activer la confirmation de signature et les observations des indicateurs de campagne : ______
- À l'échelle du site chemin de retour compatibilité et complétion du fournisseur, le cas échéant : ______
- Identités réelles des messages, résultats fiables et mode d'alignement : ______
- Titulaire de la police, exceptions non résolues et décision de libération : ______
Les preuves originales de mise en œuvre, l'examen humain, l'applicabilité actuelle, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire restent ouverts. Aucune clé, entrée DNS , demande d'assistance, message de test ou publication n'a été créée.