# SMTP vs REST email API Source: https://developer.nylas.com/docs/cookbook/email/smtp-vs-rest-email-api/ SMTP is how mail servers have exchanged messages since 1982. It's everywhere, and it's a blunt tool for an app that sends on behalf of real users: you manage credentials per mailbox, open a socket per send, and handle deliverability yourself. A REST email API sends over HTTP instead. You make a request, the message goes out through the user's own mailbox, and one integration covers every provider. Here's how the two compare for sending, and when each one fits. > **Info:** > **New to Nylas?** Start with the [quickstart guide](/docs/v3/getting-started/) to set up your app and connect a test account before continuing here. ## How do SMTP and a REST email API differ? SMTP, standardized in 1982, is a transport protocol: your code opens a socket to a mail server on port 587 or 465, authenticates, and streams the message. A REST email API wraps sending behind an HTTPS request that returns JSON. SMTP needs a username and password per mailbox; a REST API uses OAuth that the provider already authorized, so there are no SMTP credentials to store. The table below maps the practical differences for sending mail from an app. | Dimension | SMTP | REST email API | | --- | --- | --- | | Transport | Socket on port 587 or 465 | HTTPS request and response | | Auth | Username and password per mailbox | OAuth handled by the API | | Providers | One server config per account | One endpoint across Gmail, Outlook, Yahoo, iCloud, IMAP | | Result | A delivery attempt, no message object | A `message` object with an ID | | Threading | You set headers by hand | Reply keeps the conversation intact | | Tracking | Not built in | Opens, link clicks, and replies | Both put a message in the recipient's inbox. The REST path returns a structured result you can store and track, where SMTP gives you a transport-level acknowledgment. ## When should you use SMTP? SMTP makes sense when you send from a single mailbox you control, already run mail infrastructure, or integrate a legacy system that speaks nothing but SMTP. For a scheduled job that sends to one internal address, an SMTP relay on port 587 is the shortest path and adds no dependency. The cost shows up at scale. You store credentials for every mailbox, manage a connection per send, and configure SPF and DKIM on each sending domain yourself. Across 200 users, that becomes a credential vault and a deliverability project you own end to end. ## When should you use a REST email API? A REST email API fits when you send as many different users, want a message ID back, or would rather not store SMTP passwords. One endpoint sends through 5 provider families, so a message from a Gmail user and a message from an Outlook user use the same request. The API refreshes the OAuth token, and the sent message lands in the user's own Sent folder. This is the common choice for apps that send on a user's behalf: support replies, scheduling confirmations, and AI agents. To send through a connected mailbox step by step, read [send email without SMTP](/docs/cookbook/use-cases/build/send-email-without-smtp/). For bulk one-off mail from your own domain instead of a user's mailbox, see [transactional send](/docs/cookbook/email/transactional-send/). ## How does a REST email API send mail? Sending over REST is a single POST request. The `/v3/grants/{grant_id}/messages/send` endpoint sends through the user's mailbox and returns a `message` object with an ID, no SMTP handshake involved. The call below sends a message with open, link, and reply tracking enabled in 1 request. ```bash curl --request POST \ --url 'https://api.us.nylas.com/v3/grants//messages/send' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "subject": "Reaching Out with Nylas", "body": "Reaching out using the Nylas Email API", "to": [{ "name": "Leyah Miller", "email": "leyah@example.com" }], "tracking_options": { "opens": true, "links": true, "thread_replies": true, "label": "hey just testing" } }' ``` ```json { "request_id": "1", "data": { "bcc": null, "body": "Learn how to Send Email with Nylas APIs", "cc": null, "attachments": [], "from": [ { "email": "nyla@nylas.com" } ], "reply_to": null, "subject": "Hey Reaching Out with Nylas", "to": [ { "name": "DevRel", "email": "devrel@nylas.com" } ], "use_draft": false, "tracking_options": { "label": "hey just testing", "links": true, "opens": true, "thread_replies": true }, "date": 1707839231, "grant_id": "1", "id": "1", "thread_id": "2" } } ``` For Node.js and Python versions, see [send email without SMTP](/docs/cookbook/use-cases/build/send-email-without-smtp/). The same endpoint handles attachments and reply-to addresses through extra request fields. ## How does deliverability compare? Deliverability depends on the sending domain's reputation and its SPF, DKIM, and DMARC records. With raw SMTP you configure those records for every domain you send from and warm up the sending reputation yourself. Sending through a user's connected mailbox over REST inherits that mailbox's existing reputation and authentication across all 5 providers, since the message goes out as the user. That difference matters most for mail that should look like it came from a person. A reply sent through a customer's Gmail account passes the same SPF and DKIM checks as any other message they send, with 0 DNS changes on your side. For high-volume mail from your own domain, you still own domain authentication, which is where a dedicated sending service or [transactional send](/docs/cookbook/email/transactional-send/) fits. ## Things to know about sending over REST A REST send behaves like a real message in the user's mailbox, which has a few consequences worth planning for. The sent message appears in the provider's Sent folder and returns a `thread_id`, so replies stay grouped in the conversation. To send into an existing thread, include the original message reference rather than relying on subject matching. Rate limits apply per mailbox, the same as reading mail, and the API retries automatically on `429` responses. Attachments up to 3 MB send as JSON in the request body, and files up to 25 MB use multipart form data, as the [send attachments guide](/docs/cookbook/email/attachments/send-attachments/) explains. For the full sending workflow, see [send email without SMTP](/docs/cookbook/use-cases/build/send-email-without-smtp/). ## How do I send a reply that stays in the thread? Set `reply_to_message_id` in the send request to the ID of the message you're replying to. The API adds the `In-Reply-To` and `References` headers, so the reply lands in the same conversation across all 5 provider families instead of starting a new thread. Raw SMTP makes you build those headers by hand. The request below sends a reply that threads correctly by referencing the original message ID. ```bash curl --request POST \ --url 'https://api.us.nylas.com/v3/grants//messages/send' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "subject": "Re: Project kickoff", "body": "Thanks, that time works for me.", "to": [{ "email": "leyah@example.com" }], "reply_to_message_id": "" }' ``` Because the reply keeps the conversation intact, the recipient sees it grouped under the original message. For reading those grouped conversations back, see [email threading in Gmail vs Outlook](/docs/cookbook/email/threads/gmail-vs-outlook-threading/). ## How do I track opens, clicks, and replies? Add a `tracking_options` object to the send request to measure engagement. Set `opens`, `links`, and `thread_replies` to `true` to track 3 events: message opens, link clicks, and replies. Attach a `label` to group related sends. The API adds open tracking, rewrites links for click tracking, and reports those events through webhooks. SMTP has none of this built in. The send request earlier in this guide already enables all three options. For the full setup, including the webhook side, see [track email opens](/docs/cookbook/use-cases/build/track-email-opens/). ## FAQ ### Do I need SMTP credentials to send? No. Sending through a connected mailbox over REST uses the OAuth grant the user already authorized. There are no SMTP usernames, passwords, or server hostnames to store, and the token refreshes automatically before it expires. ### Can I send from the user's own email address? Yes. The message goes out through the user's mailbox, so it comes from their address and lands in their Sent folder. That's the main reason to send over REST instead of an SMTP relay: the mail looks like the user sent it, with their reputation behind it. ### Will messages land in the Sent folder? Yes. A REST send writes the message to the provider's Sent folder, the same as a message the user sends from Gmail or Outlook. The response includes a `thread_id`, so replies stay grouped in the conversation. ## What's next - [Send email without SMTP](/docs/cookbook/use-cases/build/send-email-without-smtp/) for the full send workflow in Node.js and Python. - [IMAP vs REST email API](/docs/cookbook/email/imap-vs-rest-email-api/) for the reading side of the same comparison. - [Transactional send](/docs/cookbook/email/transactional-send/) for bulk mail from your own domain. - [Messages API reference](/docs/reference/api/messages/) for every send field and response value.