Effective Bounce Email Management with Campaign Enterprise

General Bounce Information
Managing bounces is one of the most important steps you can take with email marketing. Remote servers (those responsible for delivering to your customers) tally up the number of failed emails to their domain and will score you based on the percentage. If your bounce percentage is high, they can start blocking you on the fly to other emails in their domain. Identifying bounced emails the first time, and filtering them or removing them from your list is critical for email deliverability.

In order for Campaign Enterprise to manage bounces, you must set up an email account exclusively for Campaign Enterprise's use. Create a new POP3 or IMAP4 email account as though Campaign were a new employee. This account cannot be an alias of another account and must be exclusive to Campaign. Once you configure the account, use it as the return path address, which is identified as the bounce email address on the compose message page in the Campaign edit screens.

The Return Path email address is where non-delivery failure notifications go, also known as NDFs or bounces. These are notices from your mail server, or subsequent mail servers in the delivery chain, indicating a problem with sending the message. A permanent NDF is considered a hard bounce, either the domain or address doesn't even exist. These are identified by Campaign as a hard bounce, and can be filtered or removed from your list immediately in most cases. A temporary NDF is a notice from an email server that there was a problem with delivery, but your mail server may retry the message on a scheduled retry. You'll need to talk to your mail administrator about the number of retries your server has. These are identified as soft bounces by Campaign and you can use more discretion on filtering or fixing these addresses.

Managing Bounced Emails with Campaign
Other write back features in Campaign Enterprise use the unique id, but the id is frequently stripped out of bounced email messages. The only thing that is always preserved is the original to address. Unlike other features with Campaign Enterprise, the record that bounces is updated by comparing the original to address with the address field in your source table, not the unique id. Since this is the case, you will need one bounce email account for each table to which you are connecting.

Scenario One
In the example below, there are three different campaigns, all using the same source table. In this case, all the campaigns use the email address for bounce account 1, but only one campaign needs to actually have bounce enabled. All bounces, regardless of which campaign sent them, will update in the source table.

Since the source table is updated, all three campaigns will be able to identify the bounced emails and apply the filter to prevent those emails from going out again. Using this scenario, you can create a Bounce Campaign, which is open to the entire table, no filtering, and enable it to monitor the account. It will monitor the account for all of the campaigns connected to that table and using that bounce email account.

Scenario Two
This example shows how bounces should be managed with multiple tables, one for each campaign. Since the source table has a specific group of addresses, you cannot check that account with the same bounce account being used by another campaign, the email address may not appear in the table. Each campaign would use the email address for the specific bounce account to which they are connected.

Scenario Three
Finally, you can set up your bounce account to monitor an email account that accepts wild cards. With this option you can use VERPS, or Variable Envelop Return Paths. This is explained in more detail in these two articles.
Using VERPS
More on VERPS

Unfortunately, MS Exchange Server 2010 does not support email accounts with wild cards. For more information on setting up your bounce email account, check with your email service provider.