What ESPs use Validity's FBLs and what is the status of Comcast data and DKIM FBL implementation?
Published 11 May 2025
Updated 7 Oct 2026
13 min read
Summarize with
Updated on 7 Oct 2026: We clarified Validity report access and Comcast complaint handling, including the experimental DKIM FBL path.
There is no complete public count or roster of email service providers (ESPs) enrolled in Validity's feedback loops (FBLs) in the cited documentation. Validity's public FBL information is mainly about mailbox provider and ISP coverage. Confirm ESP participation by asking for the named feed and its complaint handling path.
Twilio SendGrid is a documented example: Twilio's Comcast guidance explicitly says Twilio subscribes to the Validity FBL. AWeber's DKIM authentication support alone does not establish that the experimental DNS-based DKIM FBL path is deployed; request implementation evidence before treating it as confirmed. Comcast has traditional FBL data available through Validity, and its separate DNS-based DKIM FBL implementation returns limited data.
Short answer
- ESP roster: There is no complete public ESP list in the cited Validity FBL documentation, so ask each ESP for its specific feeds.
- Comcast data: Traditional complaints use the Validity path, while Comcast's partial DNS-based DKIM FBL returns a different, limited payload.
- DKIM FBL: Revision 06 expired on July 10, 2026 and is not an RFC, so production behavior still depends on each mailbox provider.
Mailbox provider coverage and ESP participation
The public coverage list is a mailbox provider list. Validity describes complaint data across more than 25 mailbox providers, while Twilio's documentation confirms its subscription and Comcast's complaint route. Neither establishes a complete roster of enrolled ESPs.
That coverage shows where a sender or ESP can seek complaint feeds. It does not show which customers are covered, whether complaint data is parsed into suppression workflows, or whether a DKIM-based DNS discovery method is live.
|
|
|
|---|---|---|
Mailbox provider FBL network | Provider coverage does not establish ESP enrollment | |
Traditional FBL; partial DNS-based DKIM FBL | Separate paths with different report formats | |
DNS-based implementation unconfirmed | Request evidence beyond DKIM authentication support | |
Subscription documented | Twilio confirms its Validity FBL subscription | |
Separate DKIM-based CFL | Enroll the actual signing domains through Yahoo |
Documented coverage and the implementation details to verify.
Validity Universal Feedback Loop provider enrollment table, including Comcast.
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 when it enrolls the relevant IPs or DKIM domains and accesses the reports available under its subscription. Useful complaint handling also requires parsing those reports and applying 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 individual 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 when complaints are tied back to the affected recipients or campaigns.
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 implementation proves
- Domain control: The ESP has confirmed the domains or IPs used for the feed.
- Data handling: Individual reports are parsed and mapped to a recipient, account, or campaign.
- Suppression flow: Identifiable recipient complaints drive suppression promptly.
Why aggregate complaint data cannot replace individual reports
Validity's published service update distinguishes free aggregate complaint trends, available for up to 120 days, from paid individual Abuse Reporting Format (ARF) reports. This distinction was introduced in September 2023. Confirm your ESP's current report entitlement; an enrolled account alone does not prove individual ARF delivery.
Aggregate trends help identify complaint spikes, but do not identify the recipient to suppress. An individual report supports suppression only when its returned headers can be matched reliably to one recipient in the sending logs.
- Ask whether your ESP receives individual reports or only aggregate complaint trends.
- Verify that a returned Message-ID or signed per-delivery identifier maps to the correct recipient.
- Deduplicate overlapping complaint feeds before counting reports or repeating suppression actions.
- Treat an absent report as missing evidence rather than proof that no recipient complained.
Comcast data status
Comcast offers a traditional complaint feedback loop and a partial DNS-based DKIM FBL implementation. 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 specifies that 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 individual 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 with delivered message counts for the same complaint source. A drop in reports also warrants checking reporting coverage.
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 supporting 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. The feedback concerns recipient complaints; DKIM supplies the authenticated identity for routing.
The DKIM signing domain and selector are the routing keys for complaints. Before publishing DKIM FBL records, verify that real outbound mail signs with the expected domain and selector. A DKIM checker checks published key records, but a delivered message is needed to verify the actual signature and its d= and s= values. 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.
Experimental 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.
Experimental selector-specific DKIM FBL DNS recordtext
Name: s1._feedback._domainkey.example.org Type: TXT Value: v=DKIMRFBLv1;ra=mailto:fbl@example.org;h=X-FBL-ID;c=n
If the record uses h or hp to request an identifying header, the relevant DKIM signature must sign that header. In this example, X-FBL-ID is an opaque per-delivery identifier mapped to one recipient in the sender's logs. Use h for an identifier that supports recipient suppression. Use hp for campaign-level reporting when the recipient's identity is withheld. An external ra destination whose domain does not share the DKIM signing domain's organizational domain also needs the proposal's confirmation DNS record.
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 which delivery methods it supports. Revision 06 defaults c to n, requesting headers without the message body. These DNS examples follow the expired draft; each provider's implementation determines 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. Its support team confirms that customers can continue using the Xfinity email platform without migrating. Under Xfinity's migration guidance, accepting Yahoo's terms makes Yahoo Mail the email provider even though the address remains at comcast.net.
That creates a split mailbox population. 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. Yahoo's CFL requires enrollment of the actual DKIM d= domain; a Validity registration does not enroll it automatically.
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 complete public ESP adoption list in the cited documentation, ask every sending provider the same operational questions and judge the answer by specificity. The provider should distinguish traditional IP or DKIM-domain enrollment from experimental DNS discovery.
A useful answer identifies the complaint source and report format, confirms coverage for your signing domains, and states suppression timing. It should also explain report entitlement and 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.
|
|
|
|---|---|---|
Which Comcast feed is active? | Named complaint route and customer coverage | Generic FBL support |
Does Validity access include individual reports? | Individual ARF delivery entitlement confirmed | An account is registered |
Which DKIM domains and selectors are covered? | Actual d= and s= values verified | DKIM is enabled |
Which returned fields identify a recipient? | Message-ID or signed identifier matched to sending logs | Report fields are not confirmed |
How quickly are recipients suppressed? | Processing time and a sample suppression event | Suppression is automatic |
Questions that separate operational FBL handling from generic support claims.
A practical request
Ask your ESP for a redacted example showing a delivered message's DKIM domain and selector, the matching feedback registration or DNS record, and the suppression action after a complaint report arrives. The returned identifier should map to the affected recipient in the sending logs.
Where Suped fits
Suped, our DMARC and email authentication platform, helps investigate DKIM coverage and DMARC results alongside changes in FBL data. DMARC aggregate reports show authentication results; they do not identify recipients who reported a message as spam.
When Comcast complaints change, check in Suped whether DKIM signing changed or a new sending source appeared. Investigate SPF errors and blocklist (blacklist) alerts in the same period.
Use DMARC monitoring to identify sending sources and review their authentication results. A domain health check checks published authentication records, while delivered-message headers confirm how the sending system actually signs mail.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Use Suped's authentication findings to direct fixes to the sending system or DNS owner, and use your ESP's complaint reports for recipient suppression.
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. Traditional DKIM-domain enrollment alone does not establish support for this DNS discovery proposal.
Keep traditional FBL enrollments active for Comcast and other participating providers. Test 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's IP addresses or DKIM domains are properly enrolled and individual-report delivery is enabled.
- 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.
Yahoo's CFL returns individual ARF reports for enrolled DKIM domains. Gmail's FBL documentation describes aggregate campaign feedback using a DKIM-signed Feedback-ID header, without recipient-level complaint reports. 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.
Use recipient-level identifiers for suppression; DMARC reports measure authentication.
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
FBL implementation checklist
- Inventory every sending source and the DKIM signatures recipients actually receive.
- Ask your ESP for Comcast and migrated Yahoo handling evidence, including individual-report access and suppression timing.
- Test experimental DKIM FBL records only after the report destination, signed identifiers, and parser are ready.
- Use Suped's DMARC monitoring to investigate authentication changes alongside provider-specific complaint trends.
