Les tentatives de prise de contrôle de sous-domaines contournent désormais couramment l’authentification des e-mails car les organisations supposent que l’héritage de politique DMARC fonctionne automatiquement. Ce n’est pas le cas. Lorsqu’un sous-domaine ne possède pas d’enregistrement DMARC explicite, il hérite de la politique du domaine organisationnel—mais uniquement si la politique du domaine organisationnel existe et est correctement configurée. Si l’héritage échoue, les attaquants peuvent envoyer du courrier non authentifié depuis marketing.exemple.com, support.exemple.com ou n’importe quel sous-domaine non réclamé, même lorsque exemple.com applique DMARC avec p=reject.

L’héritage DMARC des sous-domaines crée trois conditions d’échec que les équipes de sécurité manquent couramment : (1) la politique du domaine organisationnel existe mais est mal configurée, donc les sous-domaines héritent d’une politique plus faible que prévue, (2) le sous-domaine envoie du courrier via un service tiers qui ne s’aligne pas avec l’authentification du domaine organisationnel, donc la politique héritée échoue aux vérifications d’alignement, ou (3) le sous-domaine est enregistré dans le DNS mais n’est pas activement géré, créant une faille exploitable où les attaquants peuvent revendiquer le sous-domaine via des vulnérabilités du fournisseur d’hébergement ou du fournisseur DNS et envoyer du courrier avant détection.

Les campagnes de phishing alimentées par l’IA analysent désormais ces lacunes en utilisant l’énumération DNS automatisée et la validation de politique. Si un sous-domaine renvoie NXDOMAIN ou un enregistrement DMARC nul, l’attaquant teste si le courrier usurpé depuis ce sous-domaine passe DMARC. Si c’est le cas, le sous-domaine devient un vecteur de phishing persistant.

Ce guide explique comment fonctionne réellement l’héritage DMARC des sous-domaines, où l’héritage échoue silencieusement et comment configurer une application qui ferme les failles exploitables avant que les attaquants ne les trouvent.

I. Comment fonctionne l’héritage de politique DMARC (et où il se brise)

Lorsqu’un serveur de messagerie récepteur évalue DMARC pour [email protected], il interroge le DNS pour un enregistrement DMARC à _dmarc.marketing.exemple.com. Si aucun enregistrement n’existe, le serveur interroge _dmarc.exemple.com. Si un enregistrement existe au niveau du domaine organisationnel, le sous-domaine hérite de la politique définie dans cet enregistrement.

Ce mécanisme d’héritage fonctionne correctement lorsque :

• Le domaine organisationnel (exemple.com) publie un enregistrement DMARC
• Le sous-domaine (marketing.exemple.com) ne publie pas d’enregistrement DMARC
• Le sous-domaine envoie du courrier qui s’aligne avec la configuration SPF ou DKIM du domaine organisationnel

L’héritage échoue lorsque :

• L’enregistrement DMARC du domaine organisationnel contient des erreurs de syntaxe, donc l’enregistrement est ignoré et le sous-domaine hérite effectivement d’aucune politique
• Le sous-domaine envoie du courrier via un service tiers qui utilise son propre domaine d’expéditeur d’enveloppe, brisant l’alignement SPF
• Le service tiers ne signe pas avec un sélecteur DKIM sous le domaine organisationnel, brisant l’alignement DKIM
• Le sous-domaine est enregistré dans le DNS mais n’est pas activement géré, donc les attaquants peuvent le revendiquer via la récupération de compte du fournisseur d’hébergement, les vulnérabilités du fournisseur DNS ou l’expiration de l’enregistrement du domaine

Lorsque l’héritage échoue, le courrier du sous-domaine soit échoue DMARC silencieusement (si la politique organisationnelle est p=none ou p=quarantine) soit échoue DMARC visiblement mais atteint quand même la boîte de réception (si le serveur récepteur n’honore pas l’application ou applique des remplacements de réputation).

II. Scénarios courants d’échec DMARC de sous-domaine

Scénario 1 : La politique du domaine organisationnel existe mais l’authentification du sous-domaine ne s’aligne pas

Configuration :

