Un domaine organisationnel est une limite utilisée dans DMARC traitement. Il aide un destinataire à trouver la politique lorsqu'un domaine From visible n'a pas d'enregistrement propre, et il aide à comparer les identités authentifiées de manière détendue. alignement. Ce sont des opérations liées, mais ce n’est pas la même question.
Le raccourci « prendre les deux dernières étiquettes » n’est pas fiable. Un nom sous un suffixe public en plusieurs parties, tel que co.uk , montre déjà pourquoi le fait de compter deux labels peut sélectionner le suffixe plutôt que l'organisation. La spécification actuelle ajoute une raison supplémentaire pour éviter les raccourcis : RFC 9989 définit l'arborescence DNS plutôt que de s'appuyer sur un liste de suffixes publics seul.
Écrivez les trois questions séparément
Commencez par le domaine réel dans l'adresse d'expéditeur du message, appelé domaine de l'auteur. Demandez ensuite :
- Quel enregistrement de stratégie DMARC s'applique à ce domaine d'auteur ?
- Quel domaine organisationnel le processus de découverte applicable établit-il pour chaque identité comparée ?
- Est-ce que le passage SPF ou DKIM l'identité correspond-elle au mode d'alignement sélectionné ?
Un enregistrement valide directement sur le domaine de l'auteur remporte la sélection de la politique. Cela ne prouve pas automatiquement que le domaine auteur est le domaine organisationnel utilisé pour un alignement détendu. Considérez un vérificateur DNS qui affiche un seul champ « domaine » comme une vue de départ et collectez les noms réels et les réponses nécessaires pour expliquer sa conclusion.
Le guide de la chaîne d'identité aide à identifier les domaines From, enveloppe et DKIM avant le début de la découverte.
Suivez un exemple étiqueté
Ce qui suit est un instantané DNS synthétique. Il illustre un registre fictif sous l'espace de noms réservé .example ; il ne s'agit pas d'un résultat de requête en direct ni d'une assertion concernant un véritable suffixe public.
Supposons que le domaine d'auteur existant soit invoice.harbour.registry.example . Son message a un caractère passager Signature DKIM avec d=sign.harbour.registry.example. SPF passe pour un domaine de service distinct qui ne s'aligne pas.
| Cible de la requête | Réponse illustrative | Conséquence |
|---|---|---|
| _dmarc.invoice.harbour.registry.example | Aucun enregistrement de stratégie DMARC | Continuer la découverte |
| _dmarc.harbour.registry.example | v=DMARC1; p=none; sp=quarantine; psd=n | Établissez cette limite organisationnelle explicite et arrêtez la marche |
| _dmarc.registry.example | Non interrogé après l'arrêt | Aucune autre réponse n'est nécessaire pour cette promenade |
La politique sélectionnée est l'enregistrement sur harbour.registry.example . Étant donné que invoice.harbour.registry.example existe et est un sous-domaine, sa politique d'évaluation applicable est la mise en quarantaine via sp. Le domaine organisationnel est harbour.registry.example car l'enregistrement signale explicitement psd=n.
Pour l'identité DKIM , la recherche illustrative sur _dmarc.sign.harbour.registry.example ne renvoie aucun enregistrement, suivi du même enregistrement de limite psd=n . L'identité de signature authentifiée et le domaine d'auteur partagent donc un domaine organisationnel. Avec un alignement DKIM détendu, cette signature DKIM fournit un chemin aligné. Un alignement strict nécessiterait une égalité identitaire exacte, ce que ces deux noms différents n’ont pas.
L’exemple conserve délibérément la sélection de politiques, la découverte des limites, l’authentification et l’alignement visibles en tant que résultats distincts. La modification de la valeur de la stratégie ne transformerait pas les chaînes de domaine inégales en une correspondance exacte.
Comprendre ce qui arrête la marche
La section 4.10 RFC 9989 spécifie les requêtes, le filtrage des enregistrements et les limites. Un enregistrement valide avec psd=n identifie une limite organisationnelle. Un enregistrement valide avec psd=y identifie une limite de suffixe public, les règles de sélection de domaine organisationnel prenant en compte le domaine situé une étiquette en dessous, le cas échéant.
Si aucun des signaux ne résout la limite, la spécification fournit des règles de sélection et de repli. Il limite également la découverte de noms longs pour éviter qu'un attaquant ne force des recherches illimitées. Une implémentation de production a besoin de cet algorithme complet, y compris les enregistrements invalides ou multiples et les erreurs DNS ; retirer les étiquettes jusqu'à ce qu'un nom familier apparaisse ne constitue pas un substitut.
Ne copiez pas psd=y dans le dossier d'une organisation ordinaire. Il décrit un rôle de suffixe. psd=n peut prendre en charge les limites organisationnelles intentionnelles, y compris les sous-arbres délégués, mais doit suivre une décision d'espace de noms documentée plutôt qu'une liste de contrôle universelle.
Étudier les différences entre les outils et les récepteurs
Une implémentation plus ancienne peut utiliser l'approche du suffixe public associée à RFC 7489. Une implémentation plus récente peut suivre l'arborescence RFC 9989 . Les réponses DNS , les caches et la prise en charge de la mise en œuvre peuvent donc avoir de l'importance lorsque les résultats ne sont pas d'accord.
Pour une comparaison utile, conservez les noms d'identité complets, les réponses aux requêtes avec les horodatages, l'enregistrement de stratégie découvert, les paramètres d'alignement et le résultat du récepteur. Demandez au fournisseur de l'outil quel modèle de découverte il implémente. Ne déduisez pas l’adoption universelle d’une date de publication et ne modifiez pas DNS uniquement pour faire correspondre les étiquettes de deux tableaux de bord.
Séparez un véritable désaccord de limite d'un problème d'authentification brut. Une signature DKIM manquante, une signature échouée ou un itinéraire d'envoi non approuvé ne deviendra pas valide car le calcul du domaine organisationnel est corrigé.
Faire de la frontière un enregistrement opérationnel
Pour les domaines comportant plusieurs unités commerciales ou des équipes DNS déléguées, enregistrez qui peut publier sous chaque limite et quels services peuvent y authentifier le courrier. Revisitez cet enregistrement lorsqu'une application gagne un sous-domaine, qu'une unité commerciale modifie la gestion DNS ou qu'un fournisseur est retiré.
Utiliser vérification de la politique de sous-domaine pour vérifier quelle politique s'applique, et la comparaison d'alignement pour décider quelles relations de domaine sont acceptables.
Le résultat utile est une chaîne reproductible : il s'agissait des identités des messages, ces réponses DNS ont établi les limites pertinentes, cette politique s'est appliquée et cette identité de passage s'est alignée ou non. Une étiquette de domaine devinée ne peut pas fournir cette preuve.
Utilisez une carte de décision de limite
Utilisez cette carte pour la sélection de domaines organisationnels, et non pour remplacer la découverte de politiques. Vérifiez d’abord le domaine de l’auteur pour sa propre politique. Une politique directe peut s’appliquer même lorsque l’alignement nécessite un calcul de limite différent.
| Observation pendant la promenade spécifiée | Décision de délimitation |
|---|---|
| Un enregistrement valide contient psd=n | Arrêt; le domaine de cet enregistrement est le domaine organisationnel. |
| Un enregistrement valide contient psd=y loin du domaine de départ | Arrêt; choisissez le domaine une étiquette en dessous de ce suffixe public. |
| psd=y is at the starting domain | La marche s'arrête, mais la règle « une étiquette en dessous » ne s'applique pas à cet enregistrement de départ. Appliquez les règles de sélection, plutôt que d’inventer un domaine enfant. |
| Des enregistrements valides existent sans signal limite décisif | Sélectionnez l'enregistrement valide au nom avec le moins d'étiquettes. Ne sélectionnez pas automatiquement le premier enregistrement d'ancêtre. |
| Aucun domaine organisationnel n'est déterminé | Utilisez le domaine cible initial comme domaine organisationnel. Cette solution de secours ne crée pas d'enregistrement de stratégie. |
| Le nom du sujet comporte de nombreuses étiquettes | Appliquez la limite de huit requêtes : conservez la requête initiale, puis raccourcissez-la comme spécifié. N'interrogez pas tous les ancêtres d'un nom arbitrairement long. |
Ces lignes résument RFC 9989 sections 4.10 à 4.10.2; le filtrage des enregistrements et la gestion des erreurs DNS s'appliquent toujours. Aucune stratégie trouvée lors de la découverte de stratégie signifie que DMARC ne s'applique pas, même si l'algorithme d'alignement dispose d'une limite de repli.
Comme deuxième trace fictive, supposons que la marche pour a.mail.example.com trouve des enregistrements valides sur mail.example.com et example.com , ni avec psd=n ni psd=y, et aucun ailleurs. Le domaine organisationnel sélectionné est example.com . Si mail.example.com signale à la place psd=n, la marche s'arrête là et cette limite plus spécifique l'emporte. Conservez l'instantané DNS avec le résultat afin qu'un autre opérateur puisse reproduire la comparaison.