A delayed bounce occurs when an email is initially accepted for delivery but is later rejected after the SMTP conversation has ended. Since the original SMTP connection is closed upon delivery confirmation, a new conversation must be initiated, resulting in the loss of much of the previous context.
This means that delayed bounces lack associated IP addresses and other details, such as the message ID. Consequently, the delayed bounce may not be linked back to the message's activity history. However, we can still report the bounce to your SendGrid account within the Bounce Suppressions.
Return-Path and Bounce Handling
To better understand this process, consider how we handle the return-path. The return-path we rewrite for bounce handling typically follows this structure:
<bounces+1234567-a1b2-sendgridtesting=gmail.com@em123.domain.com>The dynamic components of this return-path example are:
- "1234567" represents the user ID of the SendGrid account that authenticated and routed the email.
- "a1b2" is an internally generated code.
- "sendgridtesting=gmail.com" corresponds to the recipient address of "sendgridtesting@gmail.com".
Everything after "@" (em123.domain.com) is the domain authentication instance used with the sending account. This domain authentication is either configured under "Settings > Sender Authentication" within the sending account or assigned from the parent account if the sending account is a subuser.
We utilize this return-path information to log any standard or delayed bounce back to the account within the specific account's bounce suppressions. Since the recipient email address is included in the return-path, we can also log that recipient email address.
Identifying a Delayed Bounce
In a standard bounce event, everything occurs promptly within the same SMTP conversation (the method used by mail servers to negotiate a connection while delivering email). Once we receive a response (bounced, delivered, etc.) from the recipient server, the SMTP conversation closes. Because this all happens within the same SMTP conversation, we retain all relevant information needed to correlate this back to the same message. We log the bounce event in the bounce suppressions list and notify you that the message, from that conversation, with that message ID, bounced. You can view this in the Activity Feed.
In the case of a delayed bounce event, we send the message and receive a "delivered" server response from the recipient server, closing the SMTP conversation. However, if they decide to bounce the message after sending the "delivered" response, they must open a new SMTP conversation and send the "bounce" response along the return-path. We can still log this back to the account, and we can see the recipient the bounce was for, thanks to the information in the return-path, but some information is lost when the new SMTP conversation is created, like the message ID, so this isn't correlated back as the same message in the activity feed, and the bounce will only show in the Bounce Suppressions list.
If you are able to see a recipient email within the Bounce Suppressions within your account, but the bounce is not reflected in your Activity Feed, this is likely due to a delayed bounce event.
If you are viewing event data that has been reported to an Event Webhook endpoint, and the bounce event is missing information that would typically reported like IP or sg_message_id, this is also likely due to a delayed bounce event.
Resources
Email Bounce Management: Soft Bounces vs. Hard Bounces