What ESPs use Validity's FBLs and what is the status of Comcast data and DKIM FBL implementation?
Published 11 May 2025
Updated 1 Aug 2026
12 min read
Summarize with
Updated on 5 Aug 2026: We updated this guide for the expired DKIM FBL draft, Comcast's documented payload limits, and the ongoing Yahoo Mail migration.
The direct answer is that there is no complete public count or public roster of ESPs that have signed up for Validity's FBLs. Validity's public FBL information is mainly a mailbox provider and ISP coverage story, not an ESP adoption report. Treat any claim about "how many ESPs" as unverified unless the ESP names the feed, the mailbox provider, and the complaint handling path.
The specific names worth separating are AWeber, Twilio SendGrid, and Comcast. AWeber is a concrete ESP name to ask about for DKIM FBL support because it has shown willingness to implement the DNS-based DKIM FBL path. Twilio SendGrid is useful because its public Comcast guidance says Comcast complaints route through the Validity FBL path. Comcast is the mailbox provider that matters most here: Comcast has traditional FBL data available through Validity, and its DKIM FBL path is partial, with limited returned data.
Short answer
- ESP roster: There is no complete public ESP list for Validity FBL adoption, so ask each ESP for its specific feeds.
- Comcast data: Comcast complaint data exists through the Validity path, but DKIM FBL output is limited in the documented partial implementation.
- DKIM FBL: Revision 06 expired on July 10, 2026 and is not an RFC, so production behavior still depends on each mailbox provider.
What is publicly known
The most useful public list is not an ESP list. It is the Validity Universal Feedback Loop mailbox provider list. The Spam Resource list names more than 30 mailbox providers and ISPs supported through Validity's interface, including Comcast, Cox, Fastmail, Gandi, SFR, Telstra, UOL, Virgin Media, Yandex, and Ziggo.
That list shows where a sender or ESP can seek complaint feeds. It does not show which ESPs have enrolled, which customers are covered, whether complaint data is parsed into suppression workflows, or whether a DKIM-based discovery method is live.
|
|
|
|---|---|---|
 Validity | MBP FBL hub | Provider roster |
 Comcast | Included | Key feed |
 AWeber | Ask first | DKIM FBL interest |
 SendGrid | Comcast path | Validity routed |
 Yahoo | Separate CFL | Not uFBL |
