Broadcast Campaigns in SMTPfast

Why we added broadcasts

SMTPfast started with transactional email: password resets, receipts, alerts, invites, and other mail sent one recipient at a time.

That is still the core use case. Transactional email has to be fast, predictable, and boring in the best possible way.

But many teams also need to send the occasional product update, newsletter, changelog, or launch note to the people who already use their product. Until now, that meant exporting contacts into a separate marketing tool or writing a batch script against the email API.

Both options are awkward.

Exporting creates another contact database to keep clean. A script is fast to write, but it usually skips the parts that matter: unsubscribe handling, test sends, suppression checks, scheduled delivery, and a clear record of what happened.

Broadcast Campaigns are our answer to that gap.

What a broadcast is

A broadcast is a one-to-many email campaign sent to your subscribed contacts.

You create a draft, write the message, send a test, review the eligible audience, then send now or schedule it for later. When the broadcast is queued, SMTPfast snapshots the recipient list. That snapshot matters because it gives the campaign a stable audit trail. If someone unsubscribes tomorrow, the old campaign still shows who was eligible when it was sent.

Every recipient gets their own email record. That means broadcasts use the same queue, delivery events, open tracking, click tracking, bounce handling, complaint handling, and suppression list as regular API sends.

You can send to all subscribed contacts or to a manual contact segment. Segments are simple saved lists that live inside Contacts. They are useful for product updates, beta groups, customer cohorts, event follow-ups, and any other audience you want to manage by hand without building a full automation system.

The sending path

When you send a broadcast, SMTPfast does a few checks before any recipient is queued:

1. The sender domain has to be verified.
2. The message needs a subject and body.
3. The body has to include an unsubscribe token.
4. The account needs enough monthly email quota for the eligible recipients.
5. The account needs an available monthly broadcast slot for its package.
6. Contacts that are unsubscribed, suppressed, or invalid are skipped.

Skipped contacts are still counted in the broadcast detail view so you can see why the eligible count changed.

Broadcast package limits are intentionally clear:

Package	Manual segments	Broadcasts per month
Free	2	2
Starter	10	10
Growth	50	50
Scale	200	200

Personalization

Broadcasts support simple contact tokens:

# Hi {{contact.first_name|there}},

Your workspace is ready.

You are receiving this at {{contact.email}}.

Unsubscribe: {{unsubscribe_url}}

The value after | is the fallback. If a contact does not have a first name, {{contact.first_name|there}} renders as there.

The unsubscribe token can be either {{unsubscribe_url}} or {{{RESEND_UNSUBSCRIBE_URL}}}. Both are supported so teams moving from Resend do not have to rewrite templates.

Draft, test, schedule, send

The builder is intentionally conservative.

Drafts can be edited and deleted. Scheduled broadcasts can be canceled. Sent broadcasts are retained because they are part of your sending history.

On the audience step, choose all contacts or a segment. The preview count updates before you save so you can catch empty or stale lists before a send. Unsubscribed contacts, bounced addresses, complaints, and manual suppressions are still removed from the final audience.

Test sends use the same rendering path as the real broadcast, but they only queue one message. That gives you a real inbox preview before you send to everyone.

Scheduling works up to 30 days out. If you edit a scheduled broadcast, SMTPfast cancels the existing delayed jobs and returns the campaign to draft. That is safer than quietly changing content while a schedule is already active.

Metrics and recipient detail

The broadcast detail page rolls up:

• total recipients
• skipped recipients
• delivered, opened, and clicked counts
• bounce and complaint counts
• unsubscribe count
• delivery, open, click, bounce, and unsubscribe rates

You can also inspect individual recipients and see their event timeline. If a recipient bounced, complained, opened, or clicked, it shows on the same row instead of forcing you to jump between logs.

Click events are grouped by URL so you can see which links got attention.

Why it shares the transactional pipeline

We considered treating broadcasts as a separate system. That would have made the feature look more like a standalone marketing platform, but it would also duplicate the parts that already need to be correct: queueing, event recording, suppressions, tracking, SES webhooks, and usage accounting.

So broadcasts use the same pipeline as normal sends.

That gives you one source of truth for deliverability. A bounce from a broadcast still feeds the suppression list. A complaint still protects future sends. An unsubscribe still removes the recipient from future campaigns.

What this is not

This is not a full marketing automation suite.

There is no journey builder, lead scoring, A/B testing, or visual template editor. Those tools have their place, but they also bring a lot of weight.

This first version is for teams that need a clean way to send product updates to their own contacts without leaving the email system they already use.

How to start

Open the Broadcasts page in the dashboard, create a draft, and send a test to yourself first.

If you prefer the API, start with:

curl -X POST https://smtpfa.st/api/v1/broadcasts \
  -H "Authorization: Bearer sf_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "May product update",
    "audience": "segment",
    "segment_id": "seg_product",
    "from": "[email protected]",
    "subject": "New features for {{contact.first_name|there}}",
    "markdown": "# Hi {{contact.first_name|there}},\n\nHere is what changed.\n\nUnsubscribe: {{unsubscribe_url}}"
  }'

Then send a test:

curl -X POST https://smtpfa.st/api/v1/broadcasts/clx_broadcast123/test \
  -H "Authorization: Bearer sf_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "to": "[email protected]" }'

When it looks right, send now or schedule:

curl -X POST https://smtpfa.st/api/v1/broadcasts/clx_broadcast123/send \
  -H "Authorization: Bearer sf_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "scheduled_at": "2026-05-12T14:00:00.000Z" }'

Full endpoint details are in the Broadcasts API docs.