SendGrid provides two ways to send email: through our SMTP relay or through our web API.
SMTP is the fastest way to get started since it requires only minimal changes:
- 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.
In some cases the web API has 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.
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.