UI/UX library › Give a site its own mail

Give a site its own mail

Your site sends as invitations@yoursite.org, never from a Gmail address. Free, and you never run a mail server.

Your site never sends the mail itself — a new mail server lands in spam for months. Brevo sends for it, and three lines in your domain's settings prove you allowed it, so the reader sees your address.

To do it on a new site: give your Claude the recipe, then ask

First, once per machine. Your Claude does not know this recipe until you give it to it. The recipe is a small file called branded-mail. Install it with one command in your Claude Code:

npx skills add gfrankgva/studio-skills

Or take the file yourself: download branded-mail and put it in ~/.claude/skills/branded-mail/SKILL.md. More ways, and what else is in the pack: further down this page.

Then just ask, in your own words: « Give yoursite.org its own mail. » Name the site, and add a sender name if you want something other than invitations@. Your Claude then does the seven steps below, and the only moment it needs you again is step 3 — and only if the domain is not at GoDaddy.

The seven steps, and whose hands

About twenty minutes, most of it waiting

1 · The account. Yours, opened once, then never again. Sign up free at brevo.com/free-plan, make a key at app.brevo.com/settings/keys/api, and paste it to your Claude once. It stores it and never shows it again. One account holds all your sites, so this step happens on your first site only. Frank: yours exists — the free SCRC account at app.brevo.com; skip to step 2.

2 · Claude declares the domain. It adds yoursite.org at app.brevo.com/senders/domain/list; it answers with three lines to put in the domain's settings — two that sign your mail, one that names who may send it.

3 · The three lines go into the domain. Your hands, only outside GoDaddy. A domain at GoDaddy Claude writes itself. Anywhere else it hands you the three lines and the exact page to paste them: Cloudflare → your domain → DNS, Google Domains → DNS, Namecheap → Manage → Advanced DNS, or the same page at whoever holds it. You paste, and say « done ».

4 · Claude waits and watches. The lines take minutes, sometimes an hour, to spread. Nothing for you to check — it keeps asking Brevo until it says verified.

5 · Claude creates the sender. invitations@yoursite.org at app.brevo.com/senders/list, with replies pointed at your own mailbox so anyone who answers reaches you.

6 · Claude wires your site to it. The site's sending function gets the new driver and the key. Nothing changes for its visitors; the mail they receive simply arrives from your name instead of a stranger's.

7 · Claude proves it from the live site. One real mail through the flow a visitor actually triggers, checked to land in the normal inbox rather than spam — then the site joins the list below.

What it costs. Nothing. 300 mails a day, counted across all your sites together, and each mail's footer says « Sent with Brevo ».

Give it to a colleague

This whole page is a skill — a small file of instructions their own assistant reads and follows. They install it once; after that they simply say « give our site its own mail » and their assistant does the seven steps below, on their sites, with their own free account.

One command, in their Claude Code:

npx skills add gfrankgva/studio-skills

That installs this skill together with the studio's six others. Nothing else to set up — no key of yours, no account of yours: each person uses their own free account, and their own domains.

Or take the file itself: download the skill (one file, put it in their ~/.claude/skills/branded-mail/) · read it on GitHub · the whole pack.

Without the skill it still works — the seven steps below are the whole method, and anyone can follow them by hand. The skill only means their assistant already knows them.

Putting it in your own software

For a site not built here, or a colleague doing it themselves. Three things, and no mail server anywhere.

One sending function, one place. The whole application calls a single send_email(to, subject, body). Everything else — which service sends, which key — is settings, never code. That is what makes swapping the sender a one-line change later instead of a hunt.
Two settings, kept outside the code. The key, and the address to send as. Never written in a file that goes to GitHub: they belong in the server's own settings file, readable only by the account that runs the site.
The service is reached over the web, not over mail ports. One ordinary web request to https://api.brevo.com/v3/smtp/email carrying the key. Servers that block outgoing mail ports do not block this, which is why it works where a mail server would not. Reference: developers.brevo.com.

If the mail lands in spam anyway, the three lines are wrong or not yet spread — check the domain at app.brevo.com/senders/domain/list before touching anything in the code.

The four traps

Each of these has broken a real sending domain

Two SPF lines on one domain kills all of it. A domain may carry exactly one. If the domain already has an SPF line, merge the new sender into it; a second line makes every mail from that domain suspect, including mail that worked yesterday.
Never overwrite the domain's existing settings. Read what is there, add to it. Blind writing wipes what makes the website, or the existing mailbox, work.
One account, many sites. Each new site is one more domain inside the same account. A second account splits the daily allowance and doubles what has to be watched.
Send the proof from the live site, not by hand. A test sent from a console proves the account works, not that the site does. The mail must leave the real flow the visitor triggers.

Your sites today

Your site	Sends as	State
voxpopuli.one	`invitations@voxpopuli.one`	Steps 1 to 5 done, step 6 not. Checked on the server today: the live site still sends from a stranger's address. Say « switch Vox Populi over » and it is done in a minute.
Any other site of yours	`invitations@thatsite`	Not started. Name it, and about twenty minutes later it sends under its own name.

Every site shares the one free account, so a second site costs nothing and needs no new sign-up from you.

When you need more than this

More than 300 mails a day. Say the number you expect, and Claude prices the paid step before anything is bought — never a surprise on a card.
You want to read mail at that address too. This page only sends. Receiving is a separate free step (mail forwarded to your normal mailbox); ask for it and Claude sets it up.
Removing « Sent with Brevo » from the footer. That needs the paid plan; Claude says the cost first.
A colleague wants to send from their own site. They need no account at all — the account belongs to your software, not to a person. They only need a login if they want to open Brevo themselves, about $9 a month each.