Categories
SFMC

Email Bounce Management — SMTP Replies and Enhanced Status Codes

Deliverability is a way to measure the success at which an email marketer gets a campaign into subscribers’ inboxes. It is impacted by things like ISPs (internet service providers), MTAs (mail transfer agents), throttling, spam, bounces and bulking. In this post, I want to touch on bounces.

A subscriber is marked as “bounced” when their receiving email server rejects an email that you send. This rejection can mean that the email address is invalid or their inbox is inaccessible at the time of send.

ISPs send messages back to Salesforce Marketing Cloud reflecting the response provided by the recipient’s server explaining why they cannot deliver your email. Interpreting these bounce responses helps you understand why your message bounced and how to fix the problem.

Breaking Down Bounce Rates

  • Bounce Rate: The percentage of total emails sent that could not be delivered to the recipient’s inbox. There are two types of bounces — a hard bounce and a soft bounce. The main differentiator between the two is that hard bounces are permanent and emailing to them should not be attempted again, whereas soft bounces are temporary and can be re-tried.
  • Soft Bounce: result of a temporary problem with a valid email address, such as a full inbox or a problem with the recipient’s server. The recipient’s server may hold these emails for delivery once the problem clears up, or you may try re-sending your email message. Generally speaking, bounces that begin with a 4xx explanation are considered soft or transient delivery failures. This means they can be reattempted for delivery and may still have a chance of being accepted by the receiving domain…at a later time.
  • Hard Bounce: result of an invalid, closed or non-existent email address. These emails will never be successfully delivered. You should immediately remove hard bounce addresses from your list because ISPs use bounce rates as a key factor to determine sender reputation. Having too many hard bounces can make your company look like a spammer in the eyes of an ISP. If a bounce begins with a 5xx code and message pertaining to a permanent failure, then it is considered a hard bounce. Reattempting delivery of these bounces is not likely to succeed and may in fact do further damage to a sender’s reputation.

The bounce data view can be queried in Automation Studio to retrieve detailed information surrounding all bounces from Marketing Cloud sends.

There are a number of fields in this data view that can be difficult to interpret. For example, what exactly is an SMTP Reply Code? How is it different to an Enhanced Status Code? How should I filter my queries to isolate certain types of bounces?

When you send an email, the receiving mail server returns a code indicating the status of the message delivery. This is known as an “SMTP response code” and is part of the normal email sending process. A bounce is logged by interpreting the specific response code that relates to unsuccessful message delivery.

Each SMTP call you make returns a response. Generally, 200 and 300 response codes are normal response codes that do not indicate an error. 400 responses are usually soft bounces. 500responses are hard failures.

With soft bounces, SFMC retries sending the email to the subscriber every 15 minutes for 72 hours, for up to 288 tries. Only after the system stops attempting to retry does a subscriber appear in your tracking as Bounced.

Breaking Down SMTP Codes

Nowadays, SMTP responses can be broken up into three parts:

  1. Basic status code
  2. Enhanced status code
  3. Reply message
Image source: https://support.google.com/a/answer/3221692
  • Reply Code / Basic Status Code: first defined in 1982 (see RFC 821), this response is limited to three digits. They are also referred to as basic status codes since “enhanced status codes” were created 14 years later. This response is used to communicate the success or failure of every SMTP command. This value is returned by selecting the SMTPCode column from the _Bounce data view in your SQL.
  • Enhanced Status Code: defined in 1996 and expands upon the basic status code, it uses a series of 3 digits separated by decimal points. The enhanced status code offers more granularity and answers the larger question “tell me why my email delivery failed?” This value is returned by selecting the SMTPBounceReason column in your SQL.
  • Reply Message: the text string regarding the bounce relayed by the mail system. This message is meant for human consumption, while the codes are typically meant to be read by machines.
SMTPCode ⟺ Basic Status Code
SMTPBounceReason ⟺ Enhanced Status Code

Marketing Cloud’s own defined bounce codes

The below fields are Marketing Cloud defined codes based on the “smtp” data sent from the recipients Mail Transfer Agent:

  • BounceCategory
  • BounceCategoryID
  • BounceSubcategory
  • BounceSubCategoryID

I have compiled all the status codes in the workbook below.

Part of the inherent problem with SMTP codes is that different servers use the same reply codes in various ways, making it incredibly difficult to state with certainty the meaning of each code.

When doing any bounce investigation it is best to take a holistic approach. Rather than simply looking at one status code by itself (eg: BounceSubCategoryID) your best approach would be to interpret ALL the reply codes holistically to better understand the cause.

The below query will join the All Subscribers list with the bounce data view to return log all “block bounces”.

