Skip to main content

Why aren't my emails being delivered?

Updated

Understanding email delivery delays

When a scenario finishes, Bloomreach has completed its part — evaluating conditions, applying filters, and handing emails off to the configured Email Service Provider (ESP). A finished scenario does not mean all emails have already reached the recipient's inbox. Delivery involves several parties after Bloomreach's handoff, and delays can occur at any of those stages.

This article explains the email delivery lifecycle, what can cause delays after a scenario finishes, and what to check or include when contacting support. 

How email delivery works

To understand where a delay can happen, it helps to see the full path an email takes:

Bloomreach → ESP (for example, Mailgun) → Recipient mail server (for example, Outlook, Gmail) → Inbox

  • enqueued — Bloomreach has handed the email to the ESP. Bloomreach's role in sending is complete at this point.

  • delivered — The ESP received a success response from the recipient's mail server, confirming it accepted the message. This does not mean the email has reached the inbox — the server may still process it through spam filtering, quarantine checks, or internal queuing before it appears.

Once the enqueued event is recorded, and any delay that follows is typically outside Bloomreach's control.

For more on email statuses, see: Email tracking and delivery statuses

Delays after the scenario finishes

These are the most common reasons why an email may not yet be delivered, even though the scenario is already finished and the enqueued event has been recorded.

1. Recipient mailbox provider throttling

The most common cause is throttling by the recipient's mail server — particularly Microsoft/Outlook and Gmail.

When a mailbox provider accepts a message but queues it internally before placing it in the inbox, Bloomreach records a delivered event (because the server responded with a success code), but the email may not appear for several minutes or even hours.

This is more likely when:

  • Sending volume increases suddenly compared to your typical sending patterns

  • You target a significantly larger audience than usual

  • You send to a segment that has not been mailed recently

Mailbox providers monitor sending patterns and may slow down or hold delivery when they detect unusual activity. They do not share specific reasons for throttling in their server responses.

To reduce the likelihood of this for time-sensitive sends:

  • Increase sending volume gradually rather than in sudden spikes.

  • For large campaigns targeting Microsoft/Outlook recipients, consider splitting the send into smaller waves.

  • Prioritize your most engaged recipients for time-sensitive campaigns — higher engagement supports a stronger sender reputation with mailbox providers.

  • Avoid targeting audiences that have not been mailed recently for urgent or time-critical sends.

For more guidance: Email deliverability tips

2. Sending provider incident

If emails across multiple campaigns or projects are delayed simultaneously, the cause may be an incident on the ESP (Email Service Provider) side rather than something specific to your campaign.

During a provider incident, emails remain in enqueued or accepted status and do not progress to delivered. Once the incident is resolved, delivery resumes automatically for messages that have not permanently failed. If an email is still in enqueued with no failed event, it does not need to be resent — the provider will continue retrying it.

Only messages that receive a permanent failure event would need to be resent.

You can check the current status of Bloomreach's supported sending providers on their respective pages:

Note: EmailLabs, Omnivery, SendSay, and UniOne do not have a public status page. If you suspect an incident with any of these providers, contact Bloomreach Support directly.

  • Oracle Responsys — no traditional status page; Oracle notifies affected customers directly by email and posts maintenance updates on the Oracle Customer Connect community

You can also check Bloomreach's own status page for any platform-side incidents.

Delays that can occur before the scenario finishes

If you are experiencing delays but the scenario has not yet finished running, the cause is likely earlier in the process. The following are not about why a delivered email is missing — they explain why emails may not have been sent yet, even when the scenario appears to be running.

1. Scenario wait node or sending window

A configured Wait node or a defined sending window within the scenario can hold customers at a certain step until the wait period ends. If fewer deliveries than expected are showing up or emails are arriving later than anticipated, check the scenario's Evaluate tab to see if customers are still in a Wait node before reaching the email node.

2. High campaign load

When a large number of campaigns are scheduled to run at the same time, the actual processing of the send can slow down — meaning the enqueued event itself may be delayed, even though the scenario has technically started. If your campaign is taking much longer than expected to reach a large audience, staggering large sends or scheduling them outside peak hours can help reduce this delay.

How to identify where the delay happened

Check

What to look for

What it means

Scenario Evaluate tab

Are customers still in a Wait node?

The send is intentionally held — the scenario has not finished for those customers yet

Customer profile Events tab

Is enqueued missing entirely?

Email has not been handed to the ESP yet

Customer profile Events tab

enqueued exists but no delivered

Delay is after Bloomreach's handoff — ESP or recipient side

Affected recipients

Delay limited to one domain (for example, Outlook, Gmail)?

Likely recipient-side throttling for that provider

Scope of impact

Multiple campaigns or projects affected at once?

Could indicate a sending provider incident

What to include when contacting support

Having the following ready will speed up the investigation:

  • The affected project name and a link to the scenario or campaign

  • 3–5 example customer profile links (including their email address) where the delay was observed, with enqueued and delivered timestamps visible in the Events tab

  • The approximate time at which the scenario was started

  • The recipient domains involved (for example, Outlook, Gmail, iCloud)

  • Whether the delay affects all recipients or only specific domains

  • Whether any emails show a failed status — if not, the provider may still be retrying

When to contact support

Reach out to Support if:

  • The delay affects a large number of recipients or multiple campaigns at the same time

  • Emails remain in enqueued for an extended period with no delivered events appearing

  • You need help determining whether the delay occurred before or after the enqueued event

  • You suspect an issue with the sending provider

Related articles