Most Common Email Issues

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 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 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 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 of campaign events with soft or hard bounces that are preceding the suppression and invalidation of the customer.
To solve this issue:

  • Make sure that 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 Bloomreach Engagement platform marks a customer profile with an invalid email because of the information it has received from your ESP about 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 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 customer filter
  • “count event invalid_contact” in metrics
  • “invalid_contact -> reason” in rows/columns of the report to get information about the reason of 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

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 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 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. Abort feature is usually used in combination with if statement to avoid sending the 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.
Refer to this document to know more.

Additional Resources

👍

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.