# Change a config file, not your codebase

> An SMTP relay on ports 587 and 465 where the password is your API key. Every recipient passes the same admission gate as the REST API. Arms at launch.

Canonical: https://emailfast.dev/features/smtp

## The relay for code you'd rather not touch

If your application already speaks SMTP, Email Fast is an SMTP relay service you
adopt by editing configuration. Connect on port 587 (STARTTLS) or 465 (implicit TLS),
authenticate with your API key as the SMTP password, and every message enters the
exact pipeline the REST API uses. The relay arms at launch, when outbound delivery
opens.

## How it works

1. Point your app at the relay: port `587` (STARTTLS) or `465` (TLS from the first byte).
2. Authenticate. The SMTP password is your API key — no second credential to provision, rotate, or forget. Revoke the key and the relay stops with it.
3. Send. Each `RCPT TO` is admitted individually — suppression, quota, and content policy checked per recipient, exactly as a REST call would be.
4. Watch results the same way as any other send: the [message timeline](/features/email-api) and signed webhooks.

One property worth naming plainly: the server refuses `AUTH` before TLS is
established. And behind the socket, every send — REST, SMTP, browser SDK, compatibility endpoints, broadcasts, automations — passes through one admission gate: idempotency, suppression, quota, and content policy in a single checkpoint no ingress can skip.

## The evidence

:::panel A session on port 587
```
220 smtp.emailfast.dev ESMTP
EHLO app.example.com
250-STARTTLS
AUTH LOGIN
530 5.7.0 Must issue a STARTTLS command first
STARTTLS
220 2.0.0 Ready to start TLS
[TLS established]
AUTH LOGIN
235 2.7.0 Authentication successful
```
The refused `AUTH` is the point: sending credentials in cleartext is structurally
impossible, not merely discouraged.
:::

## Honest limits

:::tradeoffs SMTP is the narrow interface
The protocol has no verbs for idempotency keys, `send_at` scheduling, or per-item
batch results — those are [REST conveniences](/features/email-api) one endpoint away
when you want them. Per-recipient admission also means partial acceptance is normal:
a suppressed address is refused while the rest of the envelope goes through. And the
relay itself arms at launch — it needs the live outbound path to mean anything.
:::

## Where to go next

Connection details and key management live in the [developer docs](/developers). If
you're moving off another provider wholesale, the
[drop-in migration endpoints](/features/migration) go further than SMTP alone — and
the [comparison](/compare/mailgun-alternative) shows honestly where we differ.

## What are the connection settings?

Port 587 with STARTTLS, or port 465 with TLS from the first byte. The SMTP password is your API key. The relay arms at launch; full connection details are in the developer docs .

## Is the SMTP password really my API key?

Yes. One credential, one revocation story: rotate or revoke the API key and both REST and SMTP access change with it. There is no separate SMTP credential to provision, forget, or leak.

## Why was one recipient refused mid-send?

Admission is per recipient: each RCPT TO is checked against suppressions, quota, and content policy individually. A message to five addresses can be accepted for four and refused for one suppressed address — that's suppression working, not an error in your client.

## Can my credentials cross the wire in plaintext?

No. The server refuses AUTH until TLS is established on port 587, and port 465 is TLS from the first byte. There is no configuration in which the key travels unencrypted.

## When can I use it?

The relay arms at launch, when outbound delivery opens. Until then, you can evaluate the identical pipeline through the REST API and its sandbox.