SMTP relay

Connect

Ports

The envelope decides delivery, the header decides identity

Two addresses matter in an SMTP conversation, and Posthaste keeps them as separate as the HTTP API does. RCPT TO decides delivery — it is the mailbox the message actually reaches, and it is what suppression and the recipient count check against. The From: header decides identity — it is what the recipient reads, what DKIM signs, and what has to be on one of the account’s verified domains, exactly the rule Send an email documents for the from field. MAIL FROM is never consulted for authorization — checking it would open the exact “authorize on a domain you own, display one you don’t” spoofing hole this split closes.

A message carrying two From headers is rejected outright rather than having one silently picked — the classic DMARC-confusion shape, and a parser that resolves it quietly turns it into a spoofing primitive instead of a refusal.

The message you send is parsed into fields, and the wire message is rebuilt from those fields — your raw bytes never travel further than this relay. A handful of headers are dropped rather than relayed, because they are trace/trust material every mail submission agent strips at the door: Received, DKIM-Signature, Return-Path, Authentication-Results, and the ARC set. Posthaste writes its own DKIM-Signature, Message-ID, Date, Return-Path and Feedback-ID on the way out — a header you supply under any of those names is replaced, not merged. Custom headers pass through untouched: X-* headers, In-Reply-To and References all reach the recipient exactly as you wrote them.

Retrying safely

Your own Message-ID header is what makes a retry safe, the same role idempotencyKey plays on the HTTP API — see idempotency. The relay derives a key from your Message-ID and the recipient together, so if your connection drops after DATA and your client’s queue re-offers the identical message to the identical recipient, the second attempt gets 250 again — nothing is sent twice. Most mailers set a Message-ID automatically; what matters is that yours does not change between attempts at the same send.

Suppression is per recipient

A suppressed address is refused at RCPT TO, before DATA, and only that recipient is refused — the rest of the envelope is unaffected. Send to five addresses with one on the suppression list: that one gets 550 5.7.1 with the reason at RCPT time, and the other four still go through DATA and deliver normally. This is SMTP working the way it is supposed to — a well-behaved client’s queue narrows its own recipient list on a 5xx and keeps the rest, instead of one bad address on a list sinking the whole message.

The same waybill as an API send

An accepted SMTP message shows up in the dashboard exactly like an API send: the same message record, the same event chain, the same 30-day retention window. The one visible difference is on the accepted event itself — its payload carries "source": "smtp" instead of "api", which also reaches your webhook if you listen for that event. Attachments work identically too: up to 10 files, 10 MiB combined once decoded, and the same executable-type denylist the HTTP API checks.

One thing does not carry over: scheduled sending is API and SDK only. Every message submitted here sends immediately regardless of its Date: header — that header is display metadata for the recipient’s mail client, not an instruction to us.

Reply codes

A queue-based mailer’s whole debugging surface is the reply it got back, so this is the complete set — every code this relay can return, grouped by where in the conversation it happens.

Connecting and authenticating

MAIL FROM and RCPT TO

The message itself (DATA)

Success

Clients with no retry queue

Most application mailers have no queue of their own: PHPMailer and wp_mail() on WordPress, Python’s smtplib used directly, Rails ActionMailer’s default deliver_now, and a bare nodemailer transport all send once, synchronously, and either raise once or — in wp_mail()’s case — return false and move on. To code shaped like that, a 4xx is not “retry later”, it is a lost message: nothing downstream is watching for it to run again.

Watch your account’s daily warmup allowance in the dashboard if your client has no queue — a new account starts on the first rung, and a burst that clears it turns into 452 4.2.1 on every message after, with nothing on your side noticing until a customer asks where their email went.

Connect your app

WordPress plugins take the same five fields as everything else on this page:

# WP Mail SMTP or FluentSMTP → the plugin's SMTP settings screen
SMTP Host        smtp.posthastemail.dev
SMTP Port        587
Encryption       TLS (STARTTLS)
Authentication   On
SMTP Username    posthaste
SMTP Password    <an API key with the emails:send scope>

# "From Email" in the plugin IS the From: header — it must be an address on
# one of your verified domains, checked the same way as an API send.
# Field names differ a little between plugins; the values above don't.

Everywhere else, it is a normal SMTP transport configuration:

import nodemailer from 'nodemailer'

const transport = nodemailer.createTransport({
  host: 'smtp.posthastemail.dev',
  port: 587,
  secure: false,     // 587 (and 2587) are STARTTLS, not implicit TLS
  requireTLS: true,  // refuse to AUTH if STARTTLS didn't happen
  auth: {
    user: 'posthaste',
    pass: process.env.POSTHASTE_KEY,
  },
})

await transport.sendMail({
  from: '[email protected]',
  to: '[email protected]',
  subject: 'Invoice 2026-114',
  text: 'Your invoice is attached to your account.',
})