How does Oracle handle bounced email messages?
Oracle Service Cloud
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.
- 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.
- 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 re-validating 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 blacklists, 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 the block and classifies it as one of the following block types.
Content block - 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 block - 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.
General block - An email was blocked for a reason that could not be determined.
When techmail encounters a block error, it logs the error in the database but does not attempt to resend the message, nor does it invalidate the contact email address.
For additional information, refer to the 'Email bounce handling' section in online documentation for the version your site is currently running. To access Oracle Service Cloud manuals and documentation online, refer to the Documentation for Oracle Service Cloud Products.