Better Bounce Management for Postmark

Phew, that was a busy several weeks. We have been hard at work improving the way we handle bounces on Postmark. The newest additions to our service are support for tagging emails and disabling delivery to addresses that do not want your email.

Tagging #

How many times have you wanted to tag your outgoing email and check if it gets delivered, or just get statistics about that category of emails? Would you reconsider your email delivery strategy if all your spam complaints get triggered for the “Mr. X wants to be your friend” invitation email that you send from your social networking site? Now you can see this right in the interface and optimize your email delivery. To start tagging emails, see the new property in the Postmark Developer Docs.

Automatically blocking delivery for certain bounces #

We realized that most of the time people do not want to send email to a nonexistent mailbox just to have the target SMTP server bounce the message back. Imagine a bunch of emails hitting the same addresses every day and achieving nothing. It’s both a waste of bandwidth and Postmark credits. Not to mention that ISP’s don’t like that at all and at the extreme you can end up degrading reputation and delivery.

The above situation is not even the worst thing that can happen. Say a user doesn’t want to receive email from you, and clicks the “Report spam” button in his email client. If you fail to handle that, you will keep delivering email, effectively annoying him or her even more. That can have mild consequences like bad email karma resulting in maybe you getting more spam than usual, or, if you are particularly obnoxious at sending those emails, it could result in getting blocked by the ISP and Postmark.

To help with that we decided to start rejecting email that you try to deliver to an address which has previously bounced back. We will do this only for hard bounces since those are guaranteed to represent mailboxes or servers that do not exist, and for spam complaints – those always mean that the user does not want to hear from you. The algorithm is simple — whenever we receive a hard bounce or a spam complaint sent through a server you configured, we will deactivate the recipient address and will not let you deliver email to it. The cool part is that you will not waste credits on those messages either.

Important: Right now we are still allowing emails to be delivered. On Monday March 29th we will flip the switch and stop sending to bounced and spam emails.

But I insist on sending to that address! #

Do not worry! The delivery issues interface will allow you to reactivate an email address that has generated a hard bounce, so that you can send email to it again. Spam complaints are different. We feel that nobody should have to put up with continuously getting email he or she feels is spam, so we will not allow you to reactivate an address that has been deactivated because of a spam complaint.

I have several applications. Will deactivating an address for one of them affect the others? #

Inactive addresses are associated with a Postmark server. Your applications should follow the recommended practice of using a different server for every application, so that a spam complaint for your WWE fans social network does not hurt your other apps’ delivery.

How will you reject my email? Will I get an error? #

Yes, the plan is to eventually get an error back at you. Since that email will not reach anybody, we think it is best that you get an early notification and do something about that. This might cause some problems with your existing code though. Imagine the following pseudocode:

actionA();
    sendEmail();
    actionB();

If sendEmail() throws an exception because you sent to an inactive email address, actionB() will never be executed. While I think this is not a typical situation (You are doing proper error checking when calling an external service over the network, right? Right?!), we still have to do the right thing and provide a grace period until people check their code. For the time being you will get a warning when you try to send to an inactive address, if you check the Message property of the JSON response. In a week or so, we’ll flip the switch that will start generating real errors.

As a conclusion, I’d like to say that I’m pretty excited about the new features. I hope they are useful for you and your apps. As usual, feedback is welcome.