Identifier l'opération derrière l'adresse
Une adresse appelée groupe peut distribuer des copies, collecter des messages dans une boîte aux lettres partagée ou exécuter un flux de travail de liste de diffusion qui modifie et redistribue les publications. Ces opérations ont des conséquences d'authentification différentes. Classez les étapes de traitement réelles avant de demander pourquoi un message de groupe a échoué DMARC. Une étiquette de produit familière n'établit pas l'enveloppe sortante, le contenu signé ou la décision du destinataire.
Ce guide compare les preuves proposées et non les comptes inspectés. Aucune appartenance à un groupe, boîte aux lettres partagée, configuration de liste ou échantillon de livraison d'origine n'a été consultée. Les flux fictifs ci-dessous illustrent comment poser de meilleures questions. Preuve originale requise : échantillons de livraison directe et indirecte avec comparaison de l'itinéraire, de l'enveloppe, des signatures et des résultats fiables.
Distinguer la distribution de l'accès partagé
Microsoft décrit les listes de distribution Exchange Online comme un moyen de distribuer des messages et les distingue des groupes dynamiques, des groupes de sécurité et des groupes Microsoft 365 . Sa documentation sur les boîtes aux lettres partagées décrit plutôt plusieurs personnes accédant à la même boîte aux lettres, avec les autorisations appropriées pour envoyer en tant que ou au nom de cette boîte aux lettres. Ces objectifs documentés ne prédisent pas comment un locataire particulier achemine une copie externe. Listes de distribution Microsoft Boîtes aux lettres partagées Microsoft
Séparez la réception d'un message dans un stockage partagé de son transfert ailleurs et de la rédaction d'une réponse. Un employé ouvrant un message stocké n'a pas ainsi créé un autre saut SMTP . Une règle de transfert peut en créer une. Une réponse envoyée à l'aide de l'adresse partagée est un nouveau message sortant dont le domaine d'auteur et la configuration de signature nécessitent leur propre évaluation. Enregistrez à quelle opération l’échec signalé concerne réellement.
Tracez l'enveloppe et le message indépendamment
À chaque limite SMTP , enregistrez l'hôte qui se connecte et COURRIER DE identité séparément du visible RFC5322. SPF évalue la connexion d'envoi par rapport à l'identité de l'enveloppe pertinente. Un message redistribué peut conserver l'auteur visible d'origine tout en atteignant le destinataire suivant à partir d'un serveur différent. Cette différence est une raison pour enquêter sur SPF , et non une preuve que tout mécanisme de distribution doit échouer. RFC 7208 sections 2.4 et 4
DKIM suit une dépendance différente. Une signature identifie son domaine de signature et couvre les instances d'en-tête sélectionnées ainsi que le corps canonique, sous réserve de toute limite de longueur de corps. Le simple fait d’envoyer le même contenu à des destinataires supplémentaires ne modifie pas nécessairement ces entrées. La modification du matériel couvert peut invalider la signature, tandis qu'une modification supprimée par la personne sélectionnée canonisation peut laisser la vérification inchangée. Inspectez les valeurs réelles h=, c= et toutes les valeurs l=. RFC 6376 sections 3.4 à 3.5
Reconnaître quand une liste devient un médiateur
Un gestionnaire de liste de diffusion peut ajouter un préfixe de sujet, un pied de page, des en-têtes de liste, un emballage de résumé ou une adresse d'auteur de remplacement. RFC 7960 documente ces modèles de flux indirects et leurs problèmes d'interopérabilité. Utilisez-le comme une explication des transformations possibles, et non comme une preuve qu'une liste nommée a activé chaque fonctionnalité. Capturez le message avant et après la redistribution pour établir quelles transformations se sont produites. RFC 7960 section 3.2.3
Évaluez chaque élément pertinent Signature DKIM indépendamment. La signature supplémentaire d'une liste ne répare pas une signature originale dont le contenu couvert a changé. Pour DMARC , une signature valide n'est utile que lorsque son domaine de signature s'aligne sur le domaine d'auteur en cours d'évaluation. De même, le passage SPF pour un domaine d'enveloppe contrôlé par liste n'établit pas alignement avec un domaine d'auteur externe inchangé. RFC 6376 section 4.2 RFC 9989 sections 3.2.10 et 5.3.5
Comparez deux succursales de livraison fictives
Imaginez un message fictif alex@writer.example adressé à discussion@club.example . Une branche distribue une copie autrement inchangée à un membre externe. Une autre branche de liste ajoute un pied de page après l’ajout de la signature writer.example DKIM . Supposons que la signature vérifiée à l'origine couvre tout le corps et utilise une canonisation corporelle détendue. Il s’agit d’hypothèses de scénario explicites et non de résultats observés.
Sur la branche inchangée, la signature originale peut rester valide, sous réserve de ses autres exigences de vérification. Le pied de page ajouté sur la deuxième branche modifie le corps canonique couvert et invalide cette signature. Si aucune branche n’a aligné SPF , la première peut toujours avoir un chemin DKIM aligné tandis que la seconde nécessite une explication ou une atténuation différente. Une nouvelle signature de domaine de liste ne peut pas à elle seule s'aligner sur l' writer.example From inchangée. RFC 6376 section 3.4.4 RFC 9989 section 5.3
Localiser des observations d'authentification dignes de confiance
Conservez les copies brutes originales et identifiez qui a inséré chacune d’entre elles. Authentication-Results champ. Un résultat écrit au niveau de l'entrée approuvée de l'organisation peut décrire le message avant une modification interne. Une vérification en aval décrit la représentation ultérieure. Les deux peuvent être précis à leurs limites respectives. Un en-tête de résultat arbitraire fourni par l’expéditeur ne constitue pas une preuve équivalente ; RFC 8601 nécessite un modèle de limite de confiance pour consommer ces assertions. RFC 8601 section 7
Si ARC apparaît, enregistrez séparément sa validation de chaîne et la décision de confiance du destinataire. RFC 8617 est expérimentale et ARC n'est pas un cadre de confiance universel. La proposition officielle de reclassification était un projet Internet actif lors de son examen le 8 novembre 2026, et non une spécification de remplacement approuvée. Ni un en-tête ARC ni un message accepté ne prouvent que la signature DKIM originale est actuellement vérifiée. RFC 8617 section 9.3 Proposition de statut IETF ARC
Choisissez une réparation adaptée au flux
La décision proposée doit identifier la branche défaillante réelle : utilisation non autorisée de l'enveloppe, modification du contenu couvert, identité d'auteur incorrecte ou décision de confiance spécifique au destinataire. Envisagez ensuite les modifications de configuration prises en charge avec le propriétaire du service. Préservez le traitement de sécurité requis et les attentes des utilisateurs plutôt que de désactiver globalement les fonctionnalités de groupe. Aucune autorisation de modifier un groupe, un locataire, un signataire ou une liste n'est impliquée par cette analyse.
Une vérification approuvée doit comparer un contrôle direct avec les succursales indirectes concernées, y compris les membres externes et les réponses à adresse partagée, le cas échéant. Conservez les messages bruts, les horodatages, les preuves d'itinéraire, les détails de signature et les résultats des évaluateurs connus. Jusqu'à ce que ces échantillons existent, le résultat défendable est une cartographie des flux et un plan de test, et non une déclaration selon laquelle les groupes de l'organisation sont sécurisés par DMARC.