govDelivery sends over three billion emails each quarter. Most of the time, those emails end up in the hands of subscribers, but on rare occasions, an email can’t be delivered. This can happen for a variety of reasons: a subscriber’s mailbox could be full; the email address being used is old, or the reason might be unknown entirely. The following is an overview of what happens when an email can’t be delivered, and how Granicus handles the notifications and responses we receive from mail servers when it happens.
Overview
Delivery Failure Notifications (DFNs), Delivery Service Notifications (DSNs), Non-Delivery Notifications (NDNs), Bounce Backs, and Bounces are all synonyms for notifications govDelivery receives from mail servers regarding messages that are sent to recipients. govDelivery systems log these failure messages in records specific to each recipient, classifies them, and makes decisions about how to act (or not act) upon them.
In general, a receiving server will respond with "successful delivery", "temporary failure" or "permanent failure" to indicate whether the message was received, can be retried, or outright failed. If the message was delivered, the recipient's record will be marked successful. If the message delivery notification indicated a temporary failure, or a Soft Bounce, it will be retried. If the message delivery notification indicated a permanent failure, the reason for the failure will be recorded as a Hard Bounce and processed later by the Bounce Processor.
The Bounce Processor classifies the reason for the delivery failure as something that can be ignored (SPAM, DNS errors, temporarily unavailable servers) or as indicative of a bad email address (user not found, could not deliver, etc.). It is possible for a message to be accepted by the receiving server and later be rejected, which is known as an Asynchronous Bounce.
Terminology
- Bounce Email
- Email that has been returned from a remote MTA as having failed delivery.
- Asynchronous Bounce
- An email that was originally delivered as a success to a remote email server, but later returned. This message must then be classified as "soft" or "hard".
- Synchronous Bounce
- An email that was rejected immediately by the receiving server. This could be a "soft" or "hard" bounce.
- Soft Bounce
- A rejected email that, if attempted at a later time, may result in a successful delivery. For example, "mailbox is full" or "max attempts".
- Hard Bounce
- A rejected email that, if attempted at a later time, would not result in a successful delivery and will not be attempted at a later time. For example, "unknown user" or "mailbox does not exist".
Feedback Loops
Feedback loops are communication channels that we actively set up by interacting with Internet Service Providers or ISPs. We use these feedback loops for user feedback reporting, in order to process and/or remove subscribers that actively provide feedback on emails sent through govDelivery with their ISP. We have active feedback loops from most major email providers. Some email providers like, Gmail, do not honor feedback loops.
Synchronous Bounce Processing
Synchronous bounce processing relies upon accurate records of synchronous errors encountered at the time the email is delivered and stored on a per-recipient basis. All error messages are matched against regular expressions to determine whether or not the "hard bounce" is one that requires the email address to be deleted or the delivery records to be marked in some way. Essentially, the govDelivery system receives these ISP responses, and asks the question: “Is this something I delete an email address for or is this something I don't delete an email address for?”
Asynchronous Bounce Processing
Asynchronous bounce processing is similar to synchronous bounce processing in that it is an application that asks the same “delete / don’t delete the email address” question above. The major difference is that asynchronous bounces are generally delayed in their return to us due to the nature of the bounce i.e. a mail server initially accepted an email as a delivery, but then later returned a bounce message. This initial acceptance and then later rejection on the mail server side can be caused by a variety of issues. Hence, there is also an inherent delay in the processing of an asynchronous bounce.
Frequently Asked Questions
Q. What is the process that govDelivery goes through to remove bad email addresses from client accounts?
A. The first step to addressing this question is defining what a bad email address is. There are two types of email addresses that we classify as “bad.”
- Undeliverable
- A mail server alerts us that an email address has been marked permanently undeliverable. We get a server notification of this fact, and we remove that email address from any/all govDelivery accounts.
- User Feedback
- If a subscriber provides feedback that they no longer want to receive emails from an organization (or don't believe they should be getting those emails in the first place) from within their email client, and we have a registered feedback loop with that ISP, we get a notification from the ISP regarding this fact. We remove that subscriber, but only from the account that sent the bulletin they provided user feedback on.
Q. How does govDelivery handle soft bounces?
A. Soft bounce means that the server receiving mail for a given address replied that it can't accept mail at this time, even though the address is valid. Common reasons for this include a full mailbox, issues with the mail server accepting mail, or a message sent which violates a policy of the receiving server. As soft bounces typically indicate that a recipient could receive a future message if the temporary problem is addressed and resolved, soft bounces are not removed from subscriber lists at this time.
Q. Are there some types of soft bounces where we keep attempting to send indefinitely?
A. Yes. Some soft bounce errors that are returned by a server are retry-able, in which the server may recommend that we send again at will, or wait to send and try the address again later. Soft bounce messages that contain these parameters will be retried indefinitely until a hard bounce occurs, and do not contribute to the algorithm quota of soft bounces.
Q. In the case of a hard bounce, do we delete an email address instantly if it's identified as undeliverable?
A. Yes. Once an email address is demarcated as unknown / invalid destination / undeliverable, a deletion request is processed to remove that record across all accounts.
Q. When someone uploads a list & there are "bad' email addresses, do we remove them then or on the first send?
A. The system process of deleting a bad email address only begins once the first send to subscribers occurs. Currently we have no systematic vetting that occurs immediately upon uploading a list of subscribers to a client’s account.
Q. What role if any should a client play in keeping their lists "clean"?
A. Implementing best practices on both email sending and subscriber collection are the first steps to having clean lists. Clients may be as active as they wish in keeping their lists of subscribers clean. Actively looking at their subscribers and govDelivery reports (especially on first sends), recognizing errors, and choosing to clean out bad email addressees, or email addresses that return errors, will only improve deliverability for their sends.
That being said, Granicus implements a thorough set of parameters to do this for our clients, in order to keep our bar as high as possible when it comes to deliverability across our entire organization.
