One of the hardest, dirtiest jobs we ESPs have to do is manage bouncebacks. We send a few bajillion emails out, and a kajillion bounces inevitably come back. Now, we have to scan every single one of those complicated email headers to figure out what type of bounce it was, then decide what to do with it. If we get a “hard” bounce, that usually means the account we tried to deliver email to doesn’t exist (and so we should clean the member from that list). If we get a “soft” bounce, that usually means the account exists, but we should try again later. Not to mention FBL parsing, and simply filtering out the spam that we get before we can even get to the bounces. It’s like sorting through a dumpster to find recyclables or something. Not very glamorous.

It would be all fine and dandy if people would follow delivery status notification best practices and guidelines. But they don’t. Sometimes this is a reaction to spam, and sometimes it’s just ignorance.

For example, some server admins insert snarky messages in their email headers, like “We don’t want your message. If you send email to us again, we’ll report you.” Well, that’s their prerogative and all, and we’re happy to never send to them again, but if they simply hard bounced the email, we’d be able to clean it from the list faster.

Then there are some ISPs who are downright deceptive with their bounceback codes…

Read More


We have a customer with a relatively large list of about 311,000 opt-in subscribers. They’ve been collecting opt-ins from their site for years now.

About 240,000 of them are “old” (inactive) subscribers. About 70,000 are relatively “new” (active) subscribers.

They recently segmented their list and sent the same newsletter to each group (separately) over the same IP address, about 6 hrs apart from each other. Around 2pm, they sent the newsletter to the large, inactive list. Around 8pm, they sent the same newsletter to the active list.

The results are eye-opening…

Read More