La balise np de DMARC : verrouiller les sous-domaines qui n'existent pas

_dmarc.exemple.fr.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@exemple.fr"

np vs sp vs p : qui couvre quoi

C'est la confusion la plus fréquente. Les trois balises se répartissent les cas :

• p — la politique du domaine racine lui-même (exemple.fr).
• sp — la politique des sous-domaines qui existent (mail.exemple.fr, news.exemple.fr).
• np — la politique des sous-domaines qui n'existent pas (facture-truc.exemple.fr).

Avant DMARCbis, seuls p et sp existaient. Un attaquant qui visait un sous-domaine inexistant tombait dans une zone grise. np supprime cette zone grise. En pratique, pour un domaine bien tenu, on règle souvent les trois sur la même valeur stricte : p=reject; sp=reject; np=reject.

Pourquoi c'est un gain rapide et prioritaire

La plupart des durcissements DMARC demandent du travail : inventorier les sources, les aligner, surveiller les rapports (voir atteindre p=reject). np, c'est l'inverse : zéro inventaire, zéro risque, effet immédiat. Comme aucun service légitime n'émet depuis un sous-domaine inexistant, il n'y a rien à casser. C'est pour ça qu'on le recommande tôt — souvent dès que le domaine racine est sain, avant même d'avoir terminé la montée vers p=reject sur l'ensemble.

C'est particulièrement vrai pour les organisations à forte surface de sous-domaines — banques, grands groupes, secteur public — qui exploitent des dizaines de sous-domaines réels et en laissent autant d'imaginables. Sur ce terrain, np=reject ferme d'un coup une catégorie entière d'attaques. On détaille le cas financier dans les banques.

Quelques précisions utiles

• np n'est interprété que par les destinataires à jour de DMARCbis. Pendant la transition, certains l'ignoreront encore — sans dommage, ils retombent sur le comportement antérieur. Rien à perdre à le publier dès maintenant.
• np ne remplace pas sp. Les deux sont nécessaires : sp pour les vrais sous-domaines, np pour les fantômes. En omettre un laisse une moitié de la surface exposée.
• Le « inexistant » se juge via le DNS. Un sous-domaine est considéré inexistant s'il ne résout pas (pas d'enregistrement). C'est là qu'intervient le DNS Tree Walk, le mécanisme par lequel DMARCbis détermine l'arborescence des domaines.
• Les domaines parqués adorent np. Un domaine détenu mais d'où rien ne part jamais devrait être en p=reject; np=reject — c'est aussi vrai pour les domaines dormants.

Comment vérifier que c'est en place

Une fois np=reject publié, deux contrôles :

1. Relire l'enregistrement avec un analyseur pour confirmer que la balise est bien présente et que la syntaxe est valide — notre analyseur gratuit le fait en quelques secondes.
2. Surveiller les rapports agrégés : un sous-domaine inexistant usurpé apparaîtra désormais avec une disposition reject plutôt que de se faufiler. Leur lecture s'apprend dans comment lire les rapports agrégés.

Un scénario d'attaque concret

Déroulons une attaque réelle pour voir np à l'œuvre. Une entreprise, exemple.fr, a bien fait son travail : p=reject sur le domaine racine, sp=reject pour ses sous-domaines connus (mail.exemple.fr, news.exemple.fr). Elle se croit protégée.

Un attaquant prépare une campagne de phishing. Plutôt que d'usurper exemple.fr (refusé par p=reject) ou mail.exemple.fr (refusé par sp=reject), il choisit From: facturation@comptes.exemple.fr. Ce sous-domaine comptes.exemple.fr n'existe pas dans le DNS d'exemple.fr. Sans balise np, beaucoup de destinataires se retrouvent dans une zone grise : faut-il appliquer la politique racine ? celle des sous-domaines ? rien ? Selon l'implémentation, le message peut passer — et atterrir dans la boîte de la victime avec une adresse parfaitement crédible.

Maintenant, la même attaque avec np=reject publié : le destinataire constate que comptes.exemple.fr n'a pas d'enregistrement (via le DNS Tree Walk), applique la politique np, et refuse le message. L'attaque échoue, sans qu'exemple.fr ait eu à créer ou surveiller le moindre sous-domaine fictif. C'est toute la valeur de np : couvrir l'infini des sous-domaines qui n'ont jamais été créés.