• exemple.com publie v=DMARC1; p=reject; aspf=s; adkim=s
• marketing.exemple.com envoie du courrier via Mailchimp
• Expéditeur d’enveloppe Mailchimp : [email protected]
• Signature DKIM Mailchimp : d=mcdlv.net

Ce qui se passe :

• DMARC interroge _dmarc.marketing.exemple.com → aucun enregistrement
• DMARC interroge _dmarc.exemple.com → trouve p=reject; aspf=s; adkim=s
• SPF évalue [email protected] → passe SPF pour mcdlv.net, pas marketing.exemple.com
• DKIM évalue la signature avec d=mcdlv.net → passe DKIM pour mcdlv.net, pas marketing.exemple.com
• La vérification d’alignement DMARC échoue car ni SPF ni DKIM ne s’alignent avec marketing.exemple.com en mode strict
• Résultat : La politique héritée ordonne aux récepteurs de rejeter le message, mais comme la politique a été héritée et non explicitement définie pour le sous-domaine, certains récepteurs peuvent appliquer une application plus souple

Correctif :
Publier un enregistrement DMARC explicite à _dmarc.marketing.exemple.com :

v=DMARC1; p=none; rua=mailto:[email protected]; sp=reject

Ensuite, configurer Mailchimp pour signer DKIM avec d=marketing.exemple.com ou d=exemple.com, afin que l’alignement DKIM passe en mode détendu.

Alternativement, utiliser aspf=r; adkim=r au niveau du domaine organisationnel pour permettre un alignement détendu pour les sous-domaines.

Scénario 2 : Sous-domaine enregistré dans le DNS mais pas activement géré

Configuration :

• exemple.com publie v=DMARC1; p=reject
• dev.exemple.com existe dans le DNS mais n’envoie plus de courrier et n’héberge plus de services
• L’attaquant découvre dev.exemple.com via l’énumération DNS
• L’attaquant revendique dev.exemple.com via la récupération de compte du fournisseur d’hébergement, une vulnérabilité du fournisseur DNS ou l’expiration du domaine

Ce qui se passe :

• L’attaquant configure une infrastructure de messagerie à dev.exemple.com
• L’attaquant envoie du courrier de phishing depuis [email protected]
• DMARC interroge _dmarc.dev.exemple.com → aucun enregistrement
• DMARC interroge _dmarc.exemple.com → trouve p=reject
• L’infrastructure de messagerie contrôlée par l’attaquant utilise SPF et DKIM contrôlés par l’attaquant, qui s’alignent tous deux avec dev.exemple.com en mode d’alignement détendu
• DMARC passe car l’attaquant contrôle le sous-domaine et peut configurer une authentification conforme
• Le courrier atteint la boîte de réception malgré l’application du domaine organisationnel

Correctif :
Publier explicitement p=reject à _dmarc.dev.exemple.com :

v=DMARC1; p=reject; rua=mailto:[email protected]

Supprimer les enregistrements DNS pour les sous-domaines inactifs. Si le sous-domaine doit rester enregistré, publier un enregistrement MX nul pour signaler que le sous-domaine n’envoie ni ne reçoit de courrier :

dev.exemple.com. IN MX 0 .

Surveiller les rapports DMARC pour une authentification inattendue depuis les sous-domaines.

Scénario 3 : Une erreur de syntaxe de politique du domaine organisationnel brise l’héritage

Configuration :

• exemple.com publie :

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=50

• newsletter.exemple.com envoie du courrier
• Aucun enregistrement DMARC explicite n’existe pour newsletter.exemple.com

Ce qui se passe :

• DMARC interroge _dmarc.newsletter.exemple.com → aucun enregistrement
• DMARC interroge _dmarc.exemple.com → trouve un enregistrement avec pct=50
• De nombreuses implémentations DMARC modernes ignorent pct= ou traitent l’application basée sur le pourcentage de manière incohérente
• Le sous-domaine hérite d’une politique qui peut ne pas être appliquée de manière prévisible
• Les attaquants envoient du courrier usurpé depuis newsletter.exemple.com et observent si l’application s’applique

