Bounces in Marketing Cloud Engagement

Messages can fail to deliver for a variety of reasons

Failures that can occur at various points in the delivery process — when our mail agent tries to connect, when it identifies itself, after the recipient is provided, or even after the message is initially accepted for delivery.

Failures can happen immediately when receiving mail servers respond with an error during the delivery connection. At other times, messages are initially accepted by the receiving mail server, but later found to be undeliverable. A ‘non-delivery report’ is then sent to the message return path, notifying Marketing Cloud.

We retry many send failures. If retries aren’t successful, the message is marked as bounced. 

Bounces are an early-warning signal

Bounces are usually communicated by receiving mail providers, and can be either technical or qualitative in nature, such as:

• Misconfigured DNS
• Missing authentication
• Mailbox full
• Mailbox missing
• Poor reputation

Some bounces, like “mailbox full” failures, are routine in nature and senders can feel secure they’ll be automatically handled by our bounce management logic.

Other failures, like those resulting from misconfiguration or poor sender reputation, require the sender’s intervention to correct. Because continuing to send when these conditions are present can worsen reputation and further entrench deliverability issues, it’s important to regularly review bounces to correct problems early.

Many delivery failures are retried as described in Bounce Mail Management in Email Studio

When a failure is considered temporary, additional attempts to deliver are made every 15 minutes for up to 72 hours. When an IP is blocked at an email service provider (ESP) for excessive volume, for example, the restrictions are often based on rolling windows of as little as several hours. To improve the chances of delivery, the failures are retried. Failures that occur while a message is still in its retry period are not marked as bounces. Sending delays - where a message fails initially, but succeeds on retry without a bounce logged - are a hallmark of temporary blocks. 

Other delivery failures are immediately marked as a bounce. Some failures, such as when a domain itself cannot be found, are considered permanent. In other cases, such as when complaints are mentioned in the provider’s error message, we forgo retries to avoid exacerbating a reputation problem.

When retries are exhausted, a message is marked as a bounce

If Bounce Mail Management exhausts its delivery attempts without a successful delivery, the message is marked as a bounce in our platform, represented by a row in the _Bounce data view. The data view can be accessed directly through queries, and is available to data extracts and reporting tools.

If a bounce results from an error generated by the receiving mail service, we log the bounce response in its entirety in the _Bounce data view's SMTPBounceReason column.

Some messages are accepted initially by a provider, but later result in a non-delivery report (NDR) sent to the message’s return-path (also known as the bounce address). The associated messages are marked bounced. Retries don’t apply to these failures because the sending process already completed.

Messages marked as bounced that subsequently record an open or click are marked as a false bounce. 

Bounces are categorized

Bounces as classified along categories and subcategories. Bounce categories help senders understand trends in their send failures, and give insight about how retries are handled:

Because sends are marked as bounced only after we exhaust retries, not all delivery failures are marked as bounces. For example, Soft Bounces are sends that exhausted the 72 hour retry period described in Bounce Mail Management without success. Similarly, Hard Bounces are send failures that were marked immediately as bounced because the platform considers the the failures permanent in nature.

Bounce subcategories are available in the _Bounce data view and provide an additional level of detail. Use them to distinguish between, for example, reputation blocks and blocks due to authentication failures. A list of bounce subcategories and generalizations about appropriate responses are listed in Bounce categories and reasons for Marketing Cloud email sends. 

Our deliverability team continuously reviews failure messages and delivery performance across domains and service providers to determine both how bounces should be categorized and what the best action in response is, at the domain level. The retry logic applied may vary from those listed in the table due to adjustments made for nuances seen at certain domains.

Example bounces

The Tracking tab in Email Studio shows bounce categories. To see bounce responses as listed below, retrieve records from the _Bounce data view using query activities or Tracking Extracts. 

Soft bounces

4.2.2 (SMTP reply matched bounce-rcpt pattern rule) The recipient's inbox is out of storage space. Please direct the recipient to https://support.google.com/mail/?p=OverQuotaTemp

5.2.2 Generating server: IA3PR05MB11016.namprd05.prod.outlook.com ...@hotmail.com Remote server returned '554 5.2.2 mailbox full; STOREDRV.Deliver.Exception:= QuotaExceededException.MapiExceptionShutoffQuotaExceeded; Failed to process

4.3.2 (system not accepting network messages) smtp-10.iol.local smtp-10.iol.local Too many connections, slow down [smtp-10.iol.local; LIB_145]“

4.7.1 (delivery not authorized) Service unavailable - try again later

Block bounces

5.7.1 (delivery not authorized) [CS01] Message rejected due to local policy. Please visit https://support.apple.com/en-us/HT204137

5.7.1 smtp; Message rejected. For more information, go to https://support.google.com/mail/answer/69585

5.7.1 [HME1] This message was blocked for failing both SPF and DKIM authentication checks. See https://support.apple.com/en-us/HT204137 for mailing best practices

5.7.1 (delivery not authorized) Unfortunately, messages from [x.x.x.x] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.

Hard bounces

5.1.2 (bad destination system: no such domain)

5.7.1 (delivery not authorized) Recipient address rejected: User unknown in local recipient table

5.1.1 (bad destination mailbox address) The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. For more information, go to https://support.google.com/mail/?p=NoSuchUser

Recommendation: Review bounces at different aggregation levels

High level bounce counts can alert to the need for a closer look. After observing elevated bounces across a domain, campaign, or recipient domain, drill down to find root causes. 

• Account-level aggregate bounces: To monitor overall IP and domain reputation, using standard reports and pivot tables.
• Job-level aggregate bounces: (sends/audiences/campaigns) To monitor campaign audiences, using standard reports and pivot tables. As seen in the Tracking screen.
• Subscriber-level bounces: To verify IP and domain reputation issues and troubleshoot authentication defects, using individual bounce responses from _Bounce data view query results.

Recommendation: Use bounces in conjunction with other data sources

Bounces are one of many signals that form a picture of your deliverability health. Combine their review with other sources such as:

• Inbox monitoring services, which show the final outcome of a message — Inbox, Spam, or missing. See Marketing Cloud Deliverability Options for integrated services.
• Postmaster data feeds, where MBPs share reputation assessed on your domain or IP. Microsoft SNDS, Google Postmaster Tools.
• Complaints received through feedback loop services. These are inserted in the _Complaint data view and made available to reporting sources.
• Signature customers: Proactive Monitoring bounce alerts