Réglages recommandés selon les cas

• Domaine d'envoi normal, déjà en p=reject : p=reject; sp=reject; np=reject. Le trio strict, sans état d'âme.
• Domaine encore en montée (p=quarantine) : np=reject se pose déjà, indépendamment de p. Aucun courrier légitime ne part d'un sous-domaine inexistant, donc aucun risque à le verrouiller tout de suite.
• Domaine purement « corporate » sans sous-domaines d'envoi : np=reject est presque obligatoire — c'est précisément ce genre de domaine qu'on usurpe via des sous-domaines inventés.
• Domaine parqué (aucun envoi) : p=reject; sp=reject; np=reject partout. Rien ne sort, tout doit être refusé.

Questions fréquentes sur np

np=reject peut-il bloquer du courrier légitime ? Non, par construction. La balise ne s'applique qu'aux sous-domaines sans enregistrement DNS. Or un service légitime qui envoie depuis un sous-domaine a forcément des enregistrements (au minimum pour SPF/DKIM). S'il en a, le sous-domaine « existe » et relève de sp, pas de np.

Que se passe-t-il si je crée plus tard un vrai sous-domaine ? Dès qu'il a des enregistrements DNS, il « existe » et passe sous le régime de sp. Reste simplement à l'authentifier (SPF/DKIM) avant de l'utiliser pour envoyer — comme n'importe quelle source.

np est-il obligatoire ? Non, rien n'est obligatoire dans DMARCbis. Mais c'est l'une des nouveautés au meilleur rapport bénéfice/risque : effet réel contre le phishing, zéro risque, une seule balise.

Tous les destinataires honorent-ils déjà np ? Pas encore tous — l'adoption de DMARCbis est progressive. Ceux qui ne le connaissent pas l'ignorent simplement (sans dommage). Plus l'écosystème se met à jour, plus la protection se renforce. Aucune raison d'attendre pour publier.

np et la gouvernance des sous-domaines

Au-delà de la balise elle-même, np est l'occasion de poser une question rarement traitée : qui crée des sous-domaines dans l'organisation, et qui le sait ? Dans beaucoup de structures, n'importe quelle équipe peut faire pointer campagne-ete.exemple.fr vers un prestataire, sans prévenir la sécurité. Chaque sous-domaine réel est une surface à authentifier ; chaque sous-domaine non créé est une surface à refuser. np=reject règle la seconde catégorie d'un coup, mais la première demande une vraie discipline : inventorier les sous-domaines d'envoi, les aligner, et garder sp cohérent.

Un bon réflexe : traiter la liste des sous-domaines comme un actif de sécurité, au même titre que l'inventaire des sources d'envoi. Les rapports agrégés aident ici aussi — ils révèlent du courrier émis depuis des sous-domaines oubliés, légitimes ou non. Une fois cette cartographie faite, le couple sp/np devient simple à régler : sp strict pour ce qui existe et envoie, np=reject pour tout le reste.

C'est particulièrement vrai quand BIMI est visé à terme : afficher un logo suppose une marque cohérente et une politique stricte sur l'ensemble de l'espace de noms. Un sous-domaine usurpable est une faille dans ce récit de confiance. Verrouiller les sous-domaines inexistants avec np est donc autant une mesure anti-phishing qu'une brique de cohérence de marque.

En bref

La balise np de DMARCbis fixe la politique des sous-domaines qui n'existent pas — une faille que sp ne couvrait pas. Le réglage np=reject est sans risque (rien de légitime ne part d'un sous-domaine inexistant) et immédiatement efficace contre une catégorie entière de phishing. Trois balises à distinguer : p (racine), sp (sous-domaines réels), np (sous-domaines fantômes).

Thomas pose la bonne politique

np, sp, p : trois balises, une seule à mal régler pour laisser une porte ouverte. Thomas, le RSSI virtuel, génère l'enregistrement DMARCbis complet et cohérent pour un domaine — racine, sous-domaines réels et inexistants — et vérifie sur les rapports qu'aucune source légitime n'est touchée avant de durcir.

Analyser un domaine gratuitement ou créer un compte. Pour le contexte complet de DMARCbis, voir ce nouveau standard expliqué simplement.