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.
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:
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.
When a block bounce occurs, here are the key areas to investigate:
_bounce data view) to check the value of the SMTPBounceReason and pinpoint the bounce cause from the information provided.
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:
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:
000395280

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.