Email Feedback Loop Headers in 2026: Feedback-ID, CFBL-Address, Gmail, Yahoo, Microsoft, Apple, Comcast

Feedback loops used to feel simple. You enrolled with each major receiver, you got ARF reports back, and you fed those reports into suppression. That mental model is now incomplete.

In 2026, complaint feedback is spread across provider portals, DKIM-domain enrollment, IP reputation dashboards, aggregate campaign dashboards, and at least one large receiver (Apple) that has no FBL at all. The old Return-Path-only assumption, that one external program can tell you what every delivered message proves, no longer holds.

What still works is header observability. A delivered message can tell you which complaint-readiness headers are present, which identity they point at, and whether DKIM signed them. What the message cannot tell you is whether the receiving provider has actually accepted the sender into its complaint program.

Last updated: May 23, 2026.

The short version

Provider or standard	What to look for	What it means	What it does not prove
Gmail	Feedback-ID	Gmail can aggregate complaint signals by sender-defined campaign identifiers in Postmaster Tools.	It does not send you per-recipient ARF complaints.
Yahoo / AOL	DKIM signing domain and CFL enrollment	Yahoo’s Complaint Feedback Loop is DKIM-domain based and sends ARF reports to the enrolled address.	A header alone does not prove the DKIM domain is enrolled.
Microsoft Outlook.com	SNDS and JMRP	Microsoft exposes IP reputation data and junk-message reports through Smart Network Data Services and the Junk Email Reporting Program (JMRP).	A single message header does not prove you have portal access for the sending IPs.
Apple iCloud Mail	No public FBL header	Apple says iCloud Mail does not offer a feedback loop.	You cannot infer Apple complaint visibility from a campaign header.
Comcast	FBL registration, IP-based and DKIM-based	Comcast documents an ARF feedback loop and registration for both IP-based and DKIM-based FBLs.	Header presence still needs matching provider enrollment.
RFC 9477	CFBL-Address and CFBL-Feedback-ID	Experimental header-level discovery for complaint feedback addresses and identifiers.	It is not universal receiver support.

Why Return-Path thinking no longer fits

Return-Path matters for SPF because it is the envelope sender identity. It can also be useful operationally because many ESPs encode bounce handling there. But complaint feedback is no longer something you can reason about from Return-Path alone.

Complaint readiness today depends on four separate layers:

1. Message headers: campaign identifiers such as Feedback-ID, or emerging complaint-feedback headers such as CFBL-Address.
2. Authentication: DKIM has to cover the right domain, and in some models has to sign the feedback headers themselves.
3. Provider enrollment: Gmail Postmaster Tools, Yahoo CFL, Microsoft SNDS/JMRP, Comcast FBL, or no program at all.
4. Provider policy: volume thresholds, privacy redaction, aggregate-only dashboards, IP ownership checks, and changing program requirements.

That is why one delivered message can be evidence, but not a certificate. It can tell you, “this message is instrumented for complaint feedback.” It cannot tell you, “every mailbox provider will send complaints to this address.”

Gmail: Feedback-ID is aggregate, not ARF

Gmail’s FBL model is built around the Feedback-ID header. Google documents the format as:

Feedback-ID: a:b:c:SenderId

The first three fields are optional sender-defined identifiers. The final SenderId is mandatory and should remain consistent across the mail stream. Google uses the identifiers to surface unusual spam rates in the Postmaster Tools FBL dashboard.

Two details matter when you inspect a Gmail-bound message:

• The message should have one coherent Feedback-ID, not a unique value per message. Google explicitly warns against identifiers that are unique for every email, such as a unique Message-ID.
• The mail stream needs DKIM signing by a domain controlled by the sender and verified in Gmail Postmaster Tools.

So the right interpretation is narrow: Feedback-ID tells you the sender instrumented campaign-level complaint grouping for Gmail. It does not mean Gmail will email you a copy of each spam complaint. Gmail’s model is aggregate visibility in Postmaster Tools for qualifying traffic.

Source: Google: Feedback Loop.

Yahoo / AOL: DKIM-domain CFL enrollment

Yahoo’s Complaint Feedback Loop is closer to the traditional ARF model, but it is not Return-Path based. Yahoo says the CFL supports DKIM-signed email and is a domain-based service. If a message is signed with a DKIM key enrolled in the CFL program, Yahoo sends the enrolled address an ARF report when a recipient marks the message as spam.

