Email Bounces: Types, Causes, and Handling

A guide to bounce types, Batch policies, and how to handle delivery failures.

When a campaign or orchestration sends emails, Batch can receive delivery feedback from three sources:

• Batch sending servers: before delivery, when a targeted address is already part of the suppression list.

• DNS servers: when no information is found for the domain associated with the targeted address, or when the target server has no configuration allowing email reception.

• Mailbox providers, like Gmail: when the email cannot be routed for reasons specific to them (e.g., technical issues, email address status, sender reputation).

There are several types of bounces Batch can show for your campaigns and automations:

Information on bounces is:

• Summarized in the stats of each campaign/automation.

• Displayed in detail in the profile view for each profile (bounce type and bounce reason).

• Returned, per recipient, in the event exports available via the Profiles API (fields: bounce_type and bounce_code).

Soft Bounces

→ Understanding Soft Bounces

About Soft Bounces

Soft bounces are temporary delivery failures that can happen for various reasons:

• Misconfigured or unreachable inbound server

• Inbox full (or "over quota")

• 24 hours of failed delivery due to rate limiting

• And more

Batch Policy

• Inbox full: Batch will consider a recipient permanently unreachable after 5 consecutive bounces due to a full inbox across different campaigns or automations. The email address will be added to the marketing suppression list and excluded from future marketing communications.

• Other soft bounces: Batch will retry delivery after a soft bounce to attempt re-delivery (e.g., in cases of delivery delays). If retry attempts are unsuccessful after 24 hours, Batch will mark the bounce as a soft bounce.

Recommended Action

If you export soft bounces regularly for recipient qualification and user base hygiene, handle these bounces differently depending on the bounce code provided in the exports (field: bounce_code of the API data export).

→ Soft Bounce Types

Type	Bounce Code	Description
Auto-Reply	auto_reply	An automated response was received (e.g., out-of-office).
Challenge-Response	challenge_response	The receiving server sent an automated challenge that Batch, as a sending system, cannot respond to, preventing delivery.
DNS Failure	dns_failure	No DNS record found for the recipient domain.
Generic Bounce	generic_bounce	Temporary failure with no specific reason provided.
Mailbox Full	mailbox_full	The recipient's inbox has insufficient storage space to receive the email.
Timeout	timeout	The receiving server did not respond within the allowed time.
Too Large	too_large	The message exceeds the size limit accepted by the receiving server.
Transient Failure	transient_failure	The receiving server uses a sender verification system that requires a manual email confirmation before accepting the message. As Batch sends from a no-reply address, this challenge cannot be completed and the email is never delivered.

Hard Bounces

→ Understanding Hard Bounces

About Hard Bounces

Hard bounces are permanent delivery failures. Batch receives hard bounces in cases of:

• Invalid email addresses (mistyped, nonexistent, or deactivated)

• Deleted or deactivated email accounts

• Domains that no longer exist

• Blocked sending domains due to invalid or inactive email addresses

Batch policy

Bounced recipients will be permanently added to your Batch project's transactional and marketing suppression lists, meaning they will be excluded from all future marketing and transactional communications.

Handling Hard Bounces

Hard bounces are a normal occurrence: people may make mistakes when typing their email addresses, or forget to update their address after switching providers (and losing access to their long-used address).

If you export hard bounces regularly, the following guidance applies.

1. Spikes of hard bounces

Spikes of hard bounces should be treated as a direct risk to your sender reputation or as a sign of an email collection quality issue:

• Bad sending habits: You may have mistakenly targeted segments of inactive users, which is likely to damage your sender reputation and cause you to hit spam traps.

• Segmentation issues: Especially during warmup, hard bounces should be minimal when targeting engaged recipients. Review your segmentation rules or data quality if this is not the case.

• Bot attack: Your subscription form may lack sufficient protection, allowing bots to register hundreds of fake email addresses.

In all these cases:

• Remove the address from your user base, beyond Batch.

• Mark them as unreachable. Consider showing an alert the next time the user logs in to your service, prompting them to re-enter their current email address.

2. High hard bounce rates for onboarding campaigns

This may indicate subscription or signup form UX issues: users may be struggling to enter their email addresses correctly.

→ Hard Bounce Types

Type	Bounce Code	Description
Generic Bounce: No Recipient	no_recipient	The message could not be delivered because no valid recipient was found.
Invalid Recipient	invalid_recipient	The email address does not exist or is no longer active.

Block Bounces

→ Understanding Block Bounces

About Block Bounces

A block bounce occurs when an email server refuses to accept the message due to policy or reputation issues. This is usually caused by:

• Poor sender reputation

• IP address or domain blacklisting

• Content identified as spam

• Authentication failures (missing or incorrect SPF, DKIM, or DMARC records)

• Rate limiting (sending too many emails too quickly)

• Policy blocks (the receiving server has specific rules against your type of email)

Batch Policy

Block bounces do not result in an addition to the suppression list or an unsubscribe.

Handling Block Bounces

Block bounces can happen in isolation or be tied to a wider IP or subdomain block.

Monitoring these events allows you to:

• Trigger internal alerts and identify business-critical issues, so you can start an investigation and request mitigation.

• Once the block is resolved:

  • Resend time-sensitive emails that could not be delivered (e.g., password reset links, double opt-in confirmation emails).

  • For newsletters, if they are still relevant, create an audience based on the export of the block bounces to allow your CRM team to retarget these recipients later.

→ Block Bounce Types

Type	Bounce Code	Description
Mail Block	mail_block	The receiving server has blocked the message based on a sending policy.
Relaying Denied	relaying_denied	The receiving server does not allow relaying for this sender.
Spam Block	spam_block	The sender's IP or domain is blacklisted.
Spam Content	spam_content	The message content has been identified as spam.
Prohibited Attachment	prohibited_attachment	The message contains an attachment type not accepted by the receiving server.

Admin Bounces

Admin bounces occur when an email is not sent due to Batch policies. This happens when the targeted email address is part of a suppression list.

Each Batch project has two suppression lists:

• Transactional suppression list: Used as a filter before sending transactional emails. It contains email addresses that have hard bounced following a transactional or marketing email send.

• Marketing suppression list: Used as a filter before sending marketing emails. It contains:

  • Email addresses that have hard bounced following a transactional or marketing email send.

  • Email addresses that have been unreachable after 5 consecutive bounces due to a full inbox across different campaigns or automations.

When you send a campaign, Batch attempts to reach all recipients first. Some of these recipients will then result in an admin bounce because they are already part of the transactional or marketing suppression list.

Type	Bounce Code	Description
Admin Failure	recipient_in_suppression_list	The targeted address is already part of a suppression list and was excluded before sending.

Undetermined Bounces

Undetermined bounces occur when Batch receives feedback from a mailbox provider that could not be properly categorized or whose reason could not be identified.

This usually happens with "out of band" bounces: bounces received asynchronously, after the initial SMTP session has closed, meaning the receiving server accepted the message during delivery but later determined it could not be delivered and returned a Non-Delivery Report (NDR) to the sender.

Type	Bounce Code	Description
Undetermined	undetermined	The bounce reason could not be identified or categorized.