What are the expectations and protocols for email service providers sharing bounce data with clients?
Matthew Whittaker
Co-founder & CTO, Suped
Published 17 May 2025
Updated 19 Aug 2025
7 min read
Understanding how email service providers (ESPs) share bounce data with their clients is crucial for anyone serious about email deliverability. Bounce data provides insights into why emails aren't reaching their intended recipients, which directly impacts your sender reputation and overall campaign effectiveness. It's not just about knowing if an email bounced, but why it bounced, and what specific information an ESP is obligated or willing to provide.
Different ESPs have varying policies and technical capabilities when it comes to sharing detailed bounce information. This can sometimes lead to confusion or unmet expectations from clients who need this data for crucial list hygiene and deliverability improvements. My goal here is to shed light on these expectations and the underlying protocols.
The importance of bounce data
Email bounces are a fundamental part of the email ecosystem, indicating that a message could not be delivered. There are primarily two types: hard bounces and soft bounces. Hard bounces are permanent delivery failures, often due to invalid or non-existent email addresses. Soft bounces are temporary, caused by issues like a full inbox or a temporary server outage. Each type provides different signals about your email list health and sender reputation.
For clients, understanding these distinctions is vital. A high rate of hard bounces can severely damage your email sender reputation and lead to your emails being flagged as spam or even blocked entirely. Soft bounces, while temporary, still require monitoring as persistent soft bounces to the same address may indicate an unengaged or problematic recipient.
ESPs track these bounces meticulously because their own sender reputation depends on the deliverability of their clients' emails. When a client consistently sends to bad addresses, it negatively affects the shared IP addresses, potentially impacting other clients on the same system. Therefore, ESPs have a vested interest in providing clients with tools and data to manage their bounces effectively and adhere to email deliverability best practices.
Significantly negative impact, indicates poor list hygiene.
Immediately remove from list, never send again.
Soft bounce
Temporary delivery failure, e.g., full inbox, server issues, message too large.
Minor negative impact unless persistent.
Retry delivery a few times, then consider suppression if persistent. More on soft bounce tolerance here.
What ESPs typically provide
ESPs typically provide clients with aggregated bounce rate statistics within their platforms. This usually includes overall bounce rates, hard bounce rates, and soft bounce rates. Many also allow clients to download lists of bounced email addresses, often categorized by bounce type. This allows clients to perform essential list cleaning and maintenance.
However, the level of detail can vary significantly. Some ESPs provide specific SMTP bounce codes (e.g., 550 for hard bounce, 450 for soft bounce) and textual explanations, while others might offer only generalized categories. This level of granularity is important for diagnosing specific deliverability issues. For example, a 550 bounce with a message like "mailbox full" points to a different problem than "user unknown."
The reason for this variability often comes down to the architecture of the ESP. Some ESPs are built on top of other sending infrastructures (like SendGrid or Twilio), meaning they are themselves clients of a larger service. Their access to raw, detailed bounce logs may be limited by what their upstream provider shares with them. This can create a chain of data custody that makes it challenging to get to the root cause of certain deliverability problems, as the direct sender (the client) is two steps removed from the actual bounce event.
Typical bounce data shared
Bounce rate summaries: Overall, hard, and soft bounce percentages for campaigns.
Bounced email addresses: Lists of specific email addresses that bounced, often with a classification.
Bounce type categorization: Identifying if a bounce was hard or soft.
What is often limited or not shared
Raw SMTP logs: The full, verbose log of the bounce event with specific error messages. See more about getting SMTP bounce logs.
Granular ISP-level data: Detailed insights into why specific mailbox providers bounced emails.
Historical data depth: Often limited to 30-90 days due to data retention policies.
Protocols and expectations for data sharing
The primary protocol for relaying bounce messages is the Simple Mail Transfer Protocol (SMTP). When an email fails to deliver, the receiving mail server sends back an SMTP error code (e.g., 550) with a human-readable explanation. ESPs capture and process these messages, which form the basis of their bounce reporting. However, the raw data can be extensive and complex, making it difficult for average users to parse effectively.
Example of an SMTP bounce message
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual alias table
From an ESP's perspective, sharing raw bounce data on an ongoing, regular basis can be problematic. It can encourage what some refer to as a "list washing exercise," where clients might try to clean their lists solely based on raw bounces rather than implementing sustainable best practices like consent-based list building and regular re-engagement campaigns. The focus shifts from proactive email hygiene to reactive bounce removal.
Furthermore, there's a balance between providing helpful data and overwhelming clients with information that requires deep technical understanding to interpret. ESPs aim to distill complex data into actionable insights, but clients often seek the raw details for their own diagnostic purposes. This is where a disconnect can occur, as the client's perceived right to all data clashes with the ESP's operational policies and data management strategy. It's a key part of how ESPs manage internal versus client deliverability responsibilities.
Client expectations
Full access to raw data: Desire to see every SMTP bounce message for in-depth analysis.
Unlimited historical data: Expectation of accessing bounce data from any point in their sending history.
Direct deliverability support: Belief that ESPs should actively diagnose specific client deliverability issues from raw logs.
ESP realities
Aggregated data focus: Providing summaries and categorized lists is standard due to data volume.
Limited retention: Storing all raw bounce data indefinitely is impractical for most ESPs.
Self-service tools: Empowering clients with dashboards and downloadable reports is preferred over manual support for every issue.
Navigating data requests and enhancing deliverability
For clients, the most useful bounce data is not necessarily the raw, granular logs, but rather actionable insights. This includes identifying specific email addresses that consistently hard bounce so they can be removed, and understanding patterns in soft bounces that might indicate larger issues with engagement or recipient server policies. Focus on the useful bounce data.
When requesting data from your ESP, clearly articulate your needs. Instead of asking for all bounce data for 30 days, which might be overwhelming or unavailable, specify the type of bounces (e.g., hard bounces) or a particular timeframe that you need for troubleshooting a specific problem. Be prepared to explain how you plan to use the data to improve your sending practices.
Ultimately, the best approach is proactive. Regularly implement email list hygiene to minimize bounces from the outset. This includes using double opt-in, segmenting your lists, and regularly re-engaging or removing inactive subscribers. Authentication protocols like SPF, DKIM, and DMARC also play a critical role in deliverability by verifying your sending identity and reducing the likelihood of your emails being marked as spam or bouncing due to suspicious origins. These measures reduce your reliance on detailed bounce data for troubleshooting and help improve your email deliverability rates.
Views from the trenches
Best practices
Maintain clear communication with your ESP about your deliverability goals.
Understand your ESP's data retention policies and what reports are available.
Proactively clean your email lists to minimize hard bounces before they happen.
Focus on actionable insights from bounce data, not just raw logs.
Implement email authentication protocols like DMARC, SPF, and DKIM.
Common pitfalls
Expecting full, unaggregated raw bounce data for extended periods.
Assuming your ESP has direct access to all upstream provider data.
Not understanding the difference between hard and soft bounces and their impact.
Using raw bounce data solely for list washing instead of addressing underlying issues.
Ignoring or not acting on bounce reports provided by your ESP.
Expert tips
Regularly review your sender reputation dashboards if your ESP provides them.
Segment your email lists to reduce bounces by sending relevant content.
Consider a dedicated IP if bounce rates persist on shared IPs.
Monitor engagement metrics in conjunction with bounce data for a holistic view.
If your ESP is built on another infrastructure, understand their limitations.
Expert view
Expert from Email Geeks says that if an ESP is a client of another sending infrastructure like SendGrid, it would be surprising if they shared data with anyone else outside their direct client relationship.
2019-02-08 - Email Geeks
Marketer view
Marketer from Email Geeks says they were initially told that accessing recent bounce data was feasible, but later encountered difficulties, causing confusion about proper data sharing protocols.
2019-02-08 - Email Geeks
Strengthening your email program through effective bounce management
Managing email deliverability effectively requires a collaborative approach between clients and their email service providers. While ESPs are expected to provide clear, actionable bounce data, clients must also understand the technical and operational realities that influence what data can be shared.
By focusing on proactive list management, authenticating your emails, and having clear communication with your ESP, you can ensure your messages reach the inbox and maintain a strong sender reputation.
SendGrid or 
Twilio), meaning they are themselves clients of a larger service. Their access to raw, detailed bounce logs may be limited by what their upstream provider shares with them. This can create a chain of data custody that makes it challenging to get to the root cause of certain deliverability problems, as the direct sender (the client) is two steps removed from the actual bounce event.
