Soft bounce management and resending

Product Support
1

Your software
My Mautic version is: 7.2.1
My PHP version is: 8.4
My Database type and version is: MariaDb 11.4

Your problem
Email sent through SendGrid is marked bounced when one of their IPs in blacklisted and Email Channel in Mautic is disabled on first bounce.

  1. I read in another post that Mautic retries soft bounces 5 times before disabling. However, when I look at a contact that has bounced once, the Email Channel has already been unchecked. How can I avoid the Email Channel getting unchecked so that I can retry sending an email to soft-bounced contacts?

  2. When I open an individual contact record, I can see a yellow or red icon indicating a soft or hard bounce. However, in the list view of contacts, all bounces (hard and soft) show a red icon. Is this normal? Would this be a feature request to show both yellow and red icons in the list view?

  3. I’d like to be able to make segments that show only soft bounces or only hard bounces. Mautic obviously knows what type of bounce occurred, however there is no way to distinguish soft vs hard bounces in the segment filters. Is there any way to filter this, or is would this be a feature request?

  4. Is there any way to avoid bouncing due to SendGrid IPs being blocked? Is there a way to pass through my own sending IP? A way to retry those bounces when the SendGrid IP gets unblocked?

Thanks

2

Hi Adam.

The behavior is caused by the difference between SendGrid bounce types and the current Mautic callback model.

SendGrid reports:

  • type: "bounce" as a permanent or hard bounce;
  • type: "blocked" as a temporary or soft bounce.

The SendGrid Callback plugin currently maps both events to Mautic’s BOUNCED Do Not Contact status. Because of that, Mautic disables the Email Channel immediately after the first blocked event.

1. Preventing the Email Channel from being disabled

As a temporary workaround, disable Handle blocked events in the SendGrid Callback plugin settings.

Keep Handle bounce events enabled.

This means:

  • hard bounces (type=bounce) will still disable the Email Channel;
  • blocked/soft bounces (type=blocked) will be ignored and will not disable it.

This workaround also means that blocked events will not be stored as a separate soft-bounce status, because Mautic currently has no separate native DNC reason for soft bounces.

The “retry” setting in Mautic should not be confused with recipient-level soft-bounce retries. Mautic’s retry settings are related to failed message processing, not to a provider reporting a blocked recipient after the message has been submitted.

2. Red and yellow bounce icons

This appears to be a Mautic core UI limitation.

Mautic’s standard DNC model distinguishes the email channel and the DNC reason, but it does not expose a separate soft-bounce state in the contact list view. Therefore the list view can display all email DNC records using the same bounced indicator.

The individual contact view may show more detailed information because it can display the stored event comments and bounce reason.

3. Segments for soft and hard bounces

Mautic currently provides a general bounced-email filter, but it does not provide a native segment filter for:

  • soft bounces only;
  • hard bounces only;
  • SendGrid type=blocked versus type=bounce.

The current plugin preserves the SendGrid type, status, and reason in the event comments, but those comments are not exposed as separate segment fields.

A complete solution would require one of the following:

  1. A Mautic core enhancement adding a dedicated soft-bounce data model and segment filters.
  2. A plugin extension that stores SendGrid bounce events in its own table and exposes custom segment filters.
  3. A custom contact field populated by an external automation.

4. SendGrid IP blocklists

The callback plugin does not control the IP used for sending. It only processes webhook events after SendGrid has attempted delivery.

If the recipient server is blocking a SendGrid shared IP, the usual SendGrid-side options are:

  • request delisting or remediation through SendGrid support;
  • use a dedicated SendGrid IP;
  • create a dedicated IP pool;
  • assign the sending traffic to that pool;
  • complete reverse DNS, SPF, DKIM, and IP warm-up.

SendGrid shared-pool IPs can change without notice. Dedicated IPs and IP pools provide more control over the sending reputation. SendGrid Dedicated IP documentation
SendGrid IP Pools documentation

For API-based sending, the SendGrid Mail Send API supports an ip_pool_name property. However, the current Mautic SendGrid callback plugin does not select an IP pool, because it is not the sending transport. The sending transport would need to expose or set that option.

Also note that SendGrid bounce events do not always include the sending IP, especially for delayed/asynchronous bounces. The SendGrid Email Activity data and SendGrid support are the proper places to identify which IP or pool was involved.

Current recommendation

For the current plugin:

  • enable handling of hard bounce events;
  • disable handling of blocked events if temporary SendGrid blocks should not disable contacts;
  • do not retry hard bounces automatically;
  • use a dedicated SendGrid IP or IP pool if the problem is caused by shared-IP reputation;
  • treat separate soft-bounce tracking and soft/hard bounce segmentation as a separate feature request for the plugin or Mautic core.

The current plugin successfully receives and processes SendGrid webhooks, but native soft-bounce retry and soft/hard bounce segmentation are not currently provided by Mautic 7.2.1.

3

I have disabled handling of blocked events in the callback plugin. However, I now have about 200 contacts marked as soft bounces.

  1. What database table/fields correspond so that I can remove the soft-bounce designation and re-enable the email channel for those contacts.

  2. How can I resend an existing email to these contacts, giving time for SendGrid to unblock their IPs, or by purchasing the dedicated IP option? I’m figuring that in Mautic I would need to either unmark as sent those email addresses from the current email, or else identify them in the DB, manually assign a new segment, duplicate the email, and resend. If one of those would be a solution, what tables/fields would correspond?

Thanks