Correctif :
Supprimer pct= de la politique du domaine organisationnel :

v=DMARC1; p=reject; rua=mailto:[email protected]

Étager l’application par sous-domaine ou groupe d’expéditeurs, pas par pourcentage.

III. Modèles de configuration de politique de sous-domaine explicite

Modèle 1 : Hériter de la politique du domaine organisationnel (comportement par défaut)

Enregistrement du domaine organisationnel :

_dmarc.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Comportement du sous-domaine :

• marketing.exemple.com hérite de p=reject
• support.exemple.com hérite de p=reject
• Tous les sous-domaines héritent de p=reject sauf si un enregistrement explicite existe

Quand l’utiliser :

• Vous contrôlez tous les sous-domaines
• Tous les sous-domaines envoient du courrier via une infrastructure qui s’aligne avec le SPF ou DKIM du domaine organisationnel

Modèle 2 : Remplacer la politique héritée pour des sous-domaines spécifiques

Enregistrement du domaine organisationnel :

_dmarc.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Remplacement du sous-domaine :

_dmarc.marketing.exemple.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Résultat :

• marketing.exemple.com utilise p=none
• Tous les autres sous-domaines héritent de p=reject

Quand l’utiliser :

• Un sous-domaine spécifique envoie du courrier via des services tiers qui ne peuvent pas encore s’aligner avec l’authentification du domaine organisationnel
• Vous avez besoin de visibilité sur les résultats d’authentification avant d’appliquer la politique sur le sous-domaine

Modèle 3 : Définir la politique de sous-domaine au niveau du domaine organisationnel

Enregistrement du domaine organisationnel :

_dmarc.exemple.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"

Résultat :

• exemple.com utilise p=reject
• Tous les sous-domaines héritent de p=quarantine (défini par sp=)

Quand l’utiliser :

• Vous voulez une application différente pour le domaine organisationnel vs. les sous-domaines
• Les sous-domaines envoient du courrier à volume plus faible ou à risque plus faible

Modèle 4 : Application explicite pour chaque sous-domaine

Enregistrement du domaine organisationnel :

_dmarc.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Enregistrements de sous-domaine explicites :

_dmarc.marketing.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.support.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.newsletter.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Quand l’utiliser :

• Vous voulez une visibilité et un contrôle maximum
• Vous voulez éliminer l’ambiguïté sur quelle politique s’applique
• Vous voulez détecter les tentatives de prise de contrôle de sous-domaine via les anomalies de rapport

IV. Interaction entre mode d’alignement et héritage de sous-domaine

Le mode d’alignement DMARC (aspf= pour SPF, adkim= pour DKIM) contrôle si l’alignement nécessite une correspondance exacte du domaine (mode strict) ou permet une correspondance du domaine organisationnel (mode détendu).

Mode détendu (aspf=r; adkim=r) :

• SPF passe si le domaine de l’expéditeur d’enveloppe est mail.exemple.com et l’en-tête From est [email protected]
• DKIM passe si le domaine de signature DKIM est mail.exemple.com et l’en-tête From est [email protected]

Mode strict (aspf=s; adkim=s) :

• SPF passe uniquement si le domaine de l’expéditeur d’enveloppe correspond exactement au domaine de l’en-tête From
• DKIM passe uniquement si le domaine de signature DKIM correspond exactement au domaine de l’en-tête From

Interaction avec l’héritage de sous-domaine :
Lorsqu’un sous-domaine hérite d’une politique avec mode d’alignement strict, le courrier de ce sous-domaine doit s’aligner exactement. Si le sous-domaine envoie via un service tiers qui utilise son propre domaine pour SPF ou DKIM, l’alignement strict échoue.

Exemple :

• Domaine organisationnel : v=DMARC1; p=reject; aspf=s; adkim=s
• Sous-domaine : marketing.exemple.com envoie via Mailchimp
• Mailchimp utilise [email protected] pour l’expéditeur d’enveloppe
• Mailchimp signe DKIM avec d=mcdlv.net
• DMARC évalue l’alignement strict : SPF et DKIM échouent tous deux l’alignement
• Résultat : DMARC échoue, la politique ordonne le rejet

