Bounces (also called Non-Delivery Reports/NDRs or SMTP rejections) happen when you attempt to send email to a recipient and that attempt fails, typically because the recipient's inbound mail server has declined to accept the message, when the sending platform's mail server attempted to hand it off to them. Today I'll explain how they work and why they happen.
Common reasons messages are rejected (why they bounce) include:
User unknown. Meaning this address isn't valid. Somebody gave the sender a bad address, or the user abandoned the email account and the mailbox provider shut it down.
Mailbox full. Often and indicator that a mail account has been abandoned.
Sender technical issue or failure. DMARC failure, DNS failure, misconfiguration in email headers, or something else related to DNS, email authentication, or email platform settings.
Spam or bad reputation. The recipient mail server thinks this message is spam or thinks that you're a spammer. Technical compliance isn't enough. You have to have a good sending reputation, else you're not likely to get mail delivered successfully.
Mailbox provider misconfiguration. The receiving mail server is misconfigured. Error messages like "we do not relay" or "too many hops" tend to indicate that the domain you're sending mail to is misconfigured either in DNS or in the receiving mail server's configuration.
Rejections can happen immediately, during the SMTP handoff attempt, or the receiving mail server can accept the email message and then send back a rejection after the fact.
Synchronous bounces are when the rejection occurs during the SMTP transaction. These are easiest for sending platforms to handle and log. Delivery never happens.
Asynchronous bounces are where the rejection occurs later. This can be confusing, because you might think that the message was delivered successfully, but then later the sender receives an email back saying sorry, the message was not delivered. Asynchronous bounces are rare nowadays; they're not really considered a best practice and my guidance to anybody building out email infrastructure is that you should never build a system to intentionally send asynchronous rejections. (One important reason that they're not recommended is that asynchronous bounces can end up sending backscatter, annoying unrelated parties.)
Some email service provider (ESP) and email marketing automation platforms use VERP (Variable Envelope Return Path) to encode the sender (return-path) address uniquely per recipient, to aid with tracking and processing of asynchronous bounces. Asynchronous bounces are rare enough today that I'm not sure I'd bother building VERP into any new email sending platform I was building.
When a rejection happens, the mail server for the place you're trying to send mail to will respond back with a numeric error code and a short text explanation of why the mail was rejected. This bounce information is very useful for troubleshooting purposes. Postmark's SMTP Field Manual shares many different examples of these SMTP error messages.
Some ESP platforms attempt to summarize and categorize email rejections. This "bounce categorization" can often hide the numeric error code and text explanation, making it difficult to troubleshoot delivery issues in some situations. I recommend asking the ESP's support if it is possible to have access to the "raw bounce details," aka the actual rejection message the receiving mail server responded with when a given message's delivery attempt failed.
SMTP rejections are coded starting with a 3 digit numeric code. Permanent rejections (aka bounces) always start with a 5, so bounces are sometimes referred to as 5xx errors. Temporary rejections, when delivery attempts may be deferred, but not outright rejected, are often referred to as 4xx errors or 4xx delays.
If you're looking at SMTP rejection info logged by an email marketing automation or ESP platform, you might see temporary 4xx rejections logged as permanent bounces. Why? Because most email sending platforms will re-attempt delivery of a given message only for a certain length of time. After that period of time (which could be anything, but is commonly anywhere from 72 hours to 4-5 days), the sending platform gives up and stops attempting to send the message, and logs the 4xx deferral as the bounce message.
It's bad practice to continue to repeatedly attempt to send mail to addresses or servers rejecting your email messages. Most email marketing automation and ESP platforms will suppress a bouncing address from receiving any future email messages from that company or brand on that email sending platform. Some do this after a period of time passes with no successful deliveries to a given address, or after X successive email sends with no successful deliveries.
Bounces (also called Non-Delivery Reports/NDRs or SMTP rejections) happen when you attempt to send email to a recipient and that attempt fails, typically because the recipient's inbound mail server has declined to accept the message, when the sending platform's mail server attempted to hand it off to them. Today I'll explain how they work and why they happen.
Common reasons messages are rejected (why they bounce) include:
- User unknown. Meaning this address isn't valid. Somebody gave the sender a bad address, or the user abandoned the email account and the mailbox provider shut it down.
- Mailbox full. Often and indicator that a mail account has been abandoned.
- Sender technical issue or failure. DMARC failure, DNS failure, misconfiguration in email headers, or something else related to DNS, email authentication, or email platform settings.
- Spam or bad reputation. The recipient mail server thinks this message is spam or thinks that you're a spammer. Technical compliance isn't enough. You have to have a good sending reputation, else you're not likely to get mail delivered successfully.
- Mailbox provider misconfiguration. The receiving mail server is misconfigured. Error messages like "we do not relay" or "too many hops" tend to indicate that the domain you're sending mail to is misconfigured either in DNS or in the receiving mail server's configuration.
Rejections can happen immediately, during the SMTP handoff attempt, or the receiving mail server can accept the email message and then send back a rejection after the fact.- Synchronous bounces are when the rejection occurs during the SMTP transaction. These are easiest for sending platforms to handle and log. Delivery never happens.
- Asynchronous bounces are where the rejection occurs later. This can be confusing, because you might think that the message was delivered successfully, but then later the sender receives an email back saying sorry, the message was not delivered. Asynchronous bounces are rare nowadays; they're not really considered a best practice and my guidance to anybody building out email infrastructure is that you should never build a system to intentionally send asynchronous rejections. (One important reason that they're not recommended is that asynchronous bounces can end up sending backscatter, annoying unrelated parties.)
Some email service provider (ESP) and email marketing automation platforms use VERP (Variable Envelope Return Path) to encode the sender (return-path) address uniquely per recipient, to aid with tracking and processing of asynchronous bounces. Asynchronous bounces are rare enough today that I'm not sure I'd bother building VERP into any new email sending platform I was building.When a rejection happens, the mail server for the place you're trying to send mail to will respond back with a numeric error code and a short text explanation of why the mail was rejected. This bounce information is very useful for troubleshooting purposes. Postmark's SMTP Field Manual shares many different examples of these SMTP error messages.
Some ESP platforms attempt to summarize and categorize email rejections. This "bounce categorization" can often hide the numeric error code and text explanation, making it difficult to troubleshoot delivery issues in some situations. I recommend asking the ESP's support if it is possible to have access to the "raw bounce details," aka the actual rejection message the receiving mail server responded with when a given message's delivery attempt failed.
SMTP rejections are coded starting with a 3 digit numeric code. Permanent rejections (aka bounces) always start with a 5, so bounces are sometimes referred to as 5xx errors. Temporary rejections, when delivery attempts may be deferred, but not outright rejected, are often referred to as 4xx errors or 4xx delays.
If you're looking at SMTP rejection info logged by an email marketing automation or ESP platform, you might see temporary 4xx rejections logged as permanent bounces. Why? Because most email sending platforms will re-attempt delivery of a given message only for a certain length of time. After that period of time (which could be anything, but is commonly anywhere from 72 hours to 4-5 days), the sending platform gives up and stops attempting to send the message, and logs the 4xx deferral as the bounce message.
It's bad practice to continue to repeatedly attempt to send mail to addresses or servers rejecting your email messages. Most email marketing automation and ESP platforms will suppress a bouncing address from receiving any future email messages from that company or brand on that email sending platform. Some do this after a period of time passes with no successful deliveries to a given address, or after X successive email sends with no successful deliveries.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.