make marketing affordable now!

Printing Hosting Email Marketing


Bounce management

Introduction to bounce management

Whenever an email is sent via the internet, regardless of the email software used, the email is transmitted by an MTA (Mail Transport Agent).  In most cases the MTA is the internet provider’s SMTP mail server, sending to the MTA of the email’s recipient, through intermediary MTAs.

If the email cannot be delivered to its recipient, the last MTA that tried to transmit the email generates an error email, called a bounce message, which is sent back to the sender’s email.

Usually, this bounce message contains a specific error code that explains why your email could not be delivered to its recipient.

Blink Mailer implements bounce management which handles these bounce messages, and provides automatic actions depending on the error code, like removing an incorrect email address. 

Advanced bounce management

Advanced bounce management enables the automatic performance of various actions depending on the kind of bounce error code that is returned by the MTA.

To enable it just add the following in config.php


Once this is set up, you may proceed in the Blink Mailer interface to System Manage Bounces > List Bounces Rules


From there you may create new bounce rules, based on regular expressions that will trigger Blink Mailer actions.

Regular expressions are sequences of characters that match a search pattern. While this manual won’t explain the use of regular expressions, we will analyse the examples given here.

Bounce emails generally contain a header and a mail body that may, depending on the MTA that sent the email, give a reason why the initial email could not reach its recipient.

An example bounce email could look like the following:

Final-Recipient: rfc822;

Original-Recipient: rfc822;

Action: failed

Status: 5.2.1

Remote-MTA: dns;

Diagnostic-Code: smtp; 550 5.2.1 This mailbox has been blocked due to

inactivity (UserSearch)

What we see here is the recipient’s MTA telling us that the user’s mailbox is blocked, probably because it’s not been used for a long while. There are some excellent articles about MTA responses on the internet. Every MTA programme has its own return messages. Also, you may have noticed that the return messages usually come with a 3 digit code, 5.2.2 in this example.

This code is the error code corresponding to the return message, but some MTAs just give bogus codes, especially when they think your email is spam.

Now let’s create our first bounce rule:

The regular expression could be the exact sentence the MTA return message contained, in brackets.

Now Blink Mailer provides multiple actions that can be triggered if a bounce email matches our regular expression:

  • Delete subscriber
  • Unconfirm subscriber
  • Blacklist subscriber
  • Blacklist email address
  • Delete subscriber and bounce
  • Unconfirm subscriber and delete bounce
  • Add subscriber to the do-not-send list and delete bounce
  • Add email address to the do-not-send list and delete bounce
  • Delete bounce.

In our case, we can assume that our subscriber’s email address haven’t been used for a long while, and that it’s safe to unconfirm the subscriber.

Now we have a choice between “unconfirm subscriber” and “unconfirm subscriber and delete bounce”. The only real difference between both options is that deleting the bounce message will also remove it from bounce statistics (using the BounceStatisticsPlugin).

Once we finished our rule, we may add it and try it against our bounces.

Back in Blink Mailer, we can check if our rule matches any of our actual bounces, by going to System Manage BouncesCheck Current Bounce Rules.

The system will then tell us how many bounces are caught by our rules.

Now you may have a big list of bounces that aren't caught by the rule, and some of them are pretty similar to the rule.

We may have multiple bounce messages that could say “account is disabled” or “This account has been disabled” which basically means the same as “mailbox has been blocked due to inactivity” of our first rule.

Way may create two other rules to deal with these bounces, or improve our regular expression to match all these messages with the same rule.

Regular expressions use the pipe symbol “|” as OR statement, meaning the following regular expression:

(black|white) would match any text that has the words black or white in it.

Now let’s improve our first rule by adding all our MTA return messages that basically mean the same thing:

The actual regular expression I used here is:

(account is disabled|This mailbox has been blocked due to inactivity|This account has been disabled|The email account that you tried to reach does not exist|This is a permanent error * local delivery failed)

Note that the * is a wildcard token that means there can be up to zero characters between “This is a permanent error “ and “ local delivery failed”.

This rule can now deal with any of these 5 return messages.

Good starter rule set:

Rules to copy

(Archived recipient.) Delete subscriber

(delivery error: dd This user doesn't have a account|This user doesn't have a account) Delete subscriber

(type=MX: Host not found) Delete subscriber. No mail records for the domain.

(sorry, no mailbox here by that name|Mailbox disabled|address not found in table|User mailbox is not local|mailbox not allowed|Mailbox syntax incorrect|RESOLVER\.ADR\.RecipNotFound) Delete subscriber and bounce. No ambiguity here, we can also delete the bounce message.

(account is disabled|This mailbox has been blocked due to inactivity|This account has been disabled|The email account that you tried to reach does not exist|This is a permanent error * local delivery failed) Delete subscriber and bounce. Same as above

(User unknown|Unknown user|Unknown address|No such recipient|No such user|The email account that you tried to reach is disabled|Recipient not found|Recipient unknown|Invalid recipient|Address unknown|Recipient address rejected) Delete subscriber and bounce. Same as above





Return to email user guide contents