> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Send outbound email over SMTP

> Point any SMTP client at the Orbit relay, authenticate with an API key, and send email through the same pipeline as the API — with the connection details, client snippets, a health check, and the feature limits.

# Send outbound email over SMTP

Orbit's SMTP relay accepts standard RFC 5322 submissions from any SMTP client, authenticates the connection with one of your API keys, and dispatches the message through the same email pipeline as `POST /api/v1/messages/email` — so suppression, consent checks, billing, verified-sender enforcement, and the delivery log all apply with no extra integration work.

**You will:**

1. [Choose between SMTP and the API](#1-smtp-vs-the-api-vs-inbound-parse)
2. [Collect your connection details and API key](#2-connection-details-and-credentials)
3. [Connect a standard client](#3-connect-a-standard-client)
4. [Keep deliverability controls in place](#4-deliverability-controls-still-apply)
5. [Health-check a test message](#5-health-check-a-test-message)
6. [Read the limits](#6-limits)

<Note>
  The relay is in early access and is enabled per account. Open **Developer → SMTP** in the dashboard to confirm it is live for you before pointing a client at it.
</Note>

## Prerequisites

* A live API key (`dv_live_sk_...`) from **Settings → API Keys** — the relay authenticates with an API key as the password.
* A verified sending domain for the address in your `From` header. The relay enforces the same verified-sender rules as the API, so complete [domain setup](/channels/email#domain-setup) first.
* Any SMTP client or library that speaks STARTTLS or implicit TLS.

## 1. SMTP vs the API vs inbound parse

Three surfaces touch email; pick the one that matches your traffic direction and client:

| Surface                                          | Direction | Use when                                                                                                                                 |
| ------------------------------------------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **SMTP relay** (this guide)                      | Outbound  | Your stack already speaks SMTP (legacy apps, off-the-shelf CRMs, mail-enabled devices) and you want delivery without an HTTP integration |
| **`POST /api/v1/messages/email`**                | Outbound  | New integrations — templates, idempotency keys, attachments via URL, and per-message metadata are first-class on the HTTP API            |
| **[Inbound parse](/guides/inbound-email-parse)** | Inbound   | Mail addressed *to* your domain, parsed to JSON and forwarded to your webhook                                                            |

The SMTP relay and the HTTP API are two doors into the same pipeline, not separate systems: every relayed message lands in the same delivery log, suppression list, and engagement metrics. The [`email_smtp` provider type](/guides/subaccount-connection-modes) that appears in subaccount connection modes is a registry row about *whose* SMTP lane carries the traffic — it is unrelated to connecting your own client here.

## 2. Connection details and credentials

Open **Developer → SMTP** in the dashboard for the authoritative connection card. The current values:

| Setting            | Value                                          |
| ------------------ | ---------------------------------------------- |
| Host               | `smtp.orbit.devotel.io`                        |
| Port (recommended) | `587` — STARTTLS submission                    |
| Alternate port     | `2525` — STARTTLS, for networks that block 587 |
| Implicit TLS port  | `465` — SMTPS                                  |
| Username           | `apikey`                                       |
| Password           | Any active API key on your account             |

TLS is required on every port. The username is a fixed sentinel — never substitute your email address or key id; the API key goes in the password field. Every send is scoped and billed to the API key that authenticated it, so a key with send permissions is the only credential you carry.

If authentication is rejected (`535`), verify the key is active under **Settings → API Keys** and that you are sending the full `dv_live_sk_...` value, not a label or prefix.

## 3. Connect a standard client

### Python `smtplib`

```python theme={null}
import os
import smtplib
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "you@your-domain.com"
msg["To"] = "customer@example.com"
msg["Subject"] = "Hello from Orbit"
msg.set_content("Sent through the Orbit SMTP relay.")

with smtplib.SMTP("smtp.orbit.devotel.io", 587) as server:
    server.starttls()
    server.login("apikey", os.environ["ORBIT_API_KEY"])
    server.send_message(msg)
```

### Node.js (nodemailer)

```js theme={null}
import nodemailer from "nodemailer";

const transport = nodemailer.createTransport({
  host: "smtp.orbit.devotel.io",
  port: 587,
  auth: { user: "apikey", pass: process.env.ORBIT_API_KEY },
});

await transport.sendMail({
  from: "you@your-domain.com",
  to: "customer@example.com",
  subject: "Hello from Orbit",
  text: "Sent through the Orbit SMTP relay.",
});
```

### SMTP handshake probe (swaks)

```bash theme={null}
swaks --server smtp.orbit.devotel.io:587 --tls \
  --auth-user apikey --auth-password $ORBIT_API_KEY \
  --from you@your-domain.com --to test@example.com \
  --header "Subject: Hello from Orbit"
```

## 4. Deliverability controls still apply

Relaying over SMTP does not bypass the lifecycle controls from the [Email channel lifecycle guide](/guides/email-lifecycle-guide):

* **Sender domain** — the address in your `From` header must be a verified sender. An unverified or mismatched address is rejected at dispatch with a per-recipient error, exactly as it would be over the API.
* **DKIM/SPF/DMARC** — sign and alignment run on your domain's DNS records, which the relay does not change. A drifted record degrades relayed mail the same way it degrades API-sent mail; re-verify under **Channels → Email → Domains**.
* **Suppression** — bounced, complained, and unsubscribed addresses are suppressed at the pipeline level. A submission to a suppressed address counts as a rejected recipient; the other recipients in the same message still deliver.

Because both paths share one pipeline, a suppression entry created by an API send also applies to SMTP traffic and vice versa.

## 5. Health-check a test message

1. Send the [swaks probe](#smtp-handshake-probe-swaks) above and confirm it returns `250` — `Message accepted for delivery`. A `535` means the credential failed; a `554` means the message or recipients were rejected.
2. Open **Messages → Tools → Delivery log** and look up the sent message by recipient. SMTP-relayed messages appear in the same log as API sends, carrying the source `smtp-relay` in their metadata. See [Delivery log](/guides/delivery-log) for the search and filter surface.
3. Check the domain's deliverability view if the message queued but did not land — a DNS drift or suppression hit surfaces there first.

## 6. Limits

* **Attachments are not carried through.** The relay reads attachment headers for count only; the file bytes are dropped before dispatch. Send attachment-bearing email over the HTTP API instead — see [Email attachments](/guides/email-attachments).
* **No templates or idempotency keys.** The relay accepts a fully rendered RFC 5322 message; template resolution and the `idempotency-key` header exist on the API only.
* **Body selection** — when a message carries both `text` and `html` parts, the relay prefers the non-empty HTML part, matching the API's body selection.
* **Envelope `RCPT TO` is the authoritative recipient list.** `To`/`Cc` headers are a fallback only when no envelope recipients are present; `Bcc` recipients deliver because they exist in the envelope. A single submission fans out to one message per recipient and delivers to every accepted recipient even when others are rejected.
* **Engagement tracking is not toggled per SMTP session.** Open and click tracking follow the per-domain configuration senders share between both paths — set it under **Channels → Email → Domains** (see the [Email channel reference](/channels/email)).

## Related guides

* [Email channel reference](/channels/email) — the full email surface
* [Email channel lifecycle](/guides/email-lifecycle-guide) — domain setup, warm-up, suppression, error catalog
* [Email attachments](/guides/email-attachments) — size limits and the MIME allowlist on the API
* [Inbound email and SMS routing](/guides/inbound-email-parse) — the receiving half of email
* [Delivery log](/guides/delivery-log) — tracking relayed messages end to end