en_GB ENfr_FR FR
feedback loop dns dkim email

New Feedback Loop (FBL) mechanism via DNS

—

par

Pierre-Yves Dubreucq
dans

Published on March 3, 2025, Alex Brotman from Comcast proposed an IETF draft, “draft-brotman-dkim-fbl-04”. It introduces a new standardized method that allows mailbox providers to send user feedback directly to DKIM signers. Why does this matter? And how does it actually work? Let’s break it down.

🔁 What Is a Feedback Loop (FBL)?

A Feedback Loop allows users to report an email as spam or misclassified (ham). This feedback is then sent back to the sender so they can take action: stop sending to a recipient, fix an error, or improve their sending strategy.

Traditionally, FBLs relied on manual registration systems, where senders had to declare IP ranges or DKIM domains in advance.
This draft proposes a more dynamic and automated approach, leveraging DNS and DKIM signatures.

🧠 The Key Idea: Publishing an FBL Address via DKIM DNS

The draft introduces a new DNS record type that allows DKIM-signing domains to declare where and how they want to receive FBL reports.

For example, a domain like example.org could publish the following DNS entry:

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

Where:

  • v=DKIMRFBLv1 → identifies the record version.
  • ra= → specifies where the reports should be sent (email or HTTPS).

Advantages of this approach:

  • No header modifications → avoids breaking DKIM signatures.
  • Dynamic configuration → destinations can be updated after emails are sent.
  • Multiple signers support → works seamlessly with dual-signed messages.

📍 Where to Publish the DNS Record

According to the draft, the record location depends on the DKIM configuration:

  • Default catch-all: _feedback._domainkey.example.org
  • Per-DKIM-selector setup: contact._feedback._domainkey.example.org
  • Wildcard approach for all selectors: *._feedback._domainkey.example.org

✉️ What Does the Report Contain?

Domains can specify what type of data they want to receive:

  • Full message → default (c=y)
  • Headers only → c=n
  • Campaign-based aggregation → via hp=Campaign-Id
  • Recipient-based correlation → via h=HeaderName
  • Preferred report format:
    • ARF (Abuse Reporting Format – RFC 5965)
    • XARF (JSON-based modern format)

🧪 Concrete Examples

Here are three practical examples from the draft, showing different FBL configurations.

Example 1: Simple FBL via Email

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

How it works:

  • example.org publishes a DNS record for receiving FBL reports.
  • Reports are sent to fbl@example.org.
  • By default:
    • The entire message is included (c=y).
    • Reports are sent in ARF format.

Use case:
Perfect for senders who want full complaint reports without any filtering.

Example 2: Header-Only FBL with Campaign-Based Aggregation

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

How it works:

  • Reports are sent to fbl@example.org.
  • c=n → only headers are sent, excluding message content.
  • hp=Campaign-Id → reports are grouped by campaign.

Use case:
Ideal for email marketing platforms that want privacy-friendly reporting while monitoring campaign performance.

Example 3: HTTPS-Based FBL with Dynamic Parameters

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

How it works:

  • Reports are sent via HTTPS to https://fbl.example.org/dkim-fbl.
  • track=xyz → enables tracking of report sources.
  • c=n → headers only, no message body.
  • h=Message-Id → identifies the reported message.
  • hp=Feedback-Id → links the report to a specific internal feedback ID.

Use case:
Designed for modern infrastructures that want automated report ingestion via APIs.

🔐 Security Considerations

  • Any headers referenced in the DNS record (h or hp) must be DKIM-signed and valid.
  • If the reporting address (ra) points to a different domain, an additional DNS verification is required to authorize external report receivers.

Example of cross-domain authorization:

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

🚚 Report Delivery Methods

Two delivery mechanisms are supported:

  1. Email (mailto):
    Traditional ARF/XARF delivery to a mailbox.
  2. HTTPS (POST):
    Allows automated ingestion by modern systems and APIs.

🧩 Why This Matters

This new mechanism offers:

  • Dynamic discovery of FBL endpoints.
  • Simpler onboarding → no manual registration.
  • Better interoperability between mailbox providers and senders.

Ultimately, it helps:

  • Reduce spam complaints,
  • Improve email deliverability,
  • Strengthen collaboration between mailbox providers and senders.

💡 In short: This IETF draft introduces a modern, DNS-based, DKIM-driven way to manage FBLs. If you send emails at scale or operate a DKIM-signed domain, this is a standard you’ll want to watch closely.