SendGrid provides two ways to send email: through our SMTP relay or through our Web API.
SendGrid provides our users with client libraries in many languages, this is the preferred way to integrate with SendGrid.
If you choose to use SendGrid without a client library, the Web API is recommended in most cases as it is faster, provides some benefit with encoding, and tends to be easier to use. SMTP provides many features by default, but is harder to setup.
The Web API has some advantages over SMTP:
- If your ISP blocks all outbound mail ports and your only option is HTTP.
- If there is high latency between your site and ours, the Web API might be quicker since it does not require as many messages between the client and server.
- If you do not control the application environment and cannot install and configure an SMTP library.
- If you build a library to send email, developing against a web API provides quicker development.
If you are integrating SendGrid with an existing application, setting up the application to use our SMTP relay is easiest, as it only requires modifying SMTP configuration.
- Change your SMTP username and password to your SendGrid credentials
- Set the server host name to smtp.sendgrid.net
- Use ports 25 or 587 for plain/TLS connections and port 465 for SSL connections
SendGrid extends SMTP with the X-SMTPAPI header, giving you more control over how SendGrid sends your email. See the SMTP API documentation for more information.
Though SendGrid does not store messages or provide mailboxes, the Inbound Parse Webhook parses the email bodies and attachments from incoming emails and posts them to your web application.
Examples include posting blog articles via email or processing email replies.
A local mail server, such as Postfix, is the most robust way to send email through SendGrid when configured to queue all email from your application and then relay the messages through SendGrid as a smart host. This has the least latency from your application’s perspective with the added benefit of handing your email off to a fault tolerant server. If internet connectivity between your servers and ours drops, a local mail server gracefully handles queuing and resending the email, as opposed to building that intelligence into your sending application.
Local mail servers also have advantages at high volume as they can use some of the more complex parts of the SMTP protocol, such as connection reuse and pipelining. With these techniques a mail server sends significantly more traffic in a given time than if you have individual scripts connecting for each message.