HomeEngagementContentDiscoveryOther Resources

The following are the commonly reported issues regarding [email](🔗) sending using Bloomreach Engagement. _ESP: [Email Service Provider](🔗)_

## Issue 1: Missing/invalid email property error

This happens when the customer [email attribute](🔗) is either empty or does not contain a valid email address format.

To debug this issue, check the email attribute value of the impacted customer profiles. In most cases, the failure generates “enqueue_falied” status campaign events where the message attribute contains additional details about the failure.

To solve this issue, fix the email attribute of the customer

  • Include 'email has value' condition in your [scenario](🔗) to avoid attempting to enqueue messages for customer profiles with an invalid email address

  • If possible, also include more complex conditions to filter only valid email addresses (such as “email contains @”, “email contains .”, etc.)

## Issue 2: Consent/policy error

This happens in two cases:

  • **Consents:** Customer does not have valid [consent](🔗) for given [consent category](🔗) that is used in the communication node settings.

  • **Policy:** Customer has already received the maximum amount of communication permitted by a given [policy](🔗) that is used in the communication node settings.

To debug these issues:

  • **Consents: **Check the customer profile, if they have valid consent for a given consent category.

  • **Policy: **Check the customer profile for all campaign events with the same policy as the one in the campaign that has failed. Validate if the customer has already received the maximum allowed number of communication from all campaigns with this policy within the defined interval.

To solve these issues:

  • **Consents:** Add a condition to the campaign that checks if the customer has valid consent for a given category. That way, customers that do not have this consent are excluded from the scenario, therefore not entering the communication node, preventing unnecessary “enqueued_failed” campaign events.

  • **Policy: **Ensure that customers are not being targeted by too many campaigns with the same policy setting at the same time intervals.

## Issue 3: Bounces/Blocks from ESP level

This happens when ESP has blocked the customer’s email due to either long-term inability to deliver (multiple soft bounces) or inability to deliver with reason that implies long-term inability to deliver in the future.

To debug this issue, check the **[message** attribute](doc:system-events#campaign) of campaign events with soft or hard bounces that precede the suppression and invalidation of the customer.

To solve this issue:

  • Make sure that the customer’s email is valid

  • Whitelist customer’s email on the ESP level. If Bloomreach is managing your ESP integration, contact your CSM, who will reach out to our emailing team to resolve this issue

For more information about bounce management, refer to [this article](🔗).

## Issue 4: email_invalid attribute set to true leading to suppressed campaigns

This occurs when the Bloomreach Engagement platform marks a customer profile with an invalid email because of the information it has received from your ESP about the inability to deliver the communication. This happens to prevent any further attempts to send communication to invalid addresses and to preserve your domain reputation, among other reasons. For more information, read about how sending a communication to invalid email addresses can impact your domain [reputation](🔗).

To debug this issue, you can create a report that will have

  • “email_invalid is true” in the customer filter

  • “count event invalid_contact” in metrics

  • “invalid_contact -> reason” in rows/columns of the report to get information about the reason for the invalidation of the contact

  • “invalid_contact -> source, channel, etc.” in rows/columns of the [report](🔗) to get any additional information about the invalidation of the contact

A report of this type gives you all the information you need to understand the reasons why given email service providers have decided to invalidate the contact.

After investigating the reasons for the invalidation of contacts, follow the solutions for [Issue 3](🔗) in the section above to avoid the blacklisting of given contacts on the ESP level. After that, set the **email_invalid** attribute of impacted contacts to **False** to allow the communication to be enqueued to their email addresses from Bloomreach.

If the whitelisting on the ESP level is done successfully and the contacts are indeed valid and therefore eligible to receive the communication, ESP should send the communication Bloomreach has enqueued for the given customers, resulting in a successful delivery.

## Issue 5: “Enqueue_failed” caused by issues in the content of the communication (jinja, etc.)

This occurs if your communication contains any content that can not be rendered successfully due to given circumstances (such as the absence of the data that you are trying to work with using jinja), therefore, the communication is not sent, and the corresponding campaign event with “enqueue_failed” [status](🔗) is recorded under the impacted customer profile.

To debug this issue, you can preview the **message **attribute of the campaign events with **enqueue_failed** for the impacted customer base or campaign to determine the reason behind the failure of sending given communication. To solve this issue, ensure that all the edge cases are handled correctly and that the provided content behaves as expected for any potential input that it can be rendered with. For example, make sure that there is no data missing for any object that you are referencing, such as an event property or a customer attribute.

## Issue 6: Aborted email

You can use the {% abort %} command, which will stop the execution of the code for a specific customer. The abort feature is usually used in combination with if statement to avoid sending a communication to customers that do not meet certain conditions. For example, using {% abort %} in an email node in a [scenario](🔗) prevents the email from being sent, and the scenario does not continue to subsequent nodes (for the specific customer). If used in an email, you can see the amount of aborted customers in the scenario **evaluate tab** (when you hover over the specific email node).

To debug this issue, check the [email template](🔗) that generated this aborted action and look for the {%abort%} [jinja](🔗) code. The good practice is to use the [syntax](🔗) {% abort: "Custom message" %}. In this case, the action will not only be aborted, but it will also add a campaign event with **status** aborted, and the custom message will be in the **message** property.

To solve this issue, ensure that customers who do not fulfill {%abort%} jinja conditions are filtered out before reaching the email node.

## Issue 7: Emails filtered between ESP and recipient’s mailbox

If [Mailgun](🔗) has confirmed the delivery of the email, the issue is most likely in the email application of the customer.

To debug and solve this issue, check spam/filtering settings and ensure that the application can connect to the recipient email server.

**Recommendation:** Global filters and blacklists (project level setup) [Email list hygiene filter](🔗) allows for project-level filtering of customers who should not receive any email campaign in order to manage the health of the subscribers' list.

## Additional Resources

  • [Bounce management ](🔗)

  • [Email deliverability guide](🔗)

  • [Frequency Policy ](🔗)

  • [Consent Management ](🔗)

  • [Email node settings](🔗)

  • [Email List Hygiene Filter](🔗)

  • [Most common jinja errors](🔗)

Did this article help you?

Please provide your feedback. We would like to know if our help center is effective in solving your queries. You can also leave comments and suggestions on how we can make our help articles better. You can also suggest topics you’d like us to cover.