How do I investigate bounce reasons hidden in “Others”? – Help Center

When a campaign's bounce report groups many failed sends into Others – Other, the dashboard alone can't tell you why those emails failed. The raw rejection reason is still stored on the underlying campaign event. This guide shows you how to check the reason for a single customer, build a report that surfaces it at scale, and gather the right evidence before you escalate a case to support.

Why do some bounces show as "Others"

Every email you send generates a campaign event with a status attribute, for example soft_bounced, hard_bounced, or preblocked. Bloomreach uses these statuses to classify bounce categories for reporting, but a rolled-up category does not necessarily include the underlying reason.

The SMTP rejection text lives in other attributes on the same event:

message – the diagnostic text your email provider returned, for example, "user unknown" or "mailbox full."
error – an error value that may provide additional detail when it is available.
code – the raw SMTP reply code, for example, 550 or 421. This is the most precise attribute, because the same status can result from several different codes. It's only populated when you use a Mailgun integration.

When a provider returns text that Bloomreach can't map to a named category, it still tracks the event with its real message, error, and code values — the category displays as Others – Other. Drill into those attributes to recover the real reason.

Build a report to reveal the reasons behind "Others"

Use a report when you need the breakdown across an entire campaign or time range, not just one customer.

Go to Analytics > Reports and create a new report.
Set the metric to a count of campaign events. Filter it to your campaign and channel — for example, action_type equals email and status in hard_bounced, soft_bounced, preblocked, or enqueue_failed.
Add a drill-down for the message attribute, or for error/code if you use a Mailgun integration. This turns the generic Others – Other bucket into individual rejection texts.
Set Grouping to Top so the most frequent raw reasons rise to the top of the table instead of getting lost among long-tail values.
Leave out drill-down attributes that don't apply to bounce events, such as sending_ip, which is only tracked on delivered events. Combining an unrelated attribute with a bounce filter returns N/A instead of your data.

The resulting table shows each distinct SMTP message next to its count, so you can see which rejection texts make up your Others bucket and how much of the drop in your delivery rate they account for.

Check the bounce reason for one customer

If you want to investigate the bounce reason for a specific customer, you can use the report you created above to identify which recipients received the error.

In the report, add the recipient as a drill-down attribute to see which customers received the error.
Find the affected customer and copy the recipient value, typically their email address.
Go to Data & Assets > Customers.
Search for the customer using the "email" attribute and paste the recipient's email address. Alternatively, you can search using the hard_id attribute (for example, email_id) if that is the identifier configured in your project, using the recipient value from the report.

OR
Go to the Properties and events tab and filter the events for the campaign you're investigating.
Find the relevant bounce event and expand it to inspect the message, error, and code attributes, where available, to identify the underlying cause of the rejection.

Escalate with the right evidence

If the available event details point to a provider-side or account-level issue, gather the following evidence before opening a ticket. This helps support investigation without unnecessary back-and-forth:

The campaign ID or a direct link to the campaign.
Your project or environment URL.
The exact date and time range of the affected send, in UTC.
The email integration you use — Mailgun, Mailjet, Brevo, or another ESP.
The count and percentage of sends that fell into Others – Other.
A link to the report you built with the message, error, comment, or an available code drill-down applied.
The affected recipient domain, if the pattern is domain-specific.

Prevent repeated other bounces

Clean your email list regularly and remove addresses that repeatedly hard-bounce.
Validate new audiences before sending, especially for welcome or warm-up scenarios.
Increase your sending volume to a domain gradually rather than sending one large batch at once. A sudden spike to a previously low-volume domain can trigger reputation-based rejections on its own.
Review bounce reasons and error messages whenever the delivery rate drops unusually, not only after a major incident.
If you send both marketing and transactional email from the same domain, separate them onto different subdomains to isolate sender reputation.

Read the Email deliverability dashboard documentation.
Read the Email bounce management documentation.
Read the Email bounce investigation guide.
Read the Monitor email deliverability dashboard documentation.