For header analysis, that means you care about:

• the visible From domain,
• the DKIM d= domain,
• whether the relevant Yahoo CFL enrollment exists for that signing domain,
• and whether the ESP can process ARF reports into suppression logic.

A delivered message can show the DKIM signing domain. It cannot show whether Yahoo has accepted that domain into the CFL program unless you also check the sender’s Yahoo Sender Hub enrollment.

Source: Yahoo: Complaint Feedback Loop.

Microsoft: SNDS and JMRP are IP/account-side systems

Microsoft’s Outlook.com sender tooling is Smart Network Data Services (SNDS). Microsoft describes SNDS as a way to access detailed data about individual IPs and says it includes the Junk Email Reporting Program, which lets senders receive reports when users junk messages.

That makes Microsoft different from a pure message-header model. The important objects are the sending IPs, the Microsoft account with access to those IPs, and JMRP feedback-loop settings.

One timely operational note: Microsoft’s SNDS page currently announces a May 2026 migration to a new URL and API-backed access model, with expected downtime during migration and changes to report access. If Microsoft complaint visibility matters to your program, do not treat old SNDS automation links as permanent.

Source: Microsoft: Smart Network Data Services.

Apple iCloud Mail: no public FBL

Apple’s answer is direct: iCloud Mail does not offer a feedback loop service. Apple’s postmaster page instead emphasizes authenticated mail, subscription hygiene, bounce handling, inactive-subscriber suppression, and acting on SMTP errors.

That means campaign headers can still be useful for your own tracing, but they should not be described as “Apple FBL ready.” If you send meaningful volume to iCloud Mail, your feedback surfaces are authentication results, bounces, engagement, unsubscribe behavior, and delivery errors. Apple complaint reports are not part of that set.

Source: Apple: Postmaster information for iCloud Mail.

Comcast: FBL enrollment still required

Comcast has historically run an ARF-formatted feedback loop, with reports that contain full headers and have Comcast customer addresses removed. Registration supports both IP-based and DKIM-based enrollment, the latter introduced as an experimental DKIM-FBL implementation. Comcast’s postmaster portal at postmaster.comcast.net has been reorganized more than once over the last two years, so confirm the current registration path with Comcast directly before sending production traffic that depends on FBL data.

Comcast is the reminder that some traditional feedback loops still exist, but they live behind provider-specific registration. You can inspect a message for DKIM identity and feedback-related headers, but you still need provider enrollment to actually receive complaints.

Source: Comcast Postmaster (the FBL page has moved; treat the linked landing page as the entry point rather than a stable deep link).

RFC 9477: CFBL-Address is the header-level attempt

RFC 9477 is the interesting standards-adjacent development. It defines an experimental complaint feedback loop address header. The two names to know are:

CFBL-Address: [email protected]; report=arf
CFBL-Feedback-ID: 111:222:333:4444

The intent is discoverability: the message itself can tell a participating mailbox provider where complaint feedback should go and which identifier should appear in privacy-preserving feedback. The RFC also cares about DKIM. In the strict case, where the RFC5322.From domain and the CFBL-Address domain are identical, that domain must be matched by a valid DKIM signature, and both CFBL-Address and CFBL-Feedback-ID must appear in the signature’s h= tag. In the third-party case, an additional DKIM signature matching the CFBL-Address domain is required, so both parties cryptographically agree on who receives feedback.

The direction is right: complaint feedback should be explicit, authenticated, and observable in the message itself.

RFC 9477 is still experimental, though, and it was published through the Independent RFC Stream rather than the IETF standards process. Treat CFBL-Address as a readiness signal, not as proof that Gmail, Yahoo, Microsoft, Apple, Comcast, or any specific mailbox provider will honor it.

Source: RFC 9477: Complaint Feedback Loop Address Header.

How to inspect a message for complaint-feedback readiness

When you analyze headers, do not stop at “is there a feedback header?” Use a checklist.

1. Identify the message identities

Capture these first:

From: Brand <[email protected]>
Return-Path: <[email protected]>
DKIM-Signature: d=example.com; s=news; ...
DKIM-Signature: d=mailer.example.net; s=esp; ...

The Return-Path may explain bounces and SPF. The DKIM d= domains explain who cryptographically signed the message. The visible From domain explains DMARC alignment and what the recipient saw.

