Loading

How to Handle Block Bounce Occurrences

Veröffentlichungsdatum: Oct 31, 2025
Beschreibung

What is a Bounce?

When an email is sent from Marketing Cloud but isn't received by the recipient's side (e.g., ISP, carrier) for some reason, it's called a bounce email.

Reference: Bounce Mail Management in Email Studio

There are several types of bounces. Marketing Cloud classifies them based on the bounce message returned by the recipient's server (e.g., SMTP bounce codes) into the following categories:

Reference: Bounce categories and reasons for Marketing Cloud email sends

This document will explain the aspects related to block bounces among these bounce classifications.

What is a Block Bounce?

A block bounce refers to a bounce that occurs when the recipient's side restricts email reception from the sender based on the following conditions/causes. While often categorized as a type of soft bounce, Marketing Cloud manages it separately from other soft bounces.

Here are the potential causes of a block bounce:

  • Sending to Invalid Email Addresses: If a certain volume of emails is delivered to non-existent email addresses, the sender may be deemed a spammer who hasn't confirmed opt-in, leading to other deliveries being blocked.

  • Spam Complaint: When the recipient of an email reports the sender's email as spam, the ISP blocks it.

  • Email Content-Related: Email content (such as images or URLs) matches criteria defined by the ISP and is consequently blocked as spam.

  • Blocklist: The IP address of the sender's email server is registered on the recipient's blocklist. Besides lists managed solely by ISPs, there are also those managed by third-party services (so-called DNSBLs).

  • Delivery Volume: The volume of emails sent from the sender exceeds the criteria set by the ISP (e.g., exceeding the allowable number of receipts within a certain period), leading to restricted reception.

  • Sender Domain Authentication Failure (Treated as Spoofing): If authentication like SPF or DKIM fails due to misconfiguration or other reasons, the email is rejected by the recipient's policy, often treated as a spoofed email.

  • Insufficient Sending IP Address Warm-up: The email is blocked due to insufficient reputation score, such as when IP warm-up has not been adequately performed.

Even for the same block bounce, the resolution method will vary depending on the conditions and causes listed above.

While the cause of a block bounce is usually identified based on the content within the bounce message, a clear cause cannot always be determined due to points like the following:

  • The bounce message may not contain specific information.
  • The bounce message may not always accurately state the true cause.
  • Even if an inquiry or complaint is made to the ISP, a clear answer or resolution may not be obtained.

Therefore, please also note that it's fundamentally necessary to implement comprehensive and regular countermeasures, such as the confirmation points discussed later.

Furthermore, for regular checking of bounce occurrences, we recommend using the _bounce data view, which will be discussed later, or utilizing Intelligence Reports for Engagement.

Please note that, depending on the ISP (or the nature of the block), a block bounce can be either "permanent" (requiring the ISP or DNSBL to manually lift the block) or "temporary" (e.g., automatically lifted after 24 hours). However, this information is generally not public, making it difficult to determine which type of block you're facing from surface-level observations.

If the block has been occurring continuously for a certain period, it's possible it's a permanent block. In such cases, you may need to contact the ISP to inquire or request a block removal.

Lösung

Key Points to Check When a Block Bounce Occurs

When a block bounce occurs, here are the key areas to investigate:

  • Identify the bounce reason: Use a Data Extract Activity or Query Activity (on the _bounce data view) to check the value of the SMTPBounceReason and pinpoint the bounce cause from the information provided.
  • Check for hard bounces: See if a large number of hard bounces occurred in the relevant delivery or immediately preceding deliveries.
  • Review send volume: Determine if the number of sends for the relevant delivery and those at the same time has drastically increased compared to previous trends.
  • Verify sender domain authentication: Confirm that sender domain authentication methods like SPF and DKIM are correctly applied.
  • Examine email content size: (When compared to deliveries where blocks did not occur) Check if the file size of images used is extremely large, or if the data size of the email body (text or HTML source) is excessively large.
  • Assess unsubscribe process ease: Evaluate how easy it is for subscribers to unsubscribe (if the unsubscribe process is complicated, subscribers might report the email as spam instead of unsubscribing legitimately, which ISPs can then use to flag the sender as a spam source).

 

Requesting Block Removal with ISPs

After reviewing the points mentioned above, if the block persists despite corrections, or if the correction method is unclear, you might need to ask the ISP directly for block removal.

When submitting a block removal request to an ISP, please include the following information:

  • Date and time when the block bounce occurred
  • Number of deliveries to the relevant ISP domain when the block bounce occurred
  • "From" address and email subject used for the delivery
  • Confirmation details for each of the checking points mentioned earlier

If you require information from Salesforce (e.g., for an ISP application), please create a support case with Salesforce Support, including the following details in addition to the above:

  • The JobID of the delivery where the block occurred
  • The target domain where the block occurred
  • Status of your IP warm-up efforts

 

Nummer des Knowledge-Artikels

000395280

 
Laden
Salesforce Help | Article