La politique de sous-domaine DMARC : sp et np

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@exemple.fr

La balise np : verrouiller les sous-domaines inexistants

C'est l'apport le plus utile de DMARCbis en matière de sous-domaines. La balise np (non-existent subdomain policy) fixe la politique des sous-domaines qui n'existent pas dans le DNS — c'est-à-dire qui n'ont aucun enregistrement A, AAAA ou MX.

Pourquoi est-ce crucial ? Parce qu'un attaquant n'a pas besoin que facture.exemple.fr existe pour l'écrire dans un From:. Il forge l'adresse, l'envoie, et compte sur le fait que la politique en place ne couvre pas ce cas. Avec np=reject, la déclaration est sans ambiguïté : « tout courrier prétendant venir d'un sous-domaine qui n'existe pas est à refuser. »

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@exemple.fr

Le grand avantage de np : c'est un gain immédiat et sans risque. Aucun courrier légitime ne part d'un sous-domaine qui n'existe pas, par définition. np=reject se pose donc très tôt dans un déploiement, avant même que toutes les vraies sources soient alignées — il n'y a rien à observer, rien à casser. La balise a son propre guide détaillé : la balise np (sous-domaine inexistant).

Comment le destinataire choisit le bon enregistrement

Pour appliquer sp ou np, le destinataire doit d'abord déterminer quel enregistrement DMARC gouverne un message donné, et si le sous-domaine existe. Historiquement, cette détermination du domaine organisationnel s'appuyait sur la Public Suffix List (PSL). DMARCbis la remplace par le DNS Tree Walk : une suite de requêtes DNS (huit au maximum) qui remonte l'arbre des noms jusqu'à trouver l'enregistrement DMARC applicable.

En pratique, pour un message prétendant venir de a.b.exemple.fr, le destinataire cherche un enregistrement DMARC sur ce nom, puis remonte niveau par niveau jusqu'au domaine organisationnel, et applique la politique la plus spécifique trouvée — en distinguant sous-domaine existant (sp ou son propre enregistrement) et inexistant (np). Le mécanisme est expliqué en détail dans le DNS Tree Walk. Rien n'est à configurer pour le Tree Walk lui-même ; il suffit de publier des sp/np cohérents.

Le scénario d'attaque que ça bloque

Le cas type : une banque dont la racine banque.fr est en p=reject, sans np. Un fraudeur envoie une campagne de phishing depuis securite.banque.fr — un sous-domaine qui n'existe pas. Comme il n'existe pas, il n'a pas d'enregistrement propre ; et selon l'implémentation, l'héritage de p peut être appliqué de façon inégale à un nom inexistant. Le message peut donc passer, avec une adresse d'expéditeur crédible qui inspire confiance à la victime.

Avec np=reject, ce scénario s'effondre : le destinataire voit un sous-domaine inexistant, applique np, refuse le message. C'est exactement le type d'usurpation « par le côté » que les grandes marques subissent, et que sp/np neutralisent pour un coût de configuration quasi nul. Le sujet des marques très ciblées est développé dans DMARC pour les banques.

Réglages recommandés

Pour la majorité des domaines, la configuration cible est simple et symétrique :

• p=reject sur la racine, une fois les sources alignées.
• sp=reject pour que les sous-domaines existants sans enregistrement propre soient aussi protégés.
• np=reject pour fermer les sous-domaines inexistants — à poser tôt, sans attendre.

Si un sous-domaine légitime a des besoins particuliers (prestataire non encore aligné), mieux vaut lui donner son propre enregistrement DMARC plutôt que d'affaiblir sp sur toute la racine. C'est plus chirurgical et ça préserve la protection globale.

Quand un sous-domaine mérite son propre enregistrement

L'héritage via sp couvre le cas général, mais certains sous-domaines ont une vie propre qui justifie un enregistrement DMARC dédié — publié directement sur _dmarc.le-sous-domaine.exemple.fr. Trois situations typiques :