2. Look for Gmail campaign feedback

Feedback-ID: spring-sale:retail:newsletter:brand1

Ask:

• Is the final sender identifier stable across the stream?
• Are the earlier identifiers campaign/customer/type fields rather than per-message random values?
• Is the message DKIM-signed by a sender-controlled domain?
• Is that domain verified in Gmail Postmaster Tools?

If yes, the message looks instrumented for Gmail aggregate complaint reporting.

3. Look for RFC 9477 readiness

CFBL-Address: [email protected]; report=arf
CFBL-Feedback-ID: spring-sale:retail:newsletter:brand1

Ask:

• Does the CFBL-Address domain match, descend from, or differ from the visible From domain?
• Is the relevant domain covered by DKIM?
• If the address points to a third party, is there a DKIM signature for both the From domain and the CFBL-Address domain?
• Did the DKIM h= list sign CFBL-Address and CFBL-Feedback-ID?

If yes, the message is better prepared for a provider that chooses to honor RFC 9477.

4. Separate headers from enrollment

Headers live inside the message; enrollment status does not. The header inspection above is only half the job.

• Gmail: verify Postmaster Tools access and Feedback-ID dashboard data.
• Yahoo/AOL: verify CFL enrollment for the DKIM signing domain.
• Microsoft: verify SNDS access to the sending IPs and JMRP settings.
• Comcast: verify FBL registration for the relevant IP or DKIM identity.
• Apple: do not expect an FBL.

What this means for ESPs and domain owners

If you operate an ESP, the goal is not to stamp every possible header and declare victory. The goal is to make complaint handling explainable:

• Use stable campaign/customer/type identifiers for Feedback-ID.
• Avoid per-message identifiers in Gmail’s Feedback-ID fields.
• DKIM-sign feedback-related headers when you add them.
• Keep provider enrollments documented next to the domains and IPs they cover.
• Process ARF complaints into suppression, not just dashboards.
• Treat aggregate Gmail complaint rates as campaign-level risk signals, not subscriber-level suppression events.

If you own a brand domain and send through ESPs, ask a more precise question than “do we have FBL?” Ask:

For each mailbox provider, which identity is enrolled, what evidence can we see in headers, and where does the resulting complaint data land?

That question exposes the real architecture.

A practical example

Suppose this is in a delivered newsletter:

From: Example Co <[email protected]>
Return-Path: <[email protected]>
Feedback-ID: sale42:exampleco:newsletter:espid
CFBL-Address: [email protected]; report=arf
CFBL-Feedback-ID: sale42:exampleco:newsletter:espid
DKIM-Signature: v=1; d=example.com; s=news; h=From:Subject:Feedback-ID:CFBL-Address:CFBL-Feedback-ID:...;
DKIM-Signature: v=1; d=esp.example.net; s=mail; h=From:Subject:Feedback-ID:...;

A good analyzer should say:

• Gmail readiness: likely good header shape, assuming the example.com or ESP-controlled signing domain is verified in Postmaster Tools.
• RFC 9477 readiness: promising, because the CFBL-Address domain matches the visible From organizational domain and DKIM signs the feedback headers.
• Yahoo readiness: cannot be proven from the message; check Yahoo CFL enrollment for the DKIM signing domain.
• Microsoft readiness: cannot be proven from the message; check SNDS/JMRP access for the sending IP.
• Apple readiness: no public FBL exists.
• Comcast readiness: cannot be proven from the message; check Comcast FBL registration.

That is the difference between header observability and provider entitlement.

Use the headers, but do not overclaim them

Complaint feedback matters because it closes the loop between recipient frustration and sender action. The loop is no longer one thing.

In 2026, the honest model is:

• Gmail is Feedback-ID plus Postmaster Tools aggregate data.
• Yahoo/AOL is DKIM-domain CFL enrollment and ARF.
• Microsoft is SNDS/JMRP around IP reputation and account access.
• Apple has no public iCloud Mail FBL.
• Comcast keeps a provider-specific FBL with IP and DKIM registration.
• RFC 9477 is the experimental, header-level attempt at making complaint feedback discoverable in authenticated headers.

Inspect the message, confirm the headers, check the signatures, then verify the external enrollment. If you want a quick local inspection, paste a message into the DMARCTrust Email Header Analyzer; the output is evidence about the message, not a substitute for provider-side FBL enrollment.