Skip to content
Tinbox
Sign in

Set up cold-outreach SMTP

Wire the BYO SMTP provider that carries your cold outreach — which providers work, how to create credentials, per-domain bindings, and the in-app test send.

Cold outreach never sends through Cloudflare's outbound mail — it's transactional-only by Cloudflare's acceptable-use policy, and every mainstream transactional ESP (Postmark, SES, Mailgun, Resend, SendGrid) forbids cold in their terms too. So Tinbox sends cold mail through an SMTP provider you bring, on an isolated cold subdomain, keeping cold-sending reputation away from your real mail.

Everything is configured in-app at Settings → Cold outreach (SMTP) — no wrangler secret put, no redeploy.

Which providers work

Pick a provider that contractually permits cold B2B outreach. Dedicated cold-email infrastructure providers are built for this:

  • Mailreef, Maildoso, and similar cold-email infrastructure providers — SMTP accounts per sending domain, cold-friendly terms.
  • A self-hosted relay (Postfix or an SMTP bridge) you operate.
  • Amazon SES works technically, but read its policy carefully — unsolicited mail can get an account suspended. Use it only if you understand the risk.

Do not point cold outreach at Postmark, Mailgun, Resend, or SendGrid — the first spam complaint risks the account that also carries your transactional mail.

Create the credentials

From your cold provider you need four values:

  1. Host — e.g. smtp.mailreef.com
  2. Port — usually 587 (STARTTLS) or 465 (implicit TLS)
  3. Username — often the sending mailbox, e.g. you@outbound.acme.dev
  4. Password — an SMTP password or app-specific token

In Settings → Cold outreach (SMTP) → Add config, enter those values. The password is write-only: it's encrypted at rest in your own database and can never be read back — to change it, just type a new one.

Some providers offer an HTTPS send endpoint instead of SMTP; add a Cold-email relay (HTTP) connection in Settings → Providers and route the outreach lane to it — the SMTP pane picks it up the same way.

Send a test message

Every config has a Send a test message button — a real round trip through the exact transport your campaigns will use, to an address you choose. The result is reported honestly:

  • Couldn't connect — wrong host/port, or DNS hasn't propagated.
  • TLS failed — the security setting (STARTTLS vs TLS) doesn't match the port.
  • Authentication failed — wrong username or password; re-enter them.
  • Rejected — the server answered but refused the message (usually the from address isn't authorized for that account).
  • Test sent — handed to the provider; check the destination inbox.

The last test result is stored per config, and the outreach launch-readiness check reads it: a config whose last test failed counts as misconfigured, not merely "present".

One SMTP account per cold domain

The usual cold setup is one provider account per burner/cold subdomain. Bind each verified cold subdomain to its config under Per-domain binding; anything unbound uses the org default. A binding is explicit — if its config breaks, that domain's sends queue and wait rather than silently falling back to another account.

Precedence (env vs in-app)

A worker env secret of the same name always wins over a value stored in-app:

In-app valueOverriding worker secret
SMTP config username/passwordSMTP_USERNAME / SMTP_PASSWORD
HTTP relay endpoint/tokenOUTREACH_SMTP_URL / OUTREACH_SMTP_TOKEN
SES keysSES_ACCESS_KEY_ID / SES_SECRET_ACCESS_KEY

A deployment already configured through OUTREACH_SMTP_URL keeps working untouched — the in-app store is the no-redeploy convenience, env is the canonical override.