Email Bounce Handling
A bounced e-mail message (or simply bounce) is a message that cannot be delivered to its destination. Usually, Internet Service Providers (ISPs) will return the e-mail to the sender along with some information indicating why the message could not be delivered.
These different kinds of bounces can be grouped depending on whether the fault lies with the sender, the receiver, or somewhere in between. When it handles bounces due to problems with the recipient, it may invalidate the recipient’s e-mail address. This cleans mailing lists and segments by preventing any future mailings from being sent to that recipient, this is an important step in maintaining a good sender reputation. When techmail handles bounces due to problems with the sender or problems in transit, it takes no automatic action. For all bounces, regardless of type, it records as much information as possible for reporting.
Bounce Types
- Soft bounce – An email was returned because of a temporary problem with the
recipient's mailbox (for example, the mailbox has exceeded its available
size limit). Service incident emails that result in soft bounces are not
automatically re-sent by the system. If you want to resend an incident
response that has bounced, you must manually respond to the incident again.
Conversely, when Techmail detects that a soft bounce has been returned from
a mailing or survey invitation email, it places that message in a mail queue
and attempts to resend it for up to seven days (the default value specified
by the BOUNCE_RETRY_WINDOW configuration setting).
However, if a contact's email address returns soft bounces three consecutive times with no contact activity in the previous fifteen days (as specified by the INVALID_NUM_BOUNCES and INVALID_NUM_DAYS configuration settings), the address is marked as invalid. Once a contact's email has been invalidated, the system does not send mailings or surveys to that address.
- Hard bounce – An email was returned because of a permanent problem with the recipient's mailbox, and the problem is not expected to be resolved (for example, the recipient mail server indicates that the email address does not exist). When a hard bounce is received, the contact email address is marked invalid and no resend attempt is made. When techmail encounters a hard bounce, it immediately invalidates the contact’s e-mail address to prevent further mailings from being sent.
- General bounce – A mailing or survey invitation email was returned due to technical problems with the delivery of the message. That is, the problem is not on the sender's end nor the recipient's end, but in the transmission of the message over the network in between. It is therefore difficult to predict the likelihood of resolution. General bounces are logged in the database but no further action is taken. No resend attempt is made and the contact email address is not marked invalid.
- Unknown bounce – An email was returned for a reason that could not be determined. Unknown bounces are logged in the database but no further action is taken. No resend attempt is made and the contact email address is not marked invalid.e
- Forced unknown bounce - An email was returned and the error code is not a recognized bounce code. Typically emails will bounce with a SMTP 500 type error, but on occasion bounces do not have a typical 500 type error.
It is possible to re-validate contacts whose e-mail addresses have been invalidated due to bounce activity. In the contact workspace editor, there are fields named Primary Email Invalid, Alternate Email 1 Invalid, and Alternate Email 2 Invalid. With these fields added to a contact workspace, the contacts’ e-mail addresses can be re-validated simply by editing the contact record. These fields are also available for contact multi-edit workspaces. This allows you to re-validate multiple contact e-mail addresses at once. Please note, however, that we strongly recommend submitting an incident to Technical Support and allowing us to assist you in analyzing the need to re-validate large numbers of contacts. Large-scale re-validations can lead to e-mailing large numbers of invalid addresses, which can severely damage your reputation as a sender. Reputation damage, in turn, can lead to ISP blocks and blocklists, which reduces the efficacy of e-mail as a marketing tool, and reduces your ability to reach your customers.
To view mailing bounce statistics, visit the Mailing Delivery Analysis report located at \Public Reports\Outreach\Email Performance. This report shows the number of messages sent, number delivered, a count of each type of bounce that occurred, and percentages for each count. There is one row for each format associated with the mailing, and a bar chart that displays a visual representation of bounce information aggregated over all formats in the mailing.
In other cases, Techmail may receive an error code indicating that a mailing or survey invitation email was blocked by the recipient mail server. When this happens, Techmail attempts to identify the reason for the block and classifies it as one of the following block types.
- Content bounce - An email was blocked due to its content. In other words, some part of the message content triggered a filter that prevented the message from being delivered.
- Sender bounce - An email was blocked due to the sender's reputation. This means that the sender has not developed a trusted relationship with the recipient provider.
- Block bounce - An email was blocked for a reason not fully specified. The block class generally relates to policies outlined by the recipient mail system.
When techmail encounters this, it logs the error in the database but does not attempt to resend the message, nor does it invalidate the contact email address.
Delivery errors logged by the system can be accessed with reports, specifically the Invalid Email Address Domains report (Public Reports/Outreach/Contacts/Database Snapshot) and the Invalid Email Addresses by Mailing report (Public Reports/Outreach/Contacts).
You may also find it valuable to build a custom report using other data stored in the Bounced Messages (bounced_msgs) table. For example, you could create a custom report that includes the email address that the message was sent to, the text of the error received, the type of block or bounce it was classified as, and whether the email address was invalidated as a result. See Overview of Custom Reports.
B2C Service stores a copy of the original email message for 60 days. You can change or disable this purging interval by editing the OE_BOUNCE_PURGE_DAYS configuration setting. See Edit a Configuration Setting.
When a delivery error is returned from an incident response, a View Bounce Messages button appears in the header of the response thread that was bounced. Clicking this button opens a window displaying the contents of any delivery errors resulting from the response. See View a Bounced Message.