If you’ve spent any amount of time sending email for either personal or professional reasons, you’ve probably encountered a very common and very frustrating problem: understanding email server response codes.

When you send an email that fails to get accepted, the response codes sent back by ISPs like Yahoo, Gmail, and even home-brewed Mail Transfer Agents (MTAs) can be unhelpful, bizarre, and sometimes downright confusing. Here are a few examples of what I mean:

550 5.7.1 RESOLVER.RST.NotAuthorized; not authorized

Huh? What’s not authorized? Who? Where?

554 Reject by behaviour spam

Who is this “behavior spam” and why is he rejecting my mail? Curse you, behaviour spam!

500 SMTP Error: Data not accepted

What.

Deliverability Center

If you’re tired of relying on bone-casting and divination to decipher messages like this, we have good news! We’ve recently launched an ongoing project called “Deliverability Center” that aims to provide insight into these cryptic reasons, with only the minimum expenditure of brick dust and newt eyeballs!

The Deliverability Center is a living repository of popular and hot-button MTA response codes that we see from our users, and then we dive in to provide what we’ve found is the best resolution for each one!

Deliverability Center has a zealous team behind it, comprised of some of the most seasoned SendGrid Support techs we have to offer. Their know-how and experience means that you can feel confident that the suggestions you find will help you decipher the response codes you’re getting. Here’s an example of what you might find by searching for:

421 Too many concurrent SMTP connections; please try again later.

Our suggestion:

At any one time, SendGrid’s servers are establishing connections to mail servers across the world. Some mail servers have a connection limitation to “throttle” the amount of incoming mail in order to keep their servers from crashing. If too many connections attempt to be established, the recipient server can initiate a control that terminates existing and new connections. SendGrid is not able to limit the number of connections made to a recipient mail server. Our recommendation here would be to either contact the IT admin or postmaster of the respective server to see if the maximum connection limitation can be increased, or to slow down the rate of sending to this domain from the sender from your sending application.

Pretty sweet, huh? Keep in mind, the landscape of email is one that is ever-shifting and ever-evolving. As such, we will be constantly adding new response codes and suggestions. As of this writing it contains only the most common MTA response codes we see from our customers, but expect it to grow into something much more exhaustive as our awesome community utilizes what we think will be a powerful (and frankly, cool) tool.

We have big plans to leverage this tool in the future to help our customers stay current on delivery issues their accounts may be encountering, so stay tuned for new developments! 

Have an MTA response code that doesn’t make sense? Let us take a crack at it! Use the submission form here to send us your reason code, and our team will review it, research it, and publish a suggestion!



Ian Gifford is SendGrid's Support Systems Analyst. He curates the Support Knowledge Base and manages the systems that keep our Support organization firing on all cylinders. Drop him a line on Twitter.