L'expression DMARC le contournement peut décrire des événements très différents. Un laissez-passer valide provenant d'une source surautorisée, une livraison malgré un résultat défaillant et une erreur de mise en œuvre ne sont pas le même échec. Commencez par une affirmation falsifiable : quelle identité a été affirmée, quelles preuves ont été fiables et quelle décision différait de la règle attendue ?
Reconstruire la décision observée
Préservez le domaine de l'auteur, le domaine de l'enveloppe, les domaines de signature, les résultats d'authentification approuvés et la disposition du destinataire. Enregistrez la politique et le temps d’observation. Un message délivré ne prouve pas en soi une réussite DMARC . La gestion du destinataire inclut la politique locale et le traitement demandé par le propriétaire de domaine ne constitue pas une garantie de livraison universelle. RFC 9989.
De même, une copie Authentication-Results la chaîne n'est pas une preuve de la décision du système récepteur. Établissez le service d'authentification de confiance et le saut correspondant. RFC 8601. Si la seule preuve est une capture d'écran indiquant la réussite, conservez la réclamation comme non résolue jusqu'à ce que les identités sous-jacentes et le contexte de confiance soient disponibles.
Séparez l’autorisation excessive de l’évasion des règles
BreakSPF étudie à quel point permissif SPF l’autorisation et l’accès à l’infrastructure partagée peuvent permettre usurpation d'identité. Son modèle de menace donne à l'attaquant un chemin source éligible ; le séquestre peut alors évaluer l'autorisation publiée telle qu'elle est écrite. BreakSPF, Section III.A et Figure 3.
Si la source contrôlée par l'attaquant se trouve dans une plage autorisée et utilise une identité d'enveloppe alignée, la règle de passage ordinaire peut réussir. La faiblesse réside dans l'autorité accordée ou dans les limites du service, plutôt que dans une nouvelle définition du DMARC . À l’inverse, si seule une identité sans rapport s’authentifie et que le domaine de l’auteur n’est pas aligné, une passe revendiquée nécessite une explication différente.
Classer trois résultats hypothétiques
Supposons un seul From alerts@brand.test visible et une évaluation DMARC autrement éligible. Ce sont des hypothèses écrites et non des incidents observés.
- Cas d'autorisation : la source 192.0.2.99 se situe dans une plage SPF ip4:192.0.2.0/24 ; COURRIER DE bounce@brand.test passe SPF ; Non Signature DKIM. Le chemin SPF aligné génère une passe DMARC au niveau du message. Demandez si cette source est réellement contrôlable par un expéditeur involontaire et quel propriétaire lui a accordé cette autorité.
- Cas de traitement : MAIL FROM bounce@other.test passe SPF et DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed alignement résultat.
- Cas de preuve : un en-tête copié indique "réussite", mais l'origine du destinataire de confiance, les identités évaluées et la politique appliquée sont inconnues. Ni une violation du protocole ni un laissez-passer digne de confiance ne sont établis. Demandez l’enregistrement original et côté destinataire.
Un expéditeur positif autorisé 192.0.2.10 et une source externe 198.51.100.10 peuvent proposer des contrôles lors de l'enquête sur le premier cas. Un hypothétique enregistrement ip4:192.0.2.10/32 -all n'admet que le premier ; aucun changement réel de production ne découle de cette arithmétique de préfixe. Il n'y a pas d'analyseur exécuté, de vérification de signature ou d'exploit ici.
La section 7.4 de la RFC9989 nécessite DKIM valide pour la publication de domaines p=reject. Un mécanisme SPF aligné sur la transmission est suffisant pour la condition de réussite d'un message particulier, mais ne constitue pas une recommandation pour l'application du SPF uniquement.
Rendre le résultat exploitable
Nommez l’état reproduit et les preuves encore manquantes. Une conclusion utile indique qu'une source spécifiée est admise par une autorisation spécifiée et identifie le propriétaire responsable. Cela ne dit pas que toute la protection DMARC est vaincue. Vérifiez si le service réel restreint les identités des locataires, si la source est réellement contrôlable et si le destinataire a appliqué le résultat revendiqué.
Préserver un contrôle positif autorisé inoffensif lors du test d’une atténuation proposée. Réduire une plage ou modifier un connecteur peut briser les expéditeurs légitimes. Exigez l’approbation des modifications spécifiques à l’itinéraire et la vérification après modification, et gardez le comportement du fournisseur non testé en laboratoire explicitement non résolu. Cela prend en charge une solution précise sans exagérer un modèle éducatif en une vulnérabilité de production.