SendGrid’s Web API and SMTP Relay are the two primary methods of integrating with and sending email through SendGrid. You can think of their differences like methods of delivering a package: you could send a package in the mail, or you could drive it to the destination yourself.
While the methods of delivery are different, the end result is the same: the package is received. Below, we’ll walk you through the ins and outs of our API vs. SMTP sending methods.
Web API
SendGrid’s Web API sends mail via HTTP. Your server sends a message to SendGrid, and receives either a 250 message, indicating that the message was accepted by the receiving server, or a 400 or 500 message, indicating that something is wrong, prohibiting us from processing the request.
When everything is packaged correctly, SendGrid can process the request and then send it to the intended recipient’s ISP that responds with either a 250 message or a 500 message of their own, informing SendGrid whether or not the message was received. This process is more similar to putting your package in the mailbox and letting the post office review its information and deliver it for you.
Reminder: A 250 message from your recipient’s ISP does not guarantee that the email will reach their inbox—it means that the ISP has determined the address is valid and has accepted the message. Once accepted, the ISP then determines if it should be placed in the inbox, junk folder, spam folder, or defer the message all together.
You can learn more about the server response messages in our email error messages glossary entry.
SMTP relay
Sending email via SMTP relay, or Simple Mail Transfer Protocol, requires more back and forth conversation to deliver a message to the intended recipient than the Web API. In our example, this method is more like delivering a package yourself because it requires additional steps to complete the delivery process. When a sender uses SMTP to connect to SendGrid, separate pieces of information must be passed back and forth between SendGrid and its customers before the message can be processed and sent to the recipient ISP.
With SMTP, SendGrid has to check the message, DNS, and authentication. Each of those will return a 250 message or a 400 or 500 message indicating that something is right or wrong separately. A similar conversation has to take place between SendGrid and the receiving ISP before the ISP can decide whether it’s going to deliver, block, or send the email to the spam folder.
Read an in-depth explanation of SMTP Relay in our blog post Email Message Flow 101.
SMTP vs. API
Because of the extra “chatter” back and forth during an SMTP connection, we suggest that SendGrid customers use the Web API when possible for several reasons:
- SMTP relay creates multiple points of potential failure, meaning that there are more places in the conversation between the sender and SendGrid that could cause one of those “not okay” messages.
- The Web API is faster. The extra back and forth necessary in SMTP relay can cause some (minimal) latency for customers who are outside of the United States, and thus further from our inbound data centers.
- The Web API also allows you to add an extra layer of security to your program by utilizing API keys. API keys allow you to generate an authentication credential separate from your username password, which significantly lowers the chance of someone using your account to send spam or phish.
That being said, SMTP is an email standard and is used universally. The Web API was created by SendGrid’s founders to connect with our system more efficiently and might not be a viable option for all users. SMTP relay can also be used to connect with an existing application like a CRM system or a mail client like Outlook. The Web API is often utilized by developers creating their own products.
To read more about SendGrid’s email tools and features, head over to our Documentation.
