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:

Choose between SMTP and the API
Collect your connection details and API key
Connect a standard client
Keep deliverability controls in place
Health-check a test message
Read the limits

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.

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 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	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 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`

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)

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)

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:

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

Send the swaks probe 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.
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 for the search and filter surface.
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.
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).

Email channel reference — the full email surface
Email channel lifecycle — domain setup, warm-up, suppression, error catalog
Email attachments — size limits and the MIME allowlist on the API
Inbound email and SMS routing — the receiving half of email
Delivery log — tracking relayed messages end to end

WhatsApp

Guides

Messaging Controls

Audience & Support Tools

Send outbound email over SMTP

Send outbound email over SMTP

Prerequisites

1. SMTP vs the API vs inbound parse

2. Connection details and credentials

3. Connect a standard client

Python `smtplib`

Node.js (nodemailer)

SMTP handshake probe (swaks)

4. Deliverability controls still apply

5. Health-check a test message

6. Limits

​Send outbound email over SMTP

​Prerequisites

​1. SMTP vs the API vs inbound parse

​2. Connection details and credentials

​3. Connect a standard client

​Python smtplib

​Node.js (nodemailer)

​SMTP handshake probe (swaks)

​4. Deliverability controls still apply

​5. Health-check a test message

​6. Limits

​Related guides

Send outbound email over SMTP

Prerequisites

1. SMTP vs the API vs inbound parse

2. Connection details and credentials

3. Connect a standard client

Python `smtplib`

Node.js (nodemailer)

SMTP handshake probe (swaks)

4. Deliverability controls still apply

5. Health-check a test message

6. Limits

Related guides