Before a message gets deployed, we perform checks to see if a campaign is going to someone that could hurt the sender’s deliverability and reputation with mailbox providers. For example, one main check we perform is to find any subscribers that don't have a valid email address (hard bounce) or have classified the sender’s campaigns as spam (spam report). Whenever someone like this is identified, that subscriber is considered unmailable and is thus unsubscribed from this promotional list (transactional sends will be mailed regardless). Our system records this as a “drop” event. Drop means that no actual attempt was made to deploy the message, therefore there is no deliverability effect on the email program because mailbox providers never saw it.
NOTE: Bluecore does not display drop data in the UI, however the deliverability team does have access to these stats for troubleshooting.
Once a message is deployed, the sending mail server attempts to communicate with the receiving mail server in an attempt to successfully send the message over SMTP (Simple Mail Transfer Protocol). During the initial exchange, information is passed on including: sending IP address, sending email address, and recipient’s email address, among other details. Based on this information, the receiving server can decide quickly whether or not to outright reject the request. At this point, any of the following can occur:
Delivered - The receiving server accepted the message into their network
Bounce - The receiving server has rejected the message
Deferred - The receiving server delayed the acceptance of the message
A common misconception is that a “delivered” message has made it to the inbox. When a message registers as delivered, that simply means the receiving server has accepted the message into their network. After a successful delivery, the receiving network (mailbox provider) still has to decide whether to send that message to the inbox or spam folder. There are no logs or events sent back regarding inbox filtering. Tracking successful delivery is still a vital part of deliverability. At Bluecore the average delivered rate is 99%+ across all email programs.
A bounce occurs when the receiving server rejects the message from entering the network. The bounce is given a reason, or error code, and returned back to the sending mail server to log, and be made available for troubleshooting. All non-delivered messages are bounces. Bounces fall under two categories: hard bounces and soft bounces.
Hard Bounce: These occur when the receiving server returns an error code that indicates that the reason for the refusal is a permanent issue with that server or recipient address. The most common reason is that the address in question is not valid. That means that the email address doesn’t exist or that the domain doesn’t exist. A single hard bounce for an email address will lead to a permanent suppression from receiving future campaigns.
At Bluecore the average hard bounce rate is 0.05% across all email programs. If you have access to bounce log data, hard bounces are labeled as event_type=bounce and subtype=bounce.
Soft Bounce: These occur when the receiving server returns a reason for refusal that indicates a non-permanent rejection for that address. Common reasons for soft bounces include if your sending IP or domain has been denied due to poor reputation, the email address has a full mailbox, or that the receiving server was unreachable. If an email address has totaled 10 campaigns with a soft bounce, then it will be permanently suppressed from receiving future campaigns.
At Bluecore the average soft bounce rate is 0.37% across all email programs. If you have access to bounce log data, soft bounces are labeled as event_type=bounce and subtype=blocked.
A deferred event, or deferral, is when the receiving server has temporarily limited access to their system. Most common reasons for deferrals are a poor reputation, a volume-spike, or a capacity issue for the receiving server. This does not mean that it can’t be delivered, but more that at the time of the attempt, there was a “busy signal” signifying that it should be tried again. This means that the message stays in the sending mail server’s queue and retries until it gets a successful delivery, or until it times out at a max time limit of 72 hours.
Typically, deferrals are automatically retried after 2 minutes, then 5, then 10, then 20 and so on, up until those 72 hours are up. Each rejection of those attempts for that same campaign will be logged as a deferral, so one user can log multiple deferrals for a single message being attempted. If unsuccessful at the end of the 72 hours, a single soft bounce will be recorded. If it is successful, a delivered event will be recorded.
Total deferral counts will show in the Deliverability tab of the Email Analytics page.