Email Bounce Message Volume Increase

Jen Leonti

Our bounce process encountered an issue approximately one month ago that resulted in an invalid state that was not discovered by monitoring. We will enhance the monitoring and also implement a fix in the coming weeks to completely resolve the issue. It will be monitored closely in the meantime.



Blackbaud Communications Service

Justin Morrow

This is a further update on our Email Bounce Message issue...



Over the last 12 months, we have experienced bounce issues that are distinct and unrelated, despite symptoms that may suggest a shared cause. Be assured that our IT, Hosting, and Products groups handle each issue quickly to deliver a resolution, but they sometimes encounter new issues that require additional time to resolve. As part of the investigation to identify and resolve an issue, we continually look for areas where we can provide additional monitoring to enable quicker responses to future outages, with an ultimate goal of reducing downtime for our clients.



Our bounce process involves several steps. To ensure bounces are captured, these steps run continuously, even though the related email job may have completed prior to Blackbaud receiving the bounce message.


1. Our Message Transfer Agents (MTAs) receive the bounce message, parse the data, and then add the bounce to Blackbaud’s failure log.


2. A log processor reads the parsed data and will attempt to add it to an internal Blackbaud database.


3. Another processor pulls the new data, translates it to more readable format, and makes it available to clients for use in reports on the success and failures for a particular job.



We track two general types of bounces, depending on the Simple Mail Transfer Protocol (SMTP) bounce code and message received from the Internet Service Provider (ISP).


• Hard bounces occur when the ISP does not accept any mail on behalf of the recipient. There can be many reasons for a hard bounce, ranging from an account that doesn’t exist to an account that has been dormant for a period of time and deemed invalid by the ISP.


• Soft bounces occur when the ISP did not accept the message but will allow future attempts to deliver a message to the same recipient. However, the MTA will continue to retry a soft bounced message for a period of time which may result in the message being delivered without issue.



We capture bounces in two specific ways, and some bounces may be delayed due to external factors that may be misinterpreted as problems with the bounce process.


• Synchronous bounces occur at the SMTP level. We know immediately when an email bounces as part of the SMTP communication.


• Asynchronous bounces may occur up to, but not limited to, 48 hours after the message was sent. After the SMTP conversation completes without error, we mark the message as successfully delivered. However, we may later receive a delayed bounce message from the ISP that requires the delivery status be updated to a bounce. In this instance, a client may see a message listed as delivered but then changed to bounced since we receive the message long after the SMTP communication ended.



For more information, please visit this resource available on our website