La protection DMARC ne s’arrête pas à votre domaine racine. Bien que la plupart des organisations se concentrent sur la sécurisation de leur domaine principal, les cybercriminels ciblent de plus en plus les sous-domaines pour contourner les contrôles d’authentification des emails. Comprendre les politiques DMARC des sous-domaines et la configuration du tag sp assure une protection complète sur l’ensemble de votre infrastructure de domaines.

I. Comprendre l’Héritage des Sous-domaines DMARC

DMARC fonctionne sur un modèle d’héritage où les sous-domaines héritent automatiquement de la politique de leur domaine parent, sauf si elle est explicitement remplacée. Lorsque vous publiez une politique DMARC pour exemple.com, les sous-domaines comme mail.exemple.com et marketing.exemple.com héritent de cette même politique par défaut.

Cependant, cet héritage ne s’applique que lorsqu’aucun enregistrement DMARC spécifique n’existe pour le sous-domaine. Si marketing.exemple.com a son propre enregistrement DMARC, il utilisera cette politique au lieu d’hériter du domaine racine.

Comportement d’Héritage par Défaut

Considérez cet enregistrement DMARC de domaine racine :

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

Sans politiques de sous-domaines explicites, tous les sous-domaines héritent de la politique de quarantaine. Cela signifie :

• mail.exemple.com hérite de p=quarantine
• boutique.exemple.com hérite de p=quarantine
• api.exemple.com hérite de p=quarantine

Cet héritage fournit une protection de base mais peut ne pas convenir à tous les besoins organisationnels.

II. Le Tag DMARC sp : Contrôle de la Politique des Sous-domaines

Le tag sp (politique des sous-domaines) permet aux organisations de spécifier différentes politiques pour les sous-domaines tout en maintenant des politiques séparées pour le domaine racine. Ce contrôle granulaire répond aux scénarios où les sous-domaines nécessitent un traitement différent du domaine principal.

Syntaxe et Valeurs du Tag sp

Le tag sp accepte les mêmes valeurs que le tag de politique principal :

• sp=none – Surveiller l’authentification des sous-domaines sans application
• sp=quarantine – Traiter les messages des sous-domaines échoués comme suspects
• sp=reject – Bloquer les messages des sous-domaines qui échouent à l’authentification

Implémentation Stratégique du Tag sp

Une configuration courante combine une protection stricte du domaine racine avec une application graduelle des sous-domaines :

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

Cette politique :

• Rejette les messages non authentifiés du domaine racine
• Met en quarantaine les messages non authentifiés des sous-domaines
• Fournit une application graduelle tout en maintenant la sécurité

III. Scénarios Avancés de Configuration des Sous-domaines

Scénario 1 : Racine Haute Sécurité avec Surveillance des Sous-domaines

Les organisations avec des communications critiques du domaine racine implémentent souvent des politiques racines strictes tout en surveillant l’activité des sous-domaines :

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

Cette configuration protège le domaine principal tout en recueillant des informations sur les modèles d’utilisation des sous-domaines.

Scénario 2 : Application Graduée à travers la Hiérarchie de Domaine

Certaines organisations préfèrent des niveaux d’application étagés :

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

Cette approche permet la surveillance de l’authentification des sous-domaines tout en maintenant une protection modérée du domaine racine.

Scénario 3 : Enregistrements de Remplacement Spécifiques aux Sous-domaines

Pour un contrôle précis, les organisations peuvent publier des enregistrements DMARC spécifiques pour des sous-domaines individuels :

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

Ces enregistrements remplacent à la fois les politiques du domaine racine et du tag sp pour leurs sous-domaines respectifs.

IV. Découverte et Surveillance des Sous-domaines

L’implémentation efficace de DMARC pour les sous-domaines nécessite une découverte complète des sous-domaines. Les organisations sous-estiment souvent leur empreinte de sous-domaines, manquant des vecteurs d’attaque critiques.

Sous-domaines Couramment Négligés

Les équipes de sécurité manquent fréquemment ces catégories de sous-domaines :

• Environnements de développement et de test (dev.exemple.com, staging.exemple.com)
• Intégrations tierces (webhook.exemple.com, api.exemple.com)
• Applications héritées (ancien.exemple.com, archive.exemple.com)
• Sous-domaines régionaux ou départementaux (fr.exemple.com, rh.exemple.com)

Rapports DMARC pour la Visibilité des Sous-domaines

Les rapports agrégés DMARC fournissent une visibilité sur l’activité email des sous-domaines. Le tag rua dans votre politique de domaine racine reçoit des rapports pour tous les sous-domaines sauf s’ils ont des enregistrements DMARC spécifiques avec des adresses de rapport différentes.

Skysnag Protect découvre et surveille automatiquement l’activité des sous-domaines grâce à l’analyse des rapports DMARC, aidant les organisations à identifier des sous-domaines d’envoi d’emails précédemment inconnus.

V. Meilleures Pratiques d’Implémentation

Déploiement Graduel de la Politique des Sous-domaines

Commencez par la surveillance sur tous les sous-domaines avant d’implémenter l’application :

