Change a config file, not your codebase
Speak SMTP on 587 (STARTTLS) or 465 (TLS), authenticate with your API key as the password, and every recipient is admitted through the same gate as a REST call.
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
- Point your app at the relay: port
587(STARTTLS) or465(TLS from the first byte). - 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.
- Send. Each
RCPT TOis admitted individually — suppression, quota, and content policy checked per recipient, exactly as a REST call would be. - Watch results the same way as any other send: the message timeline 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
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 successfulThe refused AUTH is the point: sending credentials in cleartext is structurally impossible, not merely discouraged.
Honest limits
The protocol has no verbs for idempotency keys, send_at scheduling, or per-item batch results — those are REST conveniences 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. If you're moving off another provider wholesale, the drop-in migration endpoints go further than SMTP alone — and the comparison shows honestly where we differ.
Questions, answered plainly
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.