Email sending

Email settings determine the address and the name that every email the system sends goes out under — signup confirmations, notification rules, and the email channel of automation flows.

The email settings page — sender name and custom domain sections

Two levels of configuration

Level	What it controls	Difficulty
From name	The sender name the recipient sees	Easy — just a string
From domain	The email address the recipient sees	Advanced — requires DNS changes

Together, the recipient sees From name <noreply@yourdomain.com> in their inbox.

Use case: a growth camp organizer's brand identity

Cheng-han's growth camp is called "AI × E-commerce Growth Camp" and his domain is aiec.tw. The configuration is:

• From name: AI × E-commerce Growth Camp
• From domain: aiec.tw (once verified)

Students receiving a signup confirmation see "AI × E-commerce Growth Camp <noreply@aiec.tw>" in their inbox, with nothing to suggest the Zenbu platform sent it. It reads like a system he built himself.

From name (set this one)

The simplest setting, and the one to do first.

The From name field

Enter your brand name (up to 80 characters) and press Save.

Left blank, recipients see only an email address with no display name in front of the <>, which reads as mail from an unknown source and lowers your open rate.

Question: Why does this matter so much?

Inbox clients (Gmail, Outlook, Apple Mail) generally show only the sender name in the list view, not the email address. With nothing set, users see a cold noreply@… string; with it set they see "zenbu webinar" or your brand name, and open rates can differ by a factor of two.

The default sender

If you don't configure a custom domain, the system uses a shared default sender address (shown with a Default label).

That address is fully functional but has two small drawbacks:

• The email address isn't on your own domain (students see noreply@zenbu…)
• The chances of landing in spam are slightly higher (a shared domain is more likely to be treated as bulk mail by some providers)

The default is fine for small-scale tests or the first few weeks of a new site. For the long term, configure a custom domain.

Custom sending domain (advanced)

Custom domain setup with the DNS records to add

The one-off setup:

1. Enter your domain (aiec.tw, say) in the send from your own domain section
2. Press Generate DNS records → the system lists three DNS records (SPF, DKIM, DMARC and the like)
3. Add those records in your domain's DNS console (Cloudflare, GoDaddy, Namecheap…)
4. Come back and press Re-verify → the status becomes ✓ verified
5. From then on, every email goes out from your domain

Note: DNS propagation takes time

DNS can propagate worldwide in 5 minutes or take 24 hours. If Re-verify doesn't pass on the first attempt, wait 30 minutes and try again.

Question: What are these DNS records, exactly?

The three are typically SPF (which servers are authorized to send on behalf of this domain), DKIM (a cryptographic signature proving the mail really came from you) and DMARC (telling recipients what to do with mail that fails those checks). All three are needed — missing any one and recipients may put your mail straight into spam.

Question: How does mail from a custom domain differ from the default?

Technically it's almost identical, but as far as the algorithms at Gmail and Outlook are concerned, mail from your own domain with all three records in place has noticeably better deliverability than a shared domain. For anything long-term, a custom domain is strongly recommended.

When the system has no API key configured

If the server hasn't been given a RESEND_API_KEY environment variable, this page shows a yellow notice reading "the system has no Resend API key configured".

In that state:

• You can still configure a custom domain and a From name (both are stored)
• But email is not actually sent (the system logs silently, without affecting anything else)
• Once the API key is set and the service restarted, sending resumes automatically

This is normally the responsibility of whoever maintains the platform — if you see this notice, contact your administrator.

Removing a custom domain

Pressing Remove clears the domain configuration, and the system reverts to the default sender automatically.

Note: removing here doesn't clear the DNS records

The records stay on your domain (the system has no permission to change your DNS). If you're no longer using them, delete those three records yourself in your DNS console. Leaving them won't affect anything else.