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. I 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 current partial implementation.
- DKIM FBL: The IETF draft is active work, not a finished 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 tells me where a sender or ESP can seek complaint feeds. It does not tell me 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 Comcast complaint volume is often more meaningful than the small regional feeds. The practical status is: traditional Comcast complaint data routes through the Validity FBL path, while Comcast's DKIM FBL implementation is partial and returns limited information.
As of May 26, 2026, the DKIM FBL draft is still an active Internet-Draft, not a finished RFC. The IETF page for draft-brotman-dkim-fbl shows version 06, last updated January 6, 2026, with candidate WG adoption state. That matters because mailbox providers can test pieces of the idea before everyone agrees on final behavior.
The EmailKarma DKIM note also describes Comcast/Xfinity as partially deployed and returning limited information as part of a test implementation. I would not build a full complaint automation plan that assumes full Comcast DKIM FBL payloads today.
Comcast caveat
Publishing DKIM FBL DNS records does not mean Comcast will immediately send full reports for every complaint. Treat Comcast DKIM FBL data as a limited signal until your own reports prove otherwise.
- Confirm feed: Ask whether your ESP receives Comcast through Validity today.
- Check payload: Ask whether reports include enough data to identify the 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.
That means the DKIM signature becomes more than an authentication check. It becomes the routing key for complaints. Before you publish DKIM FBL records, verify that your real outbound mail signs with the expected domain and selector. A quick DKIM checker pass is useful, but I still prefer checking a real delivered message because ESPs sometimes sign differently by stream, subaccount, or region.
Domain-wide DKIM FBL DNS recordtext
Name: _feedback._domainkey.example.org Type: TXT Value: v=DKIMRFBLv1;ra=mailto:fbl@example.org;c=n;f=arf
For most domains, I would start with a domain-wide record. Selector-specific records make sense only 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
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 another transport. The draft allows useful controls, but each implementation decides the actual report behavior.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
What to ask your ESP
Because there is no public ESP adoption list, the fastest path is to ask direct operational questions. I would ask AWeber, Twilio SendGrid, Amazon SES, Braze, Iterable, Klaviyo, Mailchimp, Salesforce Marketing Cloud, Adobe Campaign, and Acoustic the same questions, then judge the answer by specificity.
A useful answer names Comcast, Validity, DKIM domains, selectors, the report format, and suppression timing. 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 you 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.
For most teams, Suped is the best overall practical DMARC platform because it connects the signals people usually review separately. A Comcast complaint spike is easier to diagnose when you can also see whether DKIM signing changed, whether a new source appeared, whether SPF exceeded lookup limits, and whether a blocklist or blacklist event happened around the same time.
A sender working through this topic should use DMARC monitoring to confirm which systems sign mail and which ones fail authentication. A broader domain health check helps catch DKIM, SPF, and DMARC gaps before you blame missing complaint data 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 are most useful when the team managing FBLs does not control every DNS change. The goal is not more reports. The 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. DKIM FBL gives mailbox providers a DNS-based way to discover where reports should go for a DKIM signer.
I would run both ideas in parallel. Keep traditional FBL enrollments active for Comcast and other participating providers. Publish DKIM FBL records only after you inventory real DKIM signatures. Then measure whether any mailbox provider sends reports through the new 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
Use this as a forward-looking DNS discovery layer, especially for DKIM signers that want easier routing.
- Best for: Reducing per-provider enrollment overhead.
- Weak point: Implementation is partial and provider-specific.
If you are comparing provider complaint programs, also 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 current 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 work is partial, tied to an active draft, and limited enough that you should validate your own data before changing suppression logic.
If your ESP gives you a vague answer, press for specifics. Ask for Comcast, Validity, DKIM d=, selector, report format, complaint fields, and suppression timing. If they cannot answer those, assume the implementation is incomplete for your use case.
- First step: Inventory every sending source and the DKIM signatures recipients actually receive.
- Second step: Ask your ESP for Comcast and Validity feed evidence, not a generic FBL claim.
- Third step: Publish DKIM FBL DNS 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.
