Sous-domaines et wildcard : ce qu'héritent (ou pas) les noms secondaires

Un domaine ne se résume pas à son nom de base. Les sous-domaines utilisés pour les envois marketing (news.example.com), les notifications applicatives (app.example.com), les bounces (bounce.example.com) ou simplement créés par des outils tiers obéissent chacun à des règles d'héritage différentes selon le mécanisme. Comprendre ce qui se propage et ce qui ne se propage pas évite deux erreurs symétriques : croire un sous-domaine protégé alors qu'il ne l'est pas, et laisser un wildcard DNS répondre à la place d'enregistrements qui n'ont jamais été publiés.

SPF : aucun héritage#

Un enregistrement SPF ne vaut que pour le nom exact sur lequel il est publié. Si example.com publie v=spf1 ... -all et qu'un message part avec MAIL FROM sur news.example.com, le routeur interroge news.example.com et, faute d'enregistrement, obtient le résultat none. Chaque sous-domaine utilisé en MAIL FROM ou en HELO doit donc disposer de son propre enregistrement. Inversement, un sous-domaine qui n'envoie jamais doit publier v=spf1 -all pour fermer la porte explicitement.

news.example.com.    IN TXT  "v=spf1 include:_spf.esp.example.net -all"
bounce.example.com.  IN TXT  "v=spf1 include:_spf.esp.example.net -all"
intranet.example.com. IN TXT "v=spf1 -all"

DKIM : tout dépend du d=#

Une signature DKIM est validée avec la clé publiée sous <sélecteur>._domainkey.<d=>. Un prestataire qui signe avec d=news.example.com a besoin que la clé soit publiée sous _domainkey.news.example.com, et cette signature s'aligne avec un From: sur news.example.com ou, en mode relaxed, sur example.com. L'étiquette t=s dans l'enregistrement de clé interdit l'usage de la clé pour un sous-domaine du d= ; en son absence, une clé publiée sur example.com peut servir à signer d=example.com pour des messages dont le From: est sur un sous-domaine.

DMARC : la politique se propage, avec sp= et np=#

DMARC est le seul des trois mécanismes à prévoir un héritage. Un routeur cherche _dmarc.news.example.com ; s'il n'existe pas, il applique la politique du domaine organisationnel example.com en utilisant la valeur de sp= (sous-domaines) ou, à défaut, celle de p=. DMARCbis ajoute np=, qui s'applique aux sous-domaines inexistants au sens DNS, ce qui permet par exemple p=quarantine; sp=quarantine; np=reject.

_dmarc.example.com.       IN TXT  "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com"
_dmarc.news.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-news@example.com"

Un sous-domaine qui publie sa propre politique l'emporte sur sp=. C'est le bon outil pour isoler un flux : un prestataire marketing peut avoir sa politique et ses rapports distincts sans toucher au domaine principal. À l'inverse, un domaine en p=reject sans sp= protège déjà tous ses sous-domaines, existants ou non.

Wildcard DNS : une réponse pour tout nom inexistant#

Un enregistrement *.example.com répond pour tout nom qui n'existe pas sous example.com, à n'importe quelle profondeur, sauf si un nom plus proche existe. Les conséquences pour le courrier sont souvent involontaires :

• Un *.example.com IN MX rend n'importe quel sous-domaine inventé routable, et un * IN A fait de même pour les mécanismes SPF a.
• Un *.example.com IN TXT "v=spf1 -all" est parfois utilisé pour fermer SPF sur tous les sous-domaines : cela fonctionne pour les noms inexistants, mais pas pour les sous-domaines qui ont déjà un enregistrement de type différent (un A sans TXT, par exemple) ; ceux-ci existent au sens DNS et le wildcard ne s'applique plus.
• Le même wildcard TXT répond aussi aux requêtes _dmarc.n-importe-quoi.example.com et selecteur._domainkey.n-importe-quoi.example.com. Les vérificateurs DMARC et DKIM ignorent les enregistrements qui ne commencent pas par la bonne version, mais certains outils de diagnostic signalent une anomalie.
• Un wildcard CNAME est encore plus envahissant : il redirige toute requête, y compris _dmarc et _domainkey, vers la cible.

La règle pratique : utiliser un wildcard uniquement pour l'usage web qui le justifie, et vérifier systématiquement, avec dig, ce qu'un nom aléatoire sous le domaine renvoie pour les types MX, A, TXT et CNAME.

Sous-domaines inexistants et usurpation#

Un attaquant peut envoyer avec From: compta@facture.example.com même si facture.example.com n'a jamais existé. Sans DMARC sur le domaine organisationnel, rien ne l'en empêche. Avec p=reject ou sp=reject, le message est rejeté puisqu'aucune authentification ne peut s'aligner. C'est l'argument principal pour ne pas laisser sp=none, et pour publier np=reject dès que les vérificateurs le prennent en charge.

Bonnes pratiques#

1. Tenir un inventaire des sous-domaines qui envoient, avec pour chacun : usage, MAIL FROM, sélecteurs DKIM, prestataire.
2. Publier SPF sur chaque sous-domaine émetteur et v=spf1 -all sur ceux qui n'émettent pas.
3. Publier un _dmarc dédié sur les sous-domaines à flux distinct, avec leurs propres rapports.
4. Fixer sp= explicitement sur le domaine organisationnel, au moins au niveau de p=.
5. Ne pas déléguer un sous-domaine entier à un prestataire sans vérifier quelles politiques il y publie.
6. Pour la réception, se rappeler que MTA-STS s'applique par domaine : un sous-domaine qui reçoit du courrier a besoin de sa propre politique.

Ce que SenderRadar en montre#

SenderRadar présente les sous-domaines associés à un domaine lorsqu'ils sont identifiables, l'état de SPF, DKIM et DMARC sur chacun, la politique de sous-domaine effective héritée du domaine organisationnel, et signale les wildcards DNS susceptibles d'interférer avec les enregistrements d'authentification. SenderRadar s'appuie sur sa propre base d'analyse pour mettre ces éléments en regard de la configuration du domaine principal.

Références#

• RFC 7208 – SPF
• RFC 6376 – DKIM
• RFC 7489 – DMARC et DMARCbis (groupe de travail DMARC)
• RFC 4592 – The Role of Wildcards in the Domain Name System