Dernière mise à jour : juillet 2026

En bref : Le tag optionnel sp= dans un enregistrement DMARC établit une politique indépendante spécifiquement pour les sous-domaines. Il permet aux administrateurs de sécuriser strictement les sous-domaines ou de les gérer avec plus de flexibilité que le domaine principal.

Par défaut, Domain-based Message Authentication, Reporting, and Conformance (DMARC) applique un héritage de politique dans toute ta hiérarchie DNS. Lorsque tu publies un enregistrement DMARC sous _dmarc.example.com, le mode de politique déclaré dans le tag p= s’applique non seulement à example.com, mais est automatiquement hérité par chaque sous-domaine, comme mail.example.com ou portal.example.com.

Cependant, les grandes architectures d’entreprise ou les déploiements progressifs nécessitent souvent que les sous-domaines suivent des règles différentes de celles du domaine principal. Pour offrir ce contrôle granulaire, le protocole prévoit le tag sp= (Subdomain Policy).

Comment fonctionne le tag sp= selon la RFC 7489

Le tag sp= accepte exactement les mêmes valeurs de politique (none, quarantine, reject) que le tag principal p=. Sa particularité réside dans son champ d’application strict : il s’applique uniquement aux sous-domaines, remplaçant la politique déclarée dans p=.

Selon la norme RFC 7489, le protocole précise : sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains.

Un enregistrement DMARC utilisant une politique de sous-domaine distincte ressemble à ceci :

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com

Dans ce déploiement, les e-mails non authentifiés prétendant provenir du domaine racine (example.com) sont immédiatement rejetés (p=reject), tandis que les messages non authentifiés prétendant provenir de n’importe quel sous-domaine sont placés en quarantaine (sp=quarantine).

Cas d’usage stratégiques pour le tag sp=

Déployer un tag sp= est particulièrement utile dans deux situations opérationnelles courantes :

1. Sécuriser les sous-domaines tout en surveillant le domaine principal

Les organisations ont souvent besoin de plusieurs mois pour auditer et autoriser tous les flux d’e-mails complexes sur leur domaine principal (example.com). Pendant que le domaine racine reste en mode surveillance (p=none), les attaquants pourraient facilement exploiter des sous-domaines non protégés (support.example.com ou billing.example.com) pour lancer des campagnes d’hameçonnage.

En configurant p=none; sp=reject, tu sécurises immédiatement tous tes sous-domaines n’envoyant pas d’e-mails contre le spoofing, tout en continuant à collecter en toute sécurité des rapports XML sur ton domaine principal.

2. Offrir un tampon de sécurité lors de l’intégration d’un sous-domaine

Si ton domaine principal applique déjà p=reject, mais que l’équipe marketing lance une nouvelle plateforme d’e-mail tierce sur un sous-domaine dédié (news.example.com), une politique reject immédiate risque de bloquer des messages légitimes si l’alignement DNS n’est pas encore finalisé. Définir sp=quarantine crée un tampon de sécurité temporaire pour tes sous-domaines jusqu’à ce que tous les nouveaux services réussissent l’alignement.

Vérifier ta configuration

Pour vérifier si ta politique principale et celle de tes sous-domaines s’héritent correctement dans ton arborescence DNS, analyse ton domaine avec le scanner gratuit MXAudit.

Pour en savoir plus sur la structuration des politiques d’authentification et la configuration par hébergeur, consulte le guide complet DMARC et des tutoriels comme configurer DMARC chez IONOS.

Pour aller plus loin