Practical status of the main names in this question.
Validity Universal Feedback Loop Service dashboard with provider enrollment rows.
Why this is not an ESP roster
The confusion comes from the word "use." A mailbox provider uses Validity when it sends feedback through that managed FBL network. An ESP uses Validity only if it enrolls, confirms the right domains, receives reports, parses them, and applies suppression or routing logic.
Those are different questions. A sender can be covered by Comcast's Validity feed through one ESP and uncovered through another ESP. A large ESP can also support one customer's dedicated IPs while leaving shared pools, customer-branded DKIM domains, or older sending stacks outside the workflow.
- Provider support: Validity's list answers which mailbox providers and ISPs participate in its managed FBL network.
- ESP enrollment: An ESP must confirm the domains or IPs it controls and process reports into customer suppression systems.
- Customer coverage: A sender still needs proof that its own IPs, DKIM domains, and complaint mailboxes are covered.
- Operational value: The feed matters only when complaints are tied back to campaigns, templates, lists, or customer accounts.
What Validity coverage tells you
- Mailbox provider: The complaint source has a path into Validity's network.
- Enrollment route: A sender or ESP can request access through that managed flow.
- Provider scope: The list is about report generators, not report consumers.
What ESP adoption proves
- Domain control: The ESP has confirmed the domains or IPs used for the feed.
- Data handling: Reports are parsed and mapped to a recipient, account, or campaign.
- Suppression flow: Complaints drive suppression fast enough to lower repeat complaints.
Comcast data status
Comcast is the piece most senders care about because its complaint volume is often more meaningful than the small regional feeds. Traditional Comcast complaints use ARF reports with full headers and scrubbed customer addresses. Comcast's partial DKIM FBL implementation is different: it returns at most two headers, base64-encoded, and the output is not meant to be ARF-compliant.
Revision 06 of draft-brotman-dkim-fbl was published on January 6, 2026 and expired on July 10, 2026. It has not become an RFC and has no formal standing in the IETF standards process. Mailbox providers can still test the proposal, but its syntax and behavior can change in a later revision.
The EmailKarma DKIM note describes Comcast/Xfinity as partially deployed. Comcast's current postmaster guidance adds the useful detail: one returned header is always Message-ID, the sender can choose one other header, and domain reputation and age affect whether reports are delivered. Do not build complaint automation that assumes full Comcast DKIM FBL payloads.
Comcast caveat
Publishing DKIM FBL DNS records does not mean Comcast will immediately send reports for every complaint. Treat the data as a limited signal until your own reports prove the coverage and payload.
- Confirm feed: Ask whether your ESP receives traditional Comcast complaints through Validity today.
- Check payload: Ask which DKIM FBL header accompanies Message-ID and whether it identifies a recipient or campaign.
- Measure volume: Compare report counts against Comcast delivery volume before trusting the feed.
How DKIM FBL works
DKIM FBL changes the discovery problem. Instead of forcing every sender and ESP to complete a separate FBL enrollment with every mailbox provider, a receiver can inspect a valid DKIM signature, take the signing domain and selector, and look up a DNS record that says where feedback should go. A message with multiple valid DKIM signatures can produce lookups for more than one signer.
That means the DKIM signature becomes more than an authentication check. It becomes the routing key for complaints. Before publishing DKIM FBL records, verify that real outbound mail signs with the expected domain and selector. A quick DKIM checker pass is useful, but also inspect a delivered message because ESPs sometimes sign differently by stream, subaccount, or region.
The domain-wide record applies only to the exact DKIM d= domain. It does not cover subdomains with different d= values. A wildcard at *._feedback._domainkey.example.org is a selector fallback for example.org, not a subdomain wildcard.
Domain-wide DKIM FBL DNS recordtext
Name: _feedback._domainkey.example.org Type: TXT Value: v=DKIMRFBLv1;ra=mailto:fbl@example.org;c=n
Start with a domain-wide record for each signing domain. Selector-specific records make sense when different systems need different report destinations. That usually applies to ESPs, large senders, and platforms with customer-specific signing domains.
Selector-specific DKIM FBL DNS recordtext
Name: s1._feedback._domainkey.example.org Type: TXT Value: v=DKIMRFBLv1;ra=mailto:fbl@example.org;h=X-Campaign-ID;c=n
If the record uses h or hp to request an identifying header, the relevant DKIM signature must sign that header. Use h when the report processor needs an identifier that can support recipient suppression. Use hp for a campaign-level identifier when recipient privacy takes priority. An external ra destination that does not align with the DKIM signing domain also needs the proposal's confirmation DNS record before reports can be sent safely.
DKIM FBL flow: user complaint, DKIM check, DNS lookup, report route, suppression.
The main trap is assuming DNS publication equals useful data. The receiving provider still decides whether to generate a report, how much content to include, and whether the report is sent by email or HTTPS. The expired draft describes controls for those choices, but each implementation decides the actual report behavior.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
How the Yahoo Mail migration affects Comcast data
Xfinity began inviting comcast.net account holders to move their mailboxes to Yahoo Mail in June 2025, and the phased rollout continues through 2026. After an account holder accepts Yahoo's terms, Yahoo Mail becomes the email provider even though the address remains at comcast.net.
That creates a split mailbox population during the migration. A comcast.net recipient domain no longer proves that Comcast processed the message or generated the complaint. Treat migrated mailboxes as Yahoo-handled and verify the relevant Yahoo CFL enrollment, while keeping the Comcast and Validity path active for mailboxes that remain on Comcast's platform.
Do not classify by recipient domain alone
- Separate populations: Track whether complaint evidence came through Comcast, Validity, or Yahoo rather than grouping all comcast.net mail together.
- Keep both paths: Do not retire Comcast enrollment solely because some recipients have migrated to Yahoo Mail.
- Label reports: Store the report source and format so migration changes do not distort complaint-rate comparisons.
What to ask your ESP
Because there is no public ESP adoption list, ask every sending provider the same operational questions and judge the answer by specificity. The provider should distinguish traditional IP or domain enrollment from experimental DNS discovery.
A useful answer names Comcast, Validity, DKIM domains, selectors, the report format, and suppression timing. It should also explain how migrated comcast.net mailboxes are handled. A weak answer says only that the ESP "supports feedback loops" without naming the feed or the data path.
|
|
|
|---|---|---|
Comcast? | Named feed | Generic FBL |
Validity? | Active route | Maybe |
DKIM? | d= and s= | Enabled |
Payload? | Fields named | Not sure |
Suppression? | SLA stated | Automatic |
Questions that separate real FBL handling from generic support claims.
A practical request
Ask your ESP for a one-message proof. The proof should show a delivered message's DKIM domain and selector, the matching feedback registration or DNS record, and the downstream suppression action after a complaint report arrives.
Where Suped fits
Suped, our DMARC and email authentication platform, does not replace a mailbox provider FBL. It helps manage the surrounding authentication and reputation work that makes FBL data usable: DKIM coverage, SPF health, DMARC policy, source discovery, alerting, and blocklist (blacklist) monitoring.
Suped brings those signals into the same investigation workflow. When Comcast complaints change, the team can check whether DKIM signing changed, a new source appeared, SPF exceeded lookup limits, or a blocklist or blacklist event occurred in the same period.
Use DMARC monitoring to confirm which systems sign mail and which ones fail authentication. A broader domain health check can catch DKIM, SPF, and DMARC gaps before missing complaint data is blamed on a mailbox provider.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and automated issue detection help when the team managing FBLs does not control every DNS change. The operational goal is fewer unknown senders, faster fixes, and complaint data that maps to the right mail stream.
How to interpret Validity and DKIM FBL together
Validity's FBL network and DKIM FBL are related, but they solve different problems. Validity gives senders and ESPs a managed path into many mailbox provider complaint feeds. The DKIM FBL proposal gives mailbox providers a DNS-based way to discover where reports should go for a DKIM signer.
Run both ideas in parallel. Keep traditional FBL enrollments active for Comcast and other participating providers. Publish DKIM FBL records only after inventorying real DKIM signatures. Then measure whether a mailbox provider sends reports through the proposed path and compare those reports against existing suppression data.
Traditional FBL
Use this today for known feeds, including Comcast through Validity where your ESP or sending domain is properly enrolled.
- Best for: Production complaint handling.
- Weak point: Enrollment and ownership checks create friction.
DKIM FBL
Test this as an experimental DNS discovery layer, not a standardized replacement for provider enrollment.
- Best for: Testing lower enrollment overhead.
- Weak point: The latest revision expired and implementation is provider-specific.
When comparing provider complaint programs, separate Yahoo's CFL and Google's aggregate model. The operational setup is different. For more context, compare Yahoo CFL setup with Gmail FBL so you do not expect one complaint feed format everywhere.
Views from the trenches
Best practices
Track DKIM d= and selector pairs before asking any provider to route feedback at scale.
Keep a domain-wide DKIM FBL record simple before adding selector-specific routing.
Compare complaint data with DMARC authentication results before suppressing broadly.
Common pitfalls
Assuming Validity's MBP roster equals a published list of ESPs using every feed today.
Expecting Comcast to return full payloads immediately creates weak suppression logic.
Publishing selector records without inventory misses traffic signed by older DKIM keys.
Expert tips
Sample live message headers so DKIM FBL checks use the selectors recipients see now.
Ask your ESP for the complaint source, payload type, and suppression delay in writing.
Use Suped alerts to catch DKIM, SPF, DMARC, and blocklist or blacklist changes together.
Marketer from Email Geeks says low-volume Validity feeds should not distract teams from Comcast data, because tiny complaint counts rarely change suppression decisions.
2024-05-10 - Email Geeks
Expert from Email Geeks says DKIM FBL adoption checks are easier when the sender has DKIM domain and selector values from real delivered mail.
2024-05-10 - Email Geeks
The practical bottom line
The safest answer to the title is this: Validity has a public mailbox provider FBL network, but it does not publish a complete ESP uptake list. Comcast is in the Validity path for traditional complaint feedback. Comcast's DKIM FBL implementation is partial, and revision 06 of the underlying proposal expired without becoming an RFC.
Comcast data also needs a migration caveat. Some comcast.net accounts now use Yahoo Mail, so verify which provider generated each complaint instead of classifying it by recipient domain. If an ESP gives a vague answer, ask for Comcast, Validity, Yahoo, DKIM d=, selector, report format, complaint fields, and suppression timing.
- First step: Inventory every sending source and the DKIM signatures recipients actually receive.
- Second step: Ask your ESP for Comcast, Validity, and migrated Yahoo handling evidence.
- Third step: Publish experimental DKIM FBL records only after the report destination and parser are ready.
- Fourth step: Use Suped to keep DMARC, SPF, DKIM, alerts, and reputation checks in one workflow.
