Delivered, Bounced, Blocked, and Deferred Emails

Great email marketers are always finding ways to tell more compelling stories with their data. Stories, you ask? Yes, your data tells a great many stories that can help you, the sender understand what’s happening with your email campaigns.

Are people registering too many spam complaints? Are my open rates changing? Why are so many people opting out of my messages? The data you get back when you send a campaign, and the questions raise those data points, are the starting points for understanding what story your results tell you.

Naturally, data points such as opens and spam complaints tell you quite a bit about how recipients interact with your messages. However, there are important events in the journey of your message that are just as meaningful and are often overlooked by marketers.

When you send an email to your subscribers via Twilio SendGrid, there are really only a few things that can happen to that message between SendGrid and the receiving server. Those events are:

• Delivered: The receiving server accepted the message
• Bounce: The receiving server denied the message and the address sent to is suppressed by SendGrid moving forward
• blocked: The receiving server denied the message and the address isn’t suppressed by SendGrid moving forward
• Deferred: The receiving server delayed acceptance of the message

Let’s take a quick look at what each of those events means to help you glean a better picture of your email delivery performance.

Delivered

A common misconception that I often run into is that a delivered message is a message that made it to the inbox. When a message registers as delivered, that simply means the receiving server has accepted the message from SendGrid. At that point, the receiving server still has to decide what to do with that message.

Most often, the 2 options facing that server are to deliver the message to the intended inbox or to send it to the spam or junk folder. Less frequently, a receiving server might choose to simply drop that message, which is akin to the receiving server simply deleting it. In those cases, the recipient won’t be able to find the message, even if they look for it in their spam folder. Dropping a message is rare, though it can happen.

Almost always, the decision about where to put the message comes down to the sending reputation of the sender and the content sent. Senders who generate excessive spam complaints from recipients, or senders sending content known by inbox providers to generate high rates of spam complaints, are much more likely to see their emails not make the inbox. Having a high percentage of delivered emails is great. However, simply getting emails delivered is only part of email success.

bounced

While some in the industry use terms like “hard bounce” and “soft bounce” to describe messages refused by the receiving server, SendGrid’s terminology separates returned messages into bounces and blocks.

bounces occur when the receiving server returns to us a code that indicates that the reason for the refusal is a permanent issue with that server or recipient address. The most common reason an address will bounce is that the address in question is not valid. If you are using SendGrid’s Event Webhook to digest your email events, a bounce will be under the bounce event with the type “bounce.”

Blocked

Similar to what you may have heard referred to as a “soft bounce,” blocked emails are ones where the receiving server returned to us a reason for refusal that indicates a nonpermanent rejection for that address. In short, it’s a rejection of that message and not an indication of the quality of the sent to address.

Common reasons a message might be blocked are if your sending IP or domain has been list denied, the content of your campaign contains elements the inbox provider deems “spammy,” or there was a technical issue that occurred between the 2 servers at the time you attempted to send the campaign.

While elevated rates of spam complaints will mean more emails filtered to the spam folder, these can also result in blocks due to a poor sending reputation. With SendGrid’s Event Webhook, blocks are identified by the bounce event under the type “blocked.” Seeing lots of blocked messages is a good indicator that your sending reputation might be suffering.

deferrals

A deferred event, or deferral, is simply an event SendGrid has received back from the receiving server that tells us that the receiving server has temporarily limited access to their system. If you’re like me and old enough to remember life before call waiting and cell phones, you can think of this like a busy signal.

It doesn’t mean that your message will not be delivered. Rather, it’s a signal that your message will not be delivered immediately. This can happen for a variety of reasons. Some of the most common reasons a message might be deferred at an inbox provider are that the inbox provider is seeing too many spam complaints for your email that has already been delivered or the receiving server is having technical issues at that time.

When SendGrid sees your mail being deferred at a particular inbox provider, we’ll continue to try to deliver that message for you for up to 72 hours. If a message to a recipient is deferred for more than 72 hours, that deferral will turn into a block. Otherwise, it’ll result in a delivery event once the message has been accepted by the receiving server.

Get help delivering to the inbox with Twilio SendGrid

Keeping an eye on these events can give you even more insight into what is happening with your emails as they journey from Twilio SendGrid to the recipient’s inbox. If you’d like to dive deeper into your email delivery health, check out our Email Deliverability Guide.

And if you’re using SendGrid’s Event Webhook to digest your data, we have some great info in our documentation on the different events you have access to our documentation.