Résumé

  • Le benchmark de Palisade, présenté le 1er septembre sur Internet Society Pulse, trouve un enregistrement DMARC valide pour 58,1 % des 99 300 domaines observés.
  • Parmi ces domaines publiant DMARC, 20,7 % n’indiquent pas d’adresse de rapports agrégés. Ce constat ne suffit ni à juger un prestataire ni à connaître le travail réellement confié par son client.

Qui s’occupe du domaine lorsque la messagerie fonctionne déjà ? La question paraît administrative. Elle devient très concrète quand un nouvel outil de facturation envoie des courriels au nom de l’entreprise, alors que l’hébergeur ne gère que les boîtes des salariés.

Le billet publié le 1er septembre par Internet Society Pulse donne une raison d’ouvrir ce dossier. Samuel Chenard, CEO et cofondateur de Palisade, y présente les résultats de son entreprise. Il s’agit d’une contribution invitée : Internet Society précise que ces opinions ne sont pas nécessairement les siennes.

Ce que le DNS permet de compter

Le benchmark correspondant porte sur 99 300 domaines observés le 14 août, pendant huit minutes. Palisade y dénombre 57 732 publications DMARC valides, soit 58,1 % de l’échantillon. Parmi ces publications, 36 938 demandent une mise en quarantaine ou un rejet, soit 64 %. Et 11 959, soit 20,7 %, ne mentionnent pas d’adresse destinée aux rapports agrégés.

Ces pourcentages n’ont donc pas tous le même dénominateur. Ils décrivent des enregistrements publics, pas des contrats ni le fonctionnement interne des entreprises. Nous n’avons pas reproduit le scan. Les domaines proviennent d’un classement de sites populaires, qui ne représente pas toute la messagerie professionnelle.

Le classement par fournisseur appelle une autre réserve : les enregistrements MX montrent l’infrastructure de réception visible. Une passerelle peut masquer la plateforme de boîtes située derrière elle. Même corrigées des différences de rang des sites, les comparaisons restent observationnelles. Elles ne prouvent pas l’effet causal d’un hébergeur.

Une prestation à définir

La portée utile de l’enquête est ailleurs : acheter des boîtes ne permet pas de déduire qui tient à jour les expéditeurs autorisés, examine les retours et décide des modifications de politique.

RFC 9989 décrit ces travaux autour de DMARC. Le propriétaire du domaine peut être un prestataire agissant pour son client au sens de la spécification. L’externalisation n’est donc pas le problème ; une offre gérée peut justement réunir les compétences nécessaires. Encore faut-il savoir quelles tâches elle comprend.

Une politique p=none n’est pas, à elle seule, un aveu de négligence. Le RFC la recommande pour commencer à observer les expéditeurs légitimes et corriger leur authentification avant de durcir le traitement demandé. Une messagerie peu fréquente peut nécessiter une observation longue.

L’absence d’adresse de rapport dans le DNS ne prouve pas davantage l’absence de toute surveillance. Sa présence ne prouve ni la réception ni la lecture des rapports : RFC 9990 prévoit notamment des conditions d’autorisation du destinataire externe et de livraison. Le scan laisse donc précisément hors champ l’organisation du travail.

Le partage ne se fait pas tout seul

La distinction proposée par Lu Heng entre une spécification commune limitée et les décisions locales éclaire ce cas. C’est ici une grille de lecture éditoriale, pas une obligation supplémentaire de l’IETF. Le protocole fournit un langage commun ; il ne rédige pas le périmètre de chaque prestation.

Une entreprise peut confier la messagerie, le DNS et l’analyse des rapports à plusieurs acteurs, ou à un seul. Dans les deux cas, il reste à attribuer l’inventaire des expéditeurs, les corrections, le suivi et l’autorisation de changer de politique. Un contrat d’hébergement peut couvrir tout cela. Son intitulé ne suffit pas à l’établir.

Sources