• Un flux d'envoi distinct et volumineux. Si mail.exemple.fr sert exclusivement à une plateforme marketing, lui donner son propre enregistrement offre une adresse rua séparée et permet de suivre ce flux indépendamment de la racine. Des rapports dédiés montrent d'un coup d'œil si cette source précise est saine.
• Un rythme de durcissement différent. Un sous-domaine dont les sources ne sont pas encore toutes alignées peut rester en quarantine pendant que la racine passe en reject. Plutôt que d'abaisser sp pour toute l'organisation, le retard s'isole sur le seul sous-domaine concerné.
• Une délégation à une entité tierce. Filiale, marque secondaire, prestataire qui gère un sous-domaine complet : lui confier son propre enregistrement DMARC clarifie les responsabilités et évite qu'une erreur de sa part n'affecte la politique de la racine.

La règle mentale est simple : l'enregistrement le plus spécifique gagne. Un _dmarc posé sur le sous-domaine l'emporte toujours sur sp hérité de la racine. Cette spécificité sert à traiter les exceptions localement, sans jamais affaiblir la protection globale au niveau du domaine organisationnel.

Le cas des domaines parqués et sans email

Un angle mort fréquent : les domaines (ou sous-domaines) détenus par une organisation mais d'où aucun email ne part — marques défensives, anciens noms, domaines réservés « au cas où ». Beaucoup d'organisations les laissent sans DMARC, en pensant qu'un domaine qui n'envoie rien ne risque rien. C'est l'inverse : un domaine sans politique DMARC est un domaine que n'importe qui peut usurper sans résistance. La bonne pratique est de leur poser d'emblée la politique la plus stricte — p=reject; sp=reject; np=reject — puisque, par construction, aucun courrier légitime n'en part. np y prend tout son sens : sur un domaine parqué, tous les sous-domaines sont inexistants.

Les sous-domaines ont un cycle de vie — sp et np le suivent

Un dernier point à intégrer : la frontière entre sp et np n'est pas figée. Elle est évaluée par le destinataire au moment où un message arrive, d'après ce que dit le DNS à cet instant. Qu'un microsite de campagne soit monté avec un simple enregistrement A, et ce nom existe désormais — un courrier forgé en son nom est jugé sous sp, pas sous np. Qu'un vieux service soit décommissionné et ses enregistrements DNS supprimés, et le nom retombe silencieusement sous np. Deux conséquences pratiques. D'abord, sp doit rester exactement aussi strict que np : si sp est plus laxiste, la simple publication d'un sous-domaine purement web affaiblit sa protection mail sans que personne n'ait touché à l'email. Ensuite, le nettoyage DNS fait partie intégrante du décommissionnement — c'est l'enregistrement supprimé qui rend le nom à la politique la plus stricte.

Erreurs fréquentes

• Durcir la racine et oublier les sous-domaines. C'est la faille la plus commune après une migration réussie : p=reject sur la racine, rien sur sp/np, et une porte latérale grande ouverte.
• Confondre sp et np. sp couvre les sous-domaines qui existent ; np ceux qui n'existent pas. Les deux sont nécessaires ; l'un ne remplace pas l'autre.
• Attendre pour poser np. Puisqu'il est sans risque, différer np=reject ne fait que prolonger inutilement l'exposition.
• Croire que la politique de sous-domaine règle l'alignement. sp et np disent quoi faire du courrier en échec ; ils ne rendent pas pour autant les vraies sources de sous-domaines alignées — ça reste un travail à part.

En résumé

Amener la racine à reject sans régler les sous-domaines, c'est verrouiller la porte d'entrée en laissant la fenêtre ouverte. sp protège les sous-domaines existants, np ferme les inexistants — et np est un gain gratuit à saisir dès le début du déploiement. Ensemble, ils suppriment l'angle d'attaque « par le côté » qui survit trop souvent à une migration DMARC par ailleurs réussie. Le réflexe à retenir est simple : chaque durcissement d'une racine s'accompagne de sp et np dans la foulée, comme deux gestes indissociables — la racine seule n'est jamais une protection complète.

Pour vérifier qu'une racine et ses sous-domaines sont correctement couverts — y compris les cas inexistants — un passage du domaine dans l'analyseur DMARC gratuit donne la politique effective vue du dehors, exactement comme un destinataire (ou un attaquant) la découvrirait.