What are the expectations and protocols for email service providers sharing bounce data with clients?

Key findings

• Varying access: ESPs often have different levels of access to raw bounce data from their underlying sending infrastructure (e.g., Sendgrid for Klaviyo). This can impact what they are able to share with their direct clients.
• Responsibility cascade: An ESP is primarily responsible to its immediate customer (e.g., Klaviyo is responsible to its client, not directly to Sendgrid's network). The ESP should interpret and pass on relevant data to its client.
• Data utility: While raw bounce data can be extensive, often only a sample or aggregated data is needed to diagnose deliverability problems and understand their magnitude, as highlighted by Salesforce's insights on email deliverability tools.
• Reputation impact: High bounce rates, particularly hard bounces, significantly harm your sender reputation, making timely access to bounce data essential for proactive management.
• Client frustration: Lack of transparency or conflicting information from an ESP regarding bounce data can severely impede a client's ability to troubleshoot issues and manage their email program effectively.

Key considerations

• Service level agreements (SLAs): Clients should clarify with their ESP what specific bounce data will be provided, in what format, and with what frequency as part of their agreement. This sets clear expectations from the outset.
• Actionable insights: Rather than raw logs, clients typically need digestible reports or aggregates that allow them to identify problematic segments, understand bounce reasons, and improve their email domain reputation.
• Avoiding list washing: ESPs may be reluctant to provide continuous raw bounce data due to concerns that clients might use it for 'list washing' instead of focusing on sustainable list hygiene and engagement practices.
• Escalation paths: If an ESP fails to provide adequate bounce data or support, clients should be prepared to escalate their concerns or consider alternative providers that align better with their deliverability needs.

Key opinions

• Right to information: Marketers frequently believe they have a fundamental right to access bounce data impacting their email performance, especially when their accounts are negatively affected or their campaigns are underperforming.
• Frustration with opacity: A common point of contention is the lack of transparency or conflicting information from ESPs regarding data access, which hinders troubleshooting and strategic adjustments.
• Need for actionable data: Marketers need data that allows them to distinguish between hard and soft bounces, identify problematic email addresses, and understand the reasons behind bounces to improve list hygiene.
• Impact on strategy: Without adequate bounce data, marketers struggle to implement effective strategies, such as knowing whether to resend emails to certain bounced recipients or to remove them permanently.

Key considerations

• Advocate for transparency: Marketers should proactively discuss data sharing expectations with potential or current ESPs and push for clear explanations when data is withheld.
• Understand ESP limitations: It's important to understand that some ESPs might rely on third-party senders, which could affect their direct access to the most granular data. Clarify this relationship upfront.
• Prioritize list hygiene: Even with limited data, maintaining a clean email list is paramount, as high bounce rates signal poor management to email providers, affecting deliverability standards.
• Seek deliverability expertise: If an ESP isn't providing the necessary deliverability support or data, seeking an external deliverability consultant can help bridge the gap.

Key opinions

• ESPs' core role: Experts emphasize that an ESP's primary responsibility is to ensure deliverability for its direct customer. This includes managing issues and providing relevant data to that customer, not necessarily their client's clients.
• Data access challenges: If an ESP doesn't have direct access to granular bounce data from its upstream provider, it raises significant concerns about their ability to offer effective deliverability assistance to their own clients.
• Limited raw data: Many experts agree that while samples of raw bounce data can be useful for diagnostics, providing extensive, ongoing raw data is often unnecessary and can lead to misuse (e.g., 'list washing' instead of strategic improvements), as highlighted by the distinction between soft versus hard bounces.
• Client-ESP relationship: Experts advise clients to carefully evaluate their ESP's capabilities and responsiveness, particularly concerning deliverability support, which often hinges on access to and interpretation of bounce data.

Key considerations

• Managed vs. self-service: The level of bounce data sharing might depend on whether the client is on a fully managed ESP plan or a self-service model, with managed plans typically offering more hands-on support and data interpretation.
• Data aggregation: ESPs are expected to aggregate and summarize bounce data into actionable reports, rather than just providing raw logs, helping clients understand how internet service providers track email engagement.
• Contextual understanding: Experts advise clients to seek not just data, but also the ESP's expertise in interpreting it. This includes understanding specific bounce codes, like those from Oath, Verizon, and AOL, and their implications.
• Proactive communication: ESPs should proactively communicate any limitations in data sharing or changes in their protocols to manage client expectations effectively.

Key findings

• Bounce categorization: Documentation distinguishes between 'hard bounces' (permanent failures, e.g., invalid address) and 'soft bounces' (temporary issues, e.g., full inbox), each requiring different handling protocols.
• Automatic suppression: Most email providers automatically cease sending attempts to hard-bounced addresses after the first failure, as detailed by Mailgun's blog on email bounces, to protect sender reputation.
• SMTP response codes: Bounce messages are communicated via standard SMTP error codes (e.g., 5xx for hard bounces, 4xx for soft bounces), which provide specific reasons for delivery failure, as explained by Rackspace Technology Documentation.
• Authentication impact: Proper implementation of email authentication protocols like DMARC, DKIM, and SPF is critical. A lack of these can lead to higher bounce rates as receiving servers may reject unauthenticated mail.

Key considerations

• Data aggregation importance: While raw SMTP logs exist, ESPs are responsible for processing these into digestible formats for clients, often providing aggregate bounce rates and categories rather than individual bounce records.
• Reputation management: Documentation consistently emphasizes that prompt handling of bounces, especially hard bounces, is essential for maintaining a strong sender reputation and avoiding blocklist or blacklist listings.
• Compliance with standards: Adhering to email sending best practices and authentication standards, such as those related to DMARC, SPF, and DKIM, directly impacts how receiving servers handle your mail, including bounce reporting.
• Understanding delivery status: Documentation clarifies that 'delivered' status does not always mean inbox placement. It simply means the receiving server accepted the message, which can still be followed by filtering or deferred delivery by internal systems.