A delayed bounce occurs when mail is initially accepted for delivery but then rejected after the SMTP conversation is over. Because the original SMTP connection was terminated upon confirmation of delivery, a new conversation is started where much of the previous context is lost. This results in delayed bounces not having an associated IP and other information, including message ID. This means that the delayed bounce may not be related back to the activity history of the message that bounced, but we are able to report the bounce back to your SendGrid account within the Bounce Suppressions.
Return-Path and Bounce Handling
Something that may be helpful with understanding how this works is looking at how we handle the return-path. The return-path that we re-write to handle bounces always has a similar structure as follows:
<bounces+1234567-a1b2-sendgridtesting=gmail.com@em123.domain.com>The dynamic pieces of the above return-path example are as follows:
- "1234567" is the user ID of the SendGrid account that authenticated and routed the email.
- "a1b2" is an internal code that is generated
- "sendgridtesting=gmail.com" coincides with the recipient address of "sendgridtesting@gmail.com"
- everything after "@" (em123.domain.com) is the domain authentication instance used with the sending account (the domain authentication that either a) lives within the sending account under "Settings > Sender Authentication" or b) which domain authentication is assigned to the account from the parent account if the sending account is a subuser).
We use the above information in the return-path to log any standard or delayed bounce back to the account, within the specific account's bounce suppressions, and because the recipient email address is included in that return-path, we can also log that recipient email address.
Identifying a Delayed Bounce
During a standard bounce event, this all happens fairly immediately on 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 is closed. Because this all happened on the same SMTP conversation, we still have all the relevant information needed to correlate this back to the same message. We log the bounce event in the bounce suppressions list, and we also let you know that that message, from that conversation, with that message ID bounced. You can see 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 and the SMTP conversation closes. However, they decide to bounce the message after sending the "delivered" response to us, and they have to 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.