Options de correctif :

1. Changer la politique du domaine organisationnel en mode détendu : aspf=r; adkim=r
2. Publier une politique de sous-domaine explicite avec mode détendu : v=DMARC1; p=reject; aspf=r; adkim=r
3. Configurer Mailchimp pour signer DKIM avec le domaine organisationnel ou le sélecteur de sous-domaine

V. Modèles d’attaque de prise de contrôle de sous-domaine et lacunes DMARC

La prise de contrôle de sous-domaine se produit lorsqu’un attaquant revendique le contrôle d’un sous-domaine qu’une organisation a enregistré mais ne gère plus activement. Les vecteurs d’attaque courants incluent :

1. Hébergement DNS expiré : Le CNAME du sous-domaine pointe vers un compte de fournisseur d’hébergement qui a expiré. L’attaquant enregistre un nouveau compte avec le même fournisseur et revendique le sous-domaine.
2. CNAME pendant : Le CNAME du sous-domaine pointe vers un service (GitHub Pages, AWS S3, Heroku, etc.) qui n’existe plus. L’attaquant enregistre le nom du service et diffuse du contenu depuis le sous-domaine.
3. Compromission du compte du fournisseur DNS : L’attaquant obtient l’accès au compte du fournisseur DNS via la réutilisation d’identifiants, le phishing ou une vulnérabilité du fournisseur. L’attaquant modifie les enregistrements de sous-domaine pour pointer vers une infrastructure contrôlée par l’attaquant.

L’héritage DMARC n’empêche pas la prise de contrôle de sous-domaine. Si un attaquant contrôle l’infrastructure du sous-domaine, l’attaquant peut configurer SPF et DKIM pour s’aligner avec le sous-domaine, passant DMARC même lorsque le domaine organisationnel applique p=reject.

Détection et prévention :

1. Politiques de sous-domaine explicites : Publier des enregistrements DMARC à chaque sous-domaine pour obtenir une visibilité sur l’activité d’authentification.
2. Surveillance DNS : Surveiller les enregistrements DNS pour des changements inattendus aux enregistrements A, AAAA, CNAME, MX ou TXT de sous-domaine.
3. Analyse des rapports DMARC : Examiner les rapports DMARC pour l’authentification depuis des sous-domaines qui ne devraient pas envoyer de courrier.
4. Enregistrements MX nuls : Publier MX nul pour les sous-domaines qui n’envoient ni ne reçoivent de courrier :

inactif.exemple.com. IN MX 0 .

5. Supprimer les enregistrements DNS inutilisés : Supprimer les enregistrements A, AAAA et CNAME pour les sous-domaines qui ne diffusent plus de contenu ou n’envoient plus de courrier.

VI. Débogage des échecs de politique DMARC héritée

Lorsqu’un sous-domaine hérite d’une politique DMARC mais que le courrier échoue l’application de manière inattendue, suivez ce processus de diagnostic :

Étape 1 : Vérifier la syntaxe de la politique du domaine organisationnel

Interroger l’enregistrement DMARC du domaine organisationnel :

dig TXT _dmarc.exemple.com +short

Sortie attendue :

"v=DMARC1; p=reject; rua=mailto:[email protected]"

Erreurs de syntaxe courantes qui brisent l’héritage :

• Absence de v=DMARC1
• Valeur p= invalide (doit être none, quarantine ou reject)
• Adresse rua= mal formée
• Inclusion de la balise obsolète pct=

Si des erreurs de syntaxe existent, l’enregistrement peut être ignoré, faisant en sorte que les sous-domaines héritent d’aucune politique.

Étape 2 : Vérifier l’absence ou la présence d’enregistrement de sous-domaine

Interroger l’enregistrement DMARC du sous-domaine :

dig TXT _dmarc.marketing.exemple.com +short

Sortie attendue (si héritant) :

(pas de sortie)

Sortie attendue (si remplacement explicite) :

"v=DMARC1; p=none; rua=mailto:[email protected]"

Si un enregistrement existe au niveau du sous-domaine, l’héritage ne se produit pas. Le sous-domaine utilise sa propre politique.