If you need help with interpretting SMTP bounce codes, IP warming or bounce mail management please reach out.

Categories
SFMC

Salesforce Marketing Cloud Release May 2020

We’re back again with the upcoming May 2020 release, the third Marketing Cloud release of 2020. So we have picked out some of the most interesting parts of the release, if you wish to review the full release article it can be found here.

Journey Builder Updates

Pause and Resume Journeys: With the ability to pause and resume journeys, one won’t need to stop running journeys to temporarily halt sending messages from Journey Builder for any foreseeable business reasons.

Single Send Push Notifications: For simpler Single Sends in Journey Builder, it now supports push notifications.

New Path Optimiser: The new activity in Flow Control allows the marketers to experiment with the marketing strategies based on email engagement metrics or other outcomes. The  Path Optimiser acts like an A/B test within Journey Builder, however, provides up to 10 paths to trial your ideas with. The winning path receives the new contacts and losing paths will shut off during the testing.

Platform Enrichment

Fallback address in Sender Profiles: If you use dynamic sender profiles using AMPscript, you can provide a backup address if the dynamic send address isn’t verified in From Address Management and can’t be displayed.

Note: This functionality is also available with Domain verification REST and SOAP APIs.

SSH keys per SFTP Account: With the availability up to 3 SFTP Accounts per MID in the last release, you can now configure authentication per user using a password, SSH key only, or a combination of both.

New CloudPages Experience PREVIEW: We’ve all seen the same experience in classic CloudPages app since the dawn of time. Nonetheless, a new preview New CloudPages Experience PREVIEW will be made available in the Web Studio app switcher dropdown for the users to get familiar with the new features and enhancements like content and collection sorting and the ability to copy existing content.

API and Development

With the development and APIs being an integral part of the DevOps process, here are some technical updates:

Action Required – Update your MobilePush iOS auth key: If you have an iOS app integrated with MobilePush, you’ll need to migrate onto Apple’s new sending service as Marketing Cloud will remove support for MobilePush .p12 Certificates in July 2020, and instead use .p8 Auth Keys when sending iOS push notifications. To avoid the iOS message failure please follow steps here.

New MobilePush SDK version: The latest version of the Marketing Cloud MobilePush SDK includes improvements to performance, analytics processing, and privacy-mode handling. You get the latest version for iOS and Android post the release.

New Journey Builder API: Have you ever wanted to pause/resume journeys via API, well now with the introduction of the new endpoints, you can pause and resume journeys up to 14 days.

Note: This also means that the functionality to pause and resume will be available in the graphical interface within Journey Builder.

Force Inline Attachment: If you want to attach images and other documents, instead of including them inline, AttachFile() AMPscript now supports the enforcement to inline attachments using the new 8th boolean parameter force_attachment.

Einstein Refinement

Salesforce’s AI solutions “Einstein” has made remarkable progress in Marketing Cloud recently with a noticeable appearance in the platform. Some of the key advancements coming into this release include:

  • Send Time Optimisation Recommendations: Finally, the app provides granular information about how the model works including scores for all hours and days in a week.
  • New Send Time option Journey Builder: The new option in Einstein Send Time Optimisation activity in Journey Builder will allow the marketers to test whether to send emails to contacts at random times, at a single time or Einstein’s recommended times.
  • New Performance Dashboards: The new dashboard is aimed to show live performance metrics for each Einstein product in your Marketing Cloud org.

Wait, there is more…

Apart from the above, there are some key honourable mentions:

Access Image URLs Faster: Users can now access the public image URLs directly from the drop-down menu instead of from the properties view.

New Marketing Cloud Trailheads: Salesforce has been promoting the users to learn about their products and services via Trailhead. And if you haven’t tried yet, the interactive tool has heaps of modules for marketer, admins and developers. Here are some new modules and trail mixes coming into the release:

Retirements and Migration

With every release, there are always some features being decommissioned and it is crucial to know those to ensure there is no obstruction in the development or BAU processes.

  • Classic Builder retirement: It is time to move into the Content Builder if you’ve managed your campaigns via Classic Builder in Marketing Cloud. The retirement begins from June 2020 which will remove the creation of new emails and by January 2021, the ability to edit emails will be deprecated.
  • MC Connect A/B Test retirement: As with the retirement of the Classic Email Builder, the ability to A/B test in Sales and Service Cloud retires January 2021.
  • Deep Links retirement: If you access Marketing Cloud to create or edit emails directly using the deep links in Salesforce CRM, this functionality will retire coming October.
  • Action Required – Cross-Cloud Authentication: If you have Sales and Service Cloud integration with Marketing Cloud, regardless of MC Connect or V5, both need to move to the Connected App authentication by July 31, 2020.