en_GB ENfr_FR FR
feedback loop dns dkim email

Nouveau mécanisme de Feedback Loop (FBL) via DNS

—

par

Pierre-Yves Dubreucq
dans

Publié le 3 mars 2025, Alex Brotman, de Comcast, a proposé un brouillon à l’IETF “draft-brotman-dkim-fbl-04”. Il propose une nouvelle méthode normalisée pour permettre aux fournisseurs de messagerie de signaler des retours d’utilisateurs directement aux signataires DKIM. Pourquoi est-ce important ? Et comment cela fonctionne-t-il concrètement ? On vous explique.

🔁 Le Feedback Loop, c’est quoi ?

Le principe d’un Feedback Loop (FBL), c’est de permettre aux utilisateurs de signaler un email qu’ils considèrent comme indésirable (spam) ou, au contraire, mal classé (ham). Ce retour est ensuite transmis à l’expéditeur pour qu’il puisse réagir : cesser l’envoi à un destinataire, corriger une erreur ou ajuster sa stratégie d’envoi.

Jusqu’à présent, ces FBL passaient souvent par des systèmes d’inscription spécifiques, basés sur des plages d’IP ou des domaines DKIM connus à l’avance. Le nouveau draft propose une alternative plus souple et automatisée, grâce au DNS.

🧠 L’idée clé : déclarer une adresse de FBL via le DNS DKIM

Le document introduit un nouveau type d’enregistrement DNS que les domaines signataires DKIM peuvent publier pour indiquer où et comment ils souhaitent recevoir des rapports FBL.

Concrètement, un domaine comme example.org peut publier une entrée DNS du type :

_feedback._domainkey.example.org TXT "v=DKIMRFBLv1;ra=mailto:fbl@example.org"

Ici :

  • v=DKIMRFBLv1 indique la version du format.
  • ra= fournit l’adresse vers laquelle les rapports doivent être envoyés (email ou URL HTTPS).

Cette approche permet de :

  • ne pas modifier les en-têtes des messages (et risquer de casser la signature DKIM),
  • changer de destination de rapport même après l’envoi du message (mise à jour DNS),
  • gérer des rapports pour plusieurs signatures (cas fréquent avec des relais SMTP intermédiaires ou des plateformes d’envoi).

📍 Où publier l’entrée DNS ?

Selon le draft :

  • L’entrée de base est :
    _feedback._domainkey.example.org
  • On peut aussi publier une version spécifique à un selector DKIM :
    contact._feedback._domainkey.example.org

Et même utiliser des jokers :
*._feedback._domainkey.example.org pour englober tous les selectors.

✉️ Que contient le rapport ?

Le domaine destinataire peut indiquer s’il souhaite recevoir :

  • le message complet (c=y par défaut),
  • uniquement les en-têtes (c=n),
  • un champ spécifique (h=HeaderName) ou même un identifiant de campagne (hp=Campaign-Id) pour du reporting agrégé.

Les formats supportés sont :

  • ARF (Abuse Reporting Format – RFC 5965),
  • XARF, un format JSON plus moderne.

🔐 Et la sécurité dans tout ça ?

Le draft impose que les en-têtes utilisés pour identifier les campagnes ou les destinataires (avec h ou hp) soient signés et validés par DKIM.

Autre précaution : si l’adresse de destination du rapport (ra) pointe vers un domaine tiers (autre que celui du DKIM d=), une vérification DNS supplémentaire est nécessaire pour prouver que ce tiers est autorisé à recevoir les rapports.

Exemple :

example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1"

🚚 Comment sont livrés les rapports ?

Deux modes sont proposés :

  • mailto
  • https: via POST

Le draft prévoit même une option Feedback-Type pour indiquer la nature du rapport (abuse, fraud, etc.).

🧪 Exemple concret

Voici trois exemples tirés du brouillon IETF pour illustrer comment configurer le DNS et comment les rapports FBL seraient envoyés.

Exemple 1 : FBL simple par email

_feedback._domainkey.example.org TXT "v=DKIMRFBLv1;ra=mailto:fbl@example.org"

Comment ça marche :

  • Le domaine example.org publie un enregistrement DNS indiquant qu’il souhaite recevoir les rapports FBL.
  • L’attribut ra=mailto:fbl@example.org précise que les rapports doivent être envoyés à cette adresse email.
  • Aucun champ optionnel (c, h, hp, f) n’est défini, donc :
    • Par défaut, le message complet sera inclus dans le rapport (c=y).
    • Le format du rapport sera ARF (f=arf par défaut).

Cas d’usage :
Parfait pour un expéditeur qui veut recevoir tous les signalements d’abus sans filtrage ni traitement particulier.

Exemple 2 : FBL sans contenu et agrégé par campagne

_feedback._domainkey.example.org TXT "v=DKIMRFBLv1;ra=mailto:fbl@example.org;c=n;hp=Campaign-Id"

Comment ça marche :

  • Le domaine example.org demande à recevoir les rapports à fbl@example.org.
  • L’attribut c=n indique que seules les en-têtes (et non le contenu des emails) doivent être transmises.
  • L’attribut hp=Campaign-Id signifie que les rapports sont regroupés par identifiant de campagne.
  • Cela permet de faire du reporting agrégé : l’expéditeur sait qu’une campagne spécifique a généré des plaintes, mais ne voit pas les emails individuels des plaignants.

Cas d’usage :
Idéal pour les plateformes d’email marketing ou les expéditeurs soucieux de protéger la vie privée des destinataires.

Exemple 3 : FBL via HTTPS avec paramètres dynamiques

_feedback._domainkey.example.org TXT "v=DKIMRFBLv1;c=n;ra=https://fbl.example.org/dkim-fbl?track=xyz;h=Message-Id;hp=Feedback-Id"

Comment ça marche :

  • Les rapports FBL doivent être envoyés via HTTPS à https://fbl.example.org/dkim-fbl.
  • Le paramètre track=xyz permet de tracer l’origine du rapport.
  • L’attribut c=n indique que seul le minimum d’informations est transmis.
  • h=Message-Id précise quel en-tête identifier pour lier la plainte à un message unique.
  • hp=Feedback-Id permet d’utiliser un identifiant de retour spécifique pour des traitements automatisés.

Cas d’usage :
Adapté aux infrastructures modernes qui veulent automatiser la gestion des plaintes via API, sans traitement manuel.

🧩 Pourquoi c’est utile ?

Ce système offre :

  • Une découverte dynamique du point de contact pour les rapports,
  • Moins de dépendance à des inscriptions manuelles,
  • Une compatibilité directe avec l’écosystème DKIM.

Il favorise une meilleure rétroaction, moins de spam perçu par les utilisateurs, et une plus grande responsabilité des expéditeurs.

💡 En résumé : ce draft propose une manière simple, décentralisée et moderne de gérer les FBL via DKIM et DNS. Si vous envoyez des emails en volume, ou gérez un domaine signé DKIM, c’est une évolution à suivre de près.