Étape 3 : Vérifier l’alignement SPF

Vérifier le résultat SPF et l’alignement dans les rapports DMARC ou les en-têtes de courrier.

Échec d’alignement SPF courant :

• Domaine de l’expéditeur d’enveloppe : [email protected]
• Domaine de l’en-tête From : [email protected]
• SPF passe pour mail.servicetierce.com
• L’alignement SPF échoue car le domaine de l’expéditeur d’enveloppe ne correspond pas au domaine de l’en-tête From

Correctif :

• Configurer le service tiers pour utiliser le domaine organisationnel ou le sous-domaine comme expéditeur d’enveloppe
• Utiliser le mode d’alignement détendu au niveau du domaine organisationnel ou du sous-domaine

Étape 4 : Vérifier l’alignement DKIM

Vérifier le domaine de signature DKIM dans les en-têtes de courrier :

DKIM-Signature: v=1; a=rsa-sha256; d=servicetierce.com; s=selector; ...

Si d=servicetierce.com et l’en-tête From est [email protected], l’alignement DKIM échoue en mode strict.

Correctif :

• Configurer le service tiers pour signer DKIM avec d=marketing.exemple.com ou d=exemple.com
• Utiliser le mode d’alignement détendu au niveau du domaine organisationnel ou du sous-domaine

Étape 5 : Examiner les rapports DMARC pour l’activité de sous-domaine

Les rapports agrégés DMARC incluent les résultats d’authentification de sous-domaine. Rechercher :

• Des sous-domaines que vous ne reconnaissez pas
• Des taux d’échec élevés depuis des sous-domaines connus
• Une authentification depuis des adresses IP que vous ne contrôlez pas

Si un sous-domaine apparaît dans les rapports mais que vous ne contrôlez pas l’infrastructure du sous-domaine, enquêter sur une prise de contrôle de sous-domaine.

Dans un déploiement Skysnag géré, utiliser la destination de rapport générée par Skysnag. Ce qui suit est un exemple manuel uniquement :

v=DMARC1; p=none; rua=mailto:[email protected]

Un enregistrement statique traditionnel peut fonctionner, mais uniquement si les rapports sont activement reçus, analysés et traités.

VII. Stratégie de configuration DMARC de sous-domaine recommandée

1. Publier la politique du domaine organisationnel :

v=DMARC1; p=reject; rua=mailto:[email protected]; sp=quarantine

Cela applique p=reject pour le domaine organisationnel et p=quarantine pour tous les sous-domaines par défaut.

2. Publier des politiques explicites pour les sous-domaines actifs :

_dmarc.marketing.exemple.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
_dmarc.support.exemple.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Cela fournit une visibilité sur l’activité d’authentification et permet une application progressive par sous-domaine.

3. Supprimer les enregistrements DNS pour les sous-domaines inactifs.
4. Publier MX nul pour les sous-domaines qui n’envoient ni ne reçoivent de courrier :

inactif.exemple.com. IN MX 0 .

5. Surveiller les rapports DMARC pour une activité de sous-domaine inattendue.

Utilisez Skysnag Protect pour identifier les expéditeurs légitimes, détecter les sources non autorisées et progresser vers l’application :

VIII. Points clés à retenir

L’héritage DMARC de sous-domaine fonctionne uniquement lorsque le domaine organisationnel publie un enregistrement DMARC valide et que le sous-domaine ne publie pas son propre enregistrement. L’héritage échoue lorsque la politique du domaine organisationnel contient des erreurs de syntaxe, le sous-domaine envoie du courrier via des services tiers qui ne s’alignent pas, ou le sous-domaine est enregistré mais n’est pas activement géré, créant des opportunités de prise de contrôle de sous-domaine.

Publier des politiques DMARC explicites pour tous les sous-domaines actifs pour obtenir visibilité et contrôle. Supprimer les enregistrements DNS pour les sous-domaines inactifs. Utiliser des enregistrements MX nuls pour les sous-domaines qui n’envoient ni ne reçoivent de courrier. Surveiller les rapports DMARC pour une activité d’authentification de sous-domaine inattendue.

Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit :