Email is a crucial component of any brand’s communication strategy. Knowing how your emails are perceived by recipients and Mailbox Providers (MBPs) is key to maintaining a good sender reputation and ensuring your messages land in the inbox. While there are already several types of Feedback Loops (FBLs) that exist, a new standard, “Email Feedback Reports for DKIM Signers“, or DKIM FBL, aims to streamline the management and registration process for senders and ESP. 

But how, you ask? It starts by leveraging your existing DKIM setup and publishing an accompanying FBL dns record for your domain. This also means any Mailbox Provider that starts to implement this new FBL could automatically see enrollment without any extra effort from the senders-registrations, applications, or accounts to manage. 

Important Note: As of the document’s publication date, this standard is an Internet-Draft and does not yet hold formal standing within the IETF standards process. It is a working document so things may change or implementations may be different than the document.

What is this new (proposed) standard?

This document outlines a proposed mechanism designed to streamline the delivery of user-supplied DKIM FBL reports to the original DKIM signer or other responsible parties. Traditionally, FBLs allow users to tell their Mailbox Provider (MBP) if they disagree with a message’s placement – for instance, if it landed in the spam folder when it should have been in the inbox, or vice-versa. 

The core idea here is to allow MBPs or reporting entities to discover where to send feedback about emails that have been signed with DKIM, directly by utilizing information found within the DKIM signature in the message itself. This aims to reduce the friction involved in getting FBLs to the original DKIM signer(s) by enabling reporters to autonomously discover the feedback destination and reporting preferences

A significant advantage of this DNS-based approach is its flexibility:

  • Feedback destinations can be changed even after messages have been delivered, ensuring that older reports can still be processed if a brand switches to a new report processing provider.
  • It avoids common problems associated with modifying message headers that are already signed by another DKIM signature.
  • For dual-signed messages (e.g., when an Email Service Provider adds its own DKIM signature to a message already signed by the original sender), feedback will be correctly routed to the locations specified in the DNS for both domains, all without potentially breaking the original DKIM signature

What a brand (DKIM signer/domain owner) needs to do

To leverage the DKIM FBL mechanism and gain insights into your email performance, brands or domain owners that sign their emails with DKIM need to configure their DNS records:

  • Publish DNS Records: At a minimum, to ensure you receive all possible feedback, you should publish a record at your top-level domain. This record acts as a catch-all for feedback related to your entire domain, including its subdomains.
    For example, if your domain is example.org, this record would typically be located at _feedback._domainkey.example.org
  • Flexible Subdomain Handling: This standard offers flexibility regarding how you handle subdomains:
    • You can utilize a DNS wildcard (* character) in your record location, such as *._feedback._domainkey.example.org, to cover all subdomains within a given domain.
    • Selector-Specific Feedback (Optional, with a Key Caveat): If your brand requires different reporting destinations for individual DKIM selectors (the s= value in your DKIM signature, which often identifies different sending systems or campaigns), you will need to create a unique DNS record for each specific selector. For instance, for d=example.org and a selector s=contact, the record would be contact._feedback._domainkey.example.org.
    • The Caveat: If you choose to configure selector-specific records, you must explicitly create individual records for each selector in use to ensure proper feedback routing. Otherwise the wildcard record will be used. 
  • DKIM Signature Coverage for Headers: If you choose to use the h (header for signer identification) or hp (header for campaign identification, often used for privacy) attributes in your DNS records, these specific headers must be covered by the DKIM signature that is requesting the report. If the header isn’t properly signed or validated, the feedback receiver (Mailbox Provider) should refuse to generate any reports for those related messages.

How to configure: options, flags, and example

The configuration for Email Feedback Reports for DKIM FBL relies on adding a TXT record in your DNS.

DNS Record Location Structure: The location of this TXT record combines a specific label with your DKIM d= value:

  • For a domain-wide catch-all: _feedback._domainkey.yourdomain.com.
  • For a wildcard covering all subdomains: *._feedback._domainkey.yourdomain.com
  • For a selector-specific record: [selector]._feedback._domainkey.yourdomain.com (e.g., contact._feedback._domainkey.example.org for s=contact).

Required and Optional Tags/Flags within the TXT Record: The DNS record MUST contain the necessary information for a report generator to send feedback to the proper location. These are represented as tags within the TXT record’s value:

  • v: Version – This tag is mandatory and MUST be “DKIMRFBLv1”.
  • ra: Report Address – This specifies the destination for reports. It can be an email address (e.g., mailto:reports@example.com) or an HTTPS URL (e.g., https://reports.example.com/fbl). The address format should adhere to [RFC5321]. It MUST classify the transfer method as either “mailto” or “https”. You can list multiple target addresses, separated by a comma (,). If an rfr (referral) entry is present, ra may be omitted.
  • rfr: Referral Record – An optional field that can refer the report generator(s) to another DNS entry for the feedback destination.
  • c: Content Flag – This flag controls whether original message content is included in the feedback report.
    • c=y (default): The reporting entity SHOULD include message headers and content.
    • c=n: The reporting entity SHOULD remove all content beyond the headers of the original message.
  • h: Header for Signer Identification – An optional field that contains a single header name (e.g., Message-ID, X-Campaign-ID). This header allows the signer to identify the recipient, sender, and campaign for the reported message. If c=n is set, this would represent the minimum amount of information provided. Crucially, this header MUST be covered by the DKIM signature requesting the report.
  • hp: Header for Campaign Identification (Privacy-Preserving) – An optional field containing a single header name (e.g., Campaign-Id). If present, the report generator MAY use this header instead of h if recipient privacy needs to be preserved, even if it means that future sending suppression might be affected. This header MUST also be covered by the DKIM signature
  • f: Format Requested – This specifies the desired format for the feedback report.
    • f=arf (default): Adheres to the “Abuse Reporting Format” ([RFC5965]).
    • f=xarf: Adheres to the “eXtended Abuse Reporting Format” (a JSON format that may evolve over time).
    • Multiple values can be separated by commas (,)

Example DNS TXT Record:

Let’s imagine your domain is example.org, and you want to receive feedback reports via email. You prefer not to receive the full message content, and you identify your campaigns using a custom Campaign-Id header.

Note: At this time XFinity (aka Comcast) has partially deployed this proposed standard, and will only return limited information in the DKIM FBL as part of their test implementation. 

Your DNS record would look like this:

Location: _feedback._domainkey.example.org 

Type: TXT 

Value: “v=DKIMRFBLv1;ra=mailto:fbl@example.org;h=Return-Path;hp=Message-ID;c=n”

This example demonstrates how to specify:

  • v=DKIMRFBLv1: The standard version.
  • ra=mailto:fbl@example.org: Reports should be sent via email to the address fbl@example.org.
  • h=Return-Path:The Mailbox Provider should include the value of the Return-Path header from the original message. This allows you to identify the specific Message related to the feedback and source of the message if you send from multiple platforms.
  • hp=Campaign-Id: The Mailbox Provider should include the value of the Campaign-Id header from the original message. This allows you to identify the specific campaign related to the feedback.
  • c=n: Only headers (specifically, the hp header in this case) should be included in the report, not the full message content.

This Internet-Draft represents a promising step towards standardizing and simplifying the process of receiving valuable email feedback, moving beyond traditional, often proprietary, feedback loops. By leveraging DNS and the existing DKIM infrastructure, it aims to provide senders with critical insights into how their mail is perceived, ultimately helping them maintain sender reputation and improve deliverability.