Since 1998 we’ve sent email from our application using our own, very reliable, SMTP servers. And while it has worked great, it is nowhere near as robust as SendGrid, a cloud-based email delivery and management service whose goal is to increase delivery and improve customer communications.
SendGrid has revolutionized the delivery of email from our applications because it allows us to know what happens to each and every email that leaves us. Was the message undeliverable because the email address was invalid? Did it bounce for some reason? Did the consumer mark it as Spam? SendGrid will tell you this and much more about every message sent from your application.
SendGrid lets you know the status of your email as well as provides usable metrics that will help you improve your deliverability. More importantly, you can provide this information back to your users so they can improve the number of emails that are received by the recipient (instead of winding up in a Junk Mail folder) as well as know exactly what happened with an email when a customer calls asking for the status of their order.
You accomplish this by using SendGrid’s application programming interface (API). We found the API robust and easy to implement, and we were able to create a working prototype in just a few hours. Understanding what happens to a message when it leaves your application is important because many end users don’t understand the intricacies of email delivery and generally, don’t care. What they do care about is if the email reached the recipient and if it didn’t, why not – in plain, simple to understand terms. This is why we’re using the SendGrid API.
The actual delivery, or sending of messages, can be accomplished in a couple of ways. SendGrid allows you to send messages directly to their SMTP servers through their API. Calling their API in this manner enables your application to talk and send messages directly to an SMTP server, negating the need for you to even have an SMTP server on our side. This is probably the best and simplest configuration you can have. However, if you’re like us this may not be an option if you have a huge installed base of code which sends email through your own SMTP server. In this case, it is a simple matter of configuring your SMTP server to forward the email through SendGrid. Anyone familiar with SMTP should be able to make this change in minutes to your SMTP server.
Finally, here’s an important tip when implementing SendGrid. Remember to change the Sender Policy Framework (SPF) records associated with your domains. The SPF is a validation system designed to prevent email spam and because you are sending your messages through SendGrid, these records will need to be updated.
Strong customer communication is vital to the success of any business whether you’re sending hundreds, thousands or millions of emails on a regular basis. Knowing exactly what happens to those emails when they leave your application is crucial to maintaining positive customer relationships and growing your business. We’ve found that SendGrid helps you get there with minimal pain and effort.