Setting Up Your Own Sender Before You Send a Single Campaign
Campaigns in the email app don't send out of the box — before your first send, you need either a Resend API key or a verified SMTP connection configured for your workspace.
It's a reasonable assumption that an email-marketing app, out of the box, can send email. In this platform's email app, that assumption is wrong in a specific and important way: campaigns do not send until your workspace has configured a real sending path. This is the single most important thing to get right before you build your first campaign, and it's worth understanding precisely rather than approximately.
The two send paths
When a campaign actually sends, the request goes through email-marketing-worker, and it has exactly two ways to deliver a message:
- Resend — a direct API call to Resend, using an API key your workspace provides.
- SMTP, via the Go backend — if Resend isn't configured, the send path falls back to Go's internal
POST /api/v1/email/queue/smtp-sendendpoint, which in turn depends on a per-workspace SMTP configuration your workspace has to set up: host, port, credentials, the works.
Neither of these is pre-configured for a new workspace. Until one of them is set up, a campaign can be built, scheduled, and "sent" from the app's perspective, but nothing actually reaches an inbox.
Verifying before you rely on it
Because "configured" and "actually works" are different questions — a typo in an SMTP password, an expired API key, a hostname that doesn't resolve — the app has a dedicated test-send endpoint: POST /api/v1/email/settings/verify. This forwards to the Go backend, which does a real SMTP dial and a real test send rather than just checking that fields are non-empty. Run this before you trust your configuration with an actual campaign, not after a customer tells you they never received anything.
This distinction matters more in 2026 than it did a few years ago. Microsoft's tightened authentication enforcement on Outlook and the broader industry push on SPF/DKIM/DMARC compliance mean an unauthenticated or improperly configured sender doesn't just risk the spam folder — it can be rejected outright. "Configured" without verification is not the same as "deliverable," and the gap between those two states is exactly what a real test send catches.
Setting up SMTP
If you're going the SMTP route, you'll need your provider's host, port, and authentication credentials — the same information any email client asks for when you add an account. This gets entered into your workspace's email settings, and Go's emailsettings handler is what actually dials your SMTP server and confirms it can send: not a client-side check that only verifies the form was filled in.
Setting up Resend
If you're going the Resend route, you'll need an API key from your Resend account, configured for your workspace. This is the more direct path — a straight HTTP call from the worker to Resend's API, without the SMTP handshake — but it still requires that key to exist before anything sends, and it's worth running the same verification step to confirm the key is valid and active rather than assuming it works because it was entered correctly.
Why this isn't a limitation to work around
It's worth reframing this rather than treating it as a gap: no legitimate email platform lets you send authenticated mail from day one without you proving you own the sending identity you're using. A sender that could send immediately, with no setup, would be a sender any account could impersonate. The setup step exists because deliverability infrastructure requires it — and skipping straight to "build a campaign" without first confirming your sender is configured and verified is the single most common way a first campaign goes out to nobody.
Before you write your first subject line, confirm one thing: has your workspace verified a working sender, Resend or SMTP, through /api/v1/email/settings/verify? If the answer is no, that's the first task, not the campaign itself.