In part 3/3 of our Email API series, we’ll be discussing SMTP Relay and Email APIs. You can reference the full series here:
Let’s dive in!
Sending email comes down to one of two protocols you’ll want to develop around: the SMTP of email servers, or the HTTP of web servers. You may be familiar with the advantages of modern cloud APIs (if not, see our earlier post explaining the topic), but SMTP is the original protocol for sending email and still remains at the core of it all.
All email is ultimately sent by an email server according to the rules of the Simple Mail Transfer Protocol. It’s a matter of whether you want to control this process yourself by handling your own SMTP interactions, or whether you are comfortable handing over the SMTP transactions to an email provider, using their abstracted API instead. There are pros and cons to both approaches, so we’ll explore them below.
SMTP (the Simple Mail Transfer Protocol) has been around for nearly four decades. It was defined as the internet standard protocol for email communications back in 1982 and is still the de facto protocol when sending or receiving email from outside one’s own systems. SMTP specifies the rules, procedures, and components of an electronic mail message, and how to send one in a standard format that can be interpreted by any other email server in a completely platform-agnostic way. Thanks to its ubiquity, a developer can rely on even legacy devices being able to handle SMTP sending.
After an email has been sent to the final destination mail server, the Internet Message Access Protocol (IMAP) takes over to retrieve messages for individual inboxes, where users can access and manage their mail. In this article, we’ll stay focused on the SMTP protocol, but check out our CTO & Co-founder Christine Spang’s excellent deep dive into IMAP to learn more about why IMAP is an important part of receiving emails, but not always the easiest thing to implement (or understand).
For the time being, let’s return to senders. Below is an example of successfully sending an email to two mailboxes via SMTP. A software client (who has email data to send) opens a connection to an SMTP mail server, then sends a HELO code to let the mail server know it wants to send an email. The overall process involves many individual handshakes between the client and server, as you’ll see below by the number of “250 Ok” responses needed to move each step forward.
Note: “S” refers to Server, “C” refers to Client, and the three-digit numbers are the response codes.
=== Connected to smtp.example.com.
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: “Bob Example” <[email protected]>
C: To: Alice Example <[email protected]>
C: Cc: [email protected]
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
Further detail about this SMTP example can be found on Wikipedia.
Aside on Response Codes
When you send data or make a request with a message to a server somewhere, you will get a response code back that indicates whether your packet of information was successfully received for the next relay or not. Codes are three-digit numbers that give a broad indication of the status of the last message. For example, codes in the 200 range typically represent an “OK, continuing” response, whereas a response in the 400 or 500 ranges indicates a problem.
HTTP is a universal web protocol for all kinds of data, not just email. Any applications that make use of a client-server computing model, such as web apps, mobile apps, and even some IoT apps, use HTTP. When using an HTTP API to send your email data, you trust an intermediary service to take care of the SMTP details, email deliverability, and email server workflows. Ultimately all your email messages will flow via SMTP at some point in their journey, but it is now up to you whether you want to micromanage the SMTP message handling process or leave it up to a third party.
Developers integrating email functionality into a product will generally turn to an HTTP API. Besides offering a familiar convention (e.g. REST), HTTP APIs offered by modern email providers offer a number of benefits that pure SMTP does not. Importantly, an API may offer other functionality outside of sending emails that complement related procedural tasks.
Cloud-based email API providers are usually able to offer better delivery speeds and allow for your transactions to happen faster because there is less back and forth required than pure SMTP. This streamlining also minimizes the number of overall exchanges required when sending an email, thereby improving I/O. The Nylas Email API was created in part because these advantages accrue at scale and can be most easily managed via a high-level API abstraction layer.
When you’re interacting with a software application over the internet, you’re using the standard protocol of web communications, HTTP (Hypertext Transfer Protocol). Whenever you visit a webpage, you’re making use of HTTP communications to request and receive data. One advantage of using HTTP as your protocol for sending email data is that it is more likely to be accepted compared to SMTP messages, which are commonly blocked by firewalls.
Below is an example of sending a message using an HTTP API:
POST /send HTTP/1.1
Host: api.nylas.com
Content-Type: application/json
Authorization: Basic WVVUW****
cache-control: no-cache
{
“reply_to_message_id”: “7a893****”
}
One major advantage of using HTTP API over SMTP is that you can choose to use API keys rather than auth-based Note that it’s also possible to use SMTP via an API. For example, if you are using the services of an email API platform, you can use their SMTP API to instruct them to follow exact SMTP specifications for sending & receiving your emails, without operating any of the email servers yourself. In essence, you are using an HTTP connection and an API abstraction to perform functions related to SMTP message handling remotely.
When deciding which protocol to use, weigh these elements of your scenario:
As a rule of thumb, SMTP is a suitable choice for simpler use cases, while an HTTP API is a better choice for complex use cases or resource-constrained scenarios. With the variety and quality of web API providers available in a mature email technology industry, most developers today will choose to develop with an HTTP API, falling back on SMTP only when they need fine-grained control or additional redundancy assurances.
Key Takeaways Building a scheduling application that displays the organizer’s available timeslots seems like a…
Explore the transformative impact of AI, the evolution of global connectivity, and the reshaping of workplace culture in the digital era in Nylas’ 2024 predictions.
Use the Nylas Email API and Ruby to group email threads into a single view, and easily access complete conversations within your app.
Email API
Calendar API
Scheduler
Contacts API
ExtractAI
Google email & calendar integration
Outlook email & calendar integration
IMAP integration
Calendar management
Embedded contextual email
Scheduling automation
Automated outreach
Intelligent data extraction
Ecommerce
Telehealth
Real estate
Financial technology
Educational technology
Expense management
Customer relationship management
Applicant tracking system
Communications platform
Marketplaces
Document management
Docs
SDKs
Tutorials
API status
Changelog
Support
Blog
Events
Guides
Inspiration gallery
Partners
Build vs. buy
Customer stories
Security & Compliance
Why Nylas
Newsroom