Pourquoi un enregistrement DMARC parent ne remplace pas un inventaire d'expéditeur

Un parent DMARC La politique peut établir comment les destinataires doivent gérer certains courriers de sous-domaines qui échouent à l'authentification. Il ne peut pas vous dire quelle application envoie ce courrier, qui l'a approuvé ou si un service de notification critique fonctionne toujours. Ces questions nécessitent un inventaire des expéditeurs lié aux preuves des messages reçus.

La distinction est importante lors de l’exécution. Une vérification DNS peut montrer une politique de protection au niveau du domaine principal de l'organisation, tandis qu'une ancienne plate-forme de campagne utilise une politique enfant explicite, qu'une filiale contrôle son propre espace de noms ou qu'un service de réinitialisation de mot de passe s'authentifie avec une identité de fournisseur sans rapport. Le dossier et l'inventaire répondent à des questions différentes.

Commencez par le domaine que le destinataire voit

Pour chaque workflow métier, capturez le domaine dans l'adresse De du message. Ne remplacez pas le domaine du site Web, le domaine de connexion du compte ou le nom de marque du fournisseur de messagerie. Identifiez ensuite la politique applicable, l'identité évaluée par SPF et le DKIM signature du ou des domaines.

Dans le cadre de la découverte DMARC actuelle, un enregistrement applicable trouvé spécifiquement pour le domaine de l'auteur a priorité sur le repli vers le domaine d'auteur. domaine organisationnel ou suffixe public. La spécification actuelle utilise un Parcours de l'arborescence DNS. Un parent immédiat ne constitue pas automatiquement la limite organisationnelle applicable. Voir RFC 9989 §4.10.1.

Votre inventaire doit donc enregistrer le domaine de stratégie découvert, et pas seulement une case à cocher intitulée « couvert par le parent ». Enregistrez également le récepteur ou l'évaluateur utilisé et la date du test. Les implémentations plus anciennes peuvent utiliser un comportement de découverte hérité, de sorte qu'un calcul documentaire n'établit pas un déploiement universel.

Comparez trois cas de sous-domaines

Ce qui suit est une illustration synthétique et non une configuration client observée. Supposer example.com est le domaine organisationnel, la découverte sélectionne son enregistrement lorsqu'aucun enregistrement enfant n'existe et son enregistrement contient p=reject; sp=quarantine; np=reject. La balise de version est omise dans cette phrase uniquement pour des raisons de lisibilité ; un véritable bilan politique doit commencer par v=DMARC1.

• Cas de domaine d'auteur : Existant billing.example.com, sans explicite Enregistrement DMARC; Stratégie applicable dans cet exemple : Parent sp=quarantine pour courrier défaillant ; Ce que l'inventaire doit encore établir : quel workflow de facturation envoie, son propriétaire et le résultat d'authentification aligné du message reçu
• Cas du domaine de l'auteur : Inexistant unused.example.com, sans politique explicite ; Stratégie applicable dans cet exemple : Parent np=reject pour courrier défaillant ; Ce que l'inventaire doit encore établir : s'il n'existe réellement pas dans DNS et si un flux de travail légitime l'utilise de manière inattendue
• Cas de domaine d'auteur : Existant news.example.com, avec son propre v=DMARC1; p=none enregistrer; Stratégie applicable dans cet exemple : l'enfant explicite p=none politique; Ce que l’inventaire doit encore établir : à qui appartient cette exception, pourquoi elle existe et quand elle sera réévaluée

Dans les trois cas, une identité alignée de passage peut produire une réussite DMARC . La colonne de stratégie décrit la gestion demandée en cas d'échec, et non une commande permettant de rejeter chaque message du domaine. Les décisions du séquestre restent distinctes sous RFC 9989 §5.4. Le sp et np les règles de sélection sont précisées dans RFC 9989 , section 4.10.1.

Une zone DNS déléguée est un autre élément d'inventaire, et non la preuve d'une politique DMARC explicite. Enregistrez qui le contrôle et testez la découverte à partir de ses domaines d'auteur réels. Ne déduisez pas les limites organisationnelles de l’organigramme de votre entreprise.

Connectez chaque expéditeur à un propriétaire d'entreprise

Créez une ligne par flux de travail d'envoi significatif. Une seule application peut nécessiter des lignes distinctes pour les campagnes, les notifications transactionnelles et les messages déclenchés par les employés si elles utilisent des identités ou des itinéraires différents.

Au minimum, conservez le flux de travail, le propriétaire responsable, le domaine de l'auteur, le domaine de l'enveloppe, le domaine de signature et sélecteur, service d'envoi, politique applicable, dernier test et condition de mise à la retraite. Ajoutez l'emplacement des preuves et tout problème non résolu. Un fournisseur nommé sans compte client ni propriétaire d'entreprise identifié reste un responsable d'enquête et non une autorité d'envoi approuvée.

Utiliser rapports agrégés pour trouver le trafic observé et le comparer avec ce registre. Sous RFC 9990 §3.1 et RFC 9989 §5.3.8, les rapports décrivent le trafic vu par les récepteurs participants ; l’absence d’un rapport ne constitue pas une preuve qu’il n’existe pas de workflow mensuel ou rarement utilisé. Demandez aux propriétaires d'applications d'effectuer délibérément des réinitialisations de mots de passe, des reçus, des alertes et des tâches planifiées.

Modifier la politique par rapport à l'inventaire

Avant de modifier la stratégie parent, identifiez les lignes qui hériteront de la modification et les lignes avec une stratégie enfant indépendante. Attribuez des tests à leurs propriétaires. Un examen sécurisé demande si le courrier légitime reste authentifié et aligné, si les exceptions sont justifiées et si la récupération peut être limitée au flux de travail concerné.

Évitez d'affaiblir la stratégie parent simplement parce que la configuration d'une application est incomplète. Déterminez d’abord si le service peut utiliser un domaine de signature aligné pris en charge. Si une exception est nécessaire, documentez sa portée, son approbateur, son expiration et son plan de vérification. Traitez cela comme une décision de risque explicite plutôt que de cacher discrètement l'expéditeur de l'inventaire.

Après la modification, comparez les nouveaux résultats de message et les rapports avec les lignes antérieures à la modification. Gardez les différences de politique et les preuves ensemble. Fermez le changement uniquement lorsque les propriétaires d'entreprise concernés confirment leurs flux de travail réels et que les expéditeurs non résolus ont une action suivante nommée.

Séparez la couverture de la police et la couverture de l’expéditeur

Un tableau de bord utile comporte deux mesures : les domaines avec une politique applicable vérifiée et les flux de travail d'envoi d'entreprise avec un propriétaire actuel et un itinéraire aligné testé. Améliorer l’un n’améliore pas automatiquement l’autre. Utilisez le guide d'inventaire des expéditeurs pour le registre opérationnel et le guide de politique de sous-domaine pour les détails de la découverte.

Rendre la prochaine décision explicite

Pour l'appareil à trois domaines, facturation de groupe selon la politique sp héritée, inutilisée sous la politique np applicable supposée et nouvelles sous sa politique p explicite. Un changement de sp parent ne doit pas être décrit comme une modification de la politique d'information explicite. Séparez chaque propriétaire de flux de travail et chaque lacune en matière de preuves. Il s’agit d’une conséquence des hypothèses de découverte énoncées, et non d’une promenade dans un arbre vivant ou d’une approbation de changement de politique.