GreenArrow Email Software Documentation

Bounce Management

How does GreenArrow software handle bounce management and bounce classification?

GreenArrow offers two kinds of built-in bounce handling for both synchronous and asynchronous failures.

The details about how they work (including configuration and classification) can be found in our documentation:

What is the difference between the two bounce processing systems?

The two bounce processing systems have different workflows, as described in the following sections.

The “Heavy” Bounce Processor

With the “heavy” or “normal” Bounce Processor, GreenArrow rewrites the RFC5321.MailFrom address of each message to contain a custom Variable Envelope Return Path (VERP).

For example, if the bounce processing mailbox is:

[email protected]

Then the generated RFC5321.MailFrom may look something like this:

[email protected]

When a bounce message reaches GreenArrow’s inbound bounce mailbox, it reads the message, parses the bounce address and message (which has information embedded in it that allows GreenArrow to identify what email bounced, what campaign it was part of, who the sender was, and more), and then determines why the message failed and what to do next with that information.

Bounce processing mailboxes can be configured in any of the following ways:

You can pre-define “bounce processing mailboxes” in the Engine UI, the Engine API, or the configuration file:

The last of these can allow one regex to cover all of your customer domains, easing configuration management.

The “bounce processing mailbox” to use can also be specified on a per-message basis with the X-GreenArrow-BounceMailboxOverride header or in the Mail Class configuration.

You can also optionally have the bounce processor forward a copy of the bounce message to the original RFC5321.MailFrom address

The Lite Bounce Processor

With the Lite Bounce Processor, the RFC5321.MailFrom address is not overwritten. You create your own bounce address for each message, encoding whatever information in the email address that you want. You must also define a regex using the lite_bounce_processor_address configuration directive to let GreenArrow know which email addresses are bounce addresses and should be processed.

With the Lite Bounce Processor, GreenArrow Engine provides you the bounce address in the bounce_lite event

What Is The Bounce Classifier?

GreenArrow Engine processes the full text of the response for any bounce, and classifies each bounce using a system of bounce codes.

The bounce code is included in the:

  • bounce_code data field of every bounce_all event and bounce_stat event generated by the Heavy/Normal Bounce Processor.
  • bounce_code data field of every bounce_lite event generated by the Lite Bounce Processor.
  • bounce_code data field of every delivery_attempt event.

(These events can be delivered by webhook, written to accounting files, or inserted into a database using one of the Event Delivery Methods.)

A synchronous bounce will generate both a delivery_attempt event showing the failure, and a bounce_all, bounce_stat, and/or bounce_lite event.

Some GreenArrow customers take advantage of the fact that the delivery_attempt notifies them of the synchronous bounce, and configure the MTA to not create bounce messages/events for the synchronous bounces, using the create_bounce_messages directive. There is an efficiency advantage to doing this. These customers process synchronous bounces from the delivery_attempt events, as bounce events for synchronous bounces are not created. GreenArrow still receives and processes asynchronous bounces and creates the normal bounce events for them.

Is Bounce Classification Configurable?

Yes. While GreenArrow Engine has an extensive set of classification rules for bounces, bounces can sometimes be misclassified. The bounce_processor_rule configuration directive allows a GreenArrow administrator to write custom bounce processing rules.

Can MTA behavior be customized based on bounce or SMTP response text?

Yes. GreenArrow Engine supports custom behavior in the MTA based on a SMTP error response, through use of the smtp_pattern directive. This directive can be applied to specific IP addresses and/or domains (including MX wildcarding).

There are also other directives that can override behavior based on a regex match of the error response, specifically these three:


Copyright © 2012–2026 GreenArrow Email