1. Phase 1 : Déployez p=none; sp=none pour établir un rapport de base
2. Phase 2 : Passez à p=quarantine; sp=none pour la protection du domaine racine
3. Phase 3 : Implémentez p=quarantine; sp=quarantine pour une couverture complète
4. Phase 4 : Progressez vers p=reject; sp=reject après validation

Exigences d’Alignement et Sous-domaines

Les exigences d’alignement DMARC s’appliquent également aux sous-domaines. Pour que les messages des sous-domaines passent DMARC :

• SPF doit s’aligner avec le sous-domaine (relâché) ou correspondance exacte (strict)
• Les signatures DKIM doivent s’aligner avec le domaine parent (relâché) ou le sous-domaine (strict)

Considérez les implications d’alignement lors de la configuration des politiques de sous-domaines, en particulier pour l’automatisation marketing et les services d’email transactionnel.

Test des Configurations de Sous-domaines

Avant d’implémenter des politiques d’application, testez minutieusement les configurations de sous-domaines :

• Vérifiez que les enregistrements SPF incluent toutes les sources d’envoi des sous-domaines
• Assurez-vous que les signatures DKIM s’alignent correctement avec les politiques de domaine
• Surveillez les rapports DMARC pour les échecs d’authentification inattendus des sous-domaines
• Testez la livraison d’email depuis tous les sous-domaines actifs

VI. Conformité et Couverture des Sous-domaines

Les organisations soumises à des exigences réglementaires devraient s’assurer que la couverture complète des sous-domaines soutient leurs objectifs de conformité. Bien que des réglementations spécifiques ne puissent pas explicitement exiger des politiques DMARC pour les sous-domaines, l’authentification complète des emails démontre la diligence raisonnable dans la protection contre le phishing et l’usurpation d’identité.

Les industries manipulant des données sensibles implémentent souvent des politiques strictes pour les sous-domaines dans le cadre de frameworks de cybersécurité plus larges. Le tag sp fournit la flexibilité pour équilibrer les exigences de sécurité avec les besoins opérationnels à travers différentes fonctions de sous-domaines.

VII. Erreurs Courantes de Politique des Sous-domaines

Politiques de Sous-domaines Trop Permissives

Définir sp=none indéfiniment crée des angles morts persistants dans la couverture de sécurité des emails. Bien que les phases de surveillance soient importantes, les organisations devraient progresser vers des politiques d’application basées sur les données de rapport.

Logique de Politique Incohérente

Implémenter des politiques de domaine racine plus strictes tout en maintenant des politiques de sous-domaines permissives peut créer des failles de sécurité. Les attaquants peuvent cibler des sous-domaines faiblement protégés pour contourner les contrôles du domaine racine.

Découverte de Sous-domaines Manquante

Déployer des politiques DMARC sans découverte complète des sous-domaines laisse des vecteurs d’attaque inconnus non protégés. L’énumération et la surveillance régulières des sous-domaines assurent une couverture complète.

VIII. Considérations Avancées du Tag sp

Implications des Sous-domaines Génériques

Le tag sp s’applique à tous les sous-domaines actuels et futurs sous le domaine racine. Cela inclut les sous-domaines créés dynamiquement et les configurations DNS génériques. Les organisations utilisant la création dynamique de sous-domaines devraient soigneusement considérer les implications du tag sp pour les systèmes automatisés.

Héritage de Sous-domaines Multi-niveaux

Pour les sous-domaines multi-niveaux (comme mail.marketing.exemple.com), l’héritage DMARC suit la structure de domaine organisationnelle. La politique disponible la plus spécifique s’applique, qu’elle provienne du parent immédiat, du domaine organisationnel ou du domaine racine.

IX. Intégration avec les Plateformes de Sécurité Email

Les plateformes modernes de sécurité email comme Skysnag Protect fournissent une gestion centralisée des politiques DMARC des sous-domaines, suivant automatiquement l’héritage des politiques et identifiant les lacunes de configuration. Cette visibilité s’avère essentielle pour les organisations gérant des infrastructures de domaines complexes.

La gestion automatisée des politiques aide à assurer des niveaux de protection cohérents à travers les domaines racines et les sous-domaines tout en fournissant la flexibilité d’implémenter des contrôles granulaires où les exigences métier demandent des approches différentes.

X. Points Clés à Retenir

Les politiques DMARC des sous-domaines fournissent une protection essentielle au-delà de la couverture du domaine racine. Le tag sp offre un contrôle flexible des politiques, permettant aux organisations d’équilibrer les exigences de sécurité avec les besoins opérationnels à travers différentes fonctions de sous-domaines.

Une implémentation réussie de DMARC pour les sous-domaines nécessite une découverte complète des sous-domaines, un déploiement graduel des politiques et une surveillance continue grâce aux rapports agrégés. Les organisations devraient éviter les pièges courants comme les politiques trop permissives et la logique d’application incohérente.

Skysnag Protect simplifie la gestion DMARC des sous-domaines grâce à la découverte automatisée, le contrôle centralisé des politiques et le rapport complet à travers toute votre infrastructure de domaines.