Documentation

A support inbox on your own domain

help@your-domain.com can really work, through Kicklace. Somebody writes to it, the message lands on their record with the words of the email on it, the people who run the workspace hear about it, and a copy arrives in your own mailbox with Reply pointing back at the person who wrote.

help@your-domain.com really works, through Kicklace. Somebody writes to it, the message lands on their record with the words of the email on it, the managers hear about it, and a copy arrives in your own mailbox with Reply pointing back at the person — so you answer it from Gmail, Outlook, or wherever you already read mail.

Written 2026-09-08 for #227. It builds on the inbox Kicklace already had (#170, replies) and needs nothing from anybody: no forwarding service, no second provider, no Google project.

What it costs you

One DNS record, and the decision to let Kicklace take the mail at that domain.

Setting it up

1. Settings → Sending → Sending domain. Your own domain has to be registered and verified there first. An inbox is an address at that domain, so Kicklace has to know the domain before it can take mail for it.

2. Settings → Sending → Inbox → Take mail on <domain> itself. The screen says:

Every email to @your-domain.com will arrive here. Only do this if nothing else receives mail at your-domain.com.

Type the domain out to confirm. That is the whole guard, and it is there because an MX record on a domain moves every address at it: if a mailbox at that domain is where your own email arrives today, this is not the thing to do — set a reply subdomain up under Replies instead, which takes replies and nothing else.

3. The MX record. Kicklace shows it under Replies and under Inbox: one MX record on the domain, pointing at Resend's inbound host. Put it wherever your domain's DNS lives — for a domain bought at Vercel that is Domains → the domain → DNS Records — and replace any MX record that is there already, including a forwarding service's. It has to be the only MX record on the domain, and the lowest priority there, or mail will not reach Kicklace. Then press Check DNS.

4. Settings → Sending → Inbox → open an address. help, forwarded to your own mailbox. Up to ten addresses per workspace. reply, log, postmaster and abuse are kept for Kicklace itself, and the address you forward to has to be somewhere else — a mailbox at the same domain would come straight back here.

What happens to a message

One support row on the sender's record: the subject, the words of the email, the day, and the sender's own address as who wrote it. Which of your addresses it came to is on the row, so help@ and sales@ are told apart without another table.
A person, when Kicklace has never seen that address: with an email and nothing else — on no list, with no consent record, so nothing may be sent to them for it.
One notification to every owner and admin — "New email to help@your-domain.com from Ada Lovelace: The export button does nothing" — in the bell, and in the Slack channel if one is connected.
One forwarded copy, to the address you named. It goes out from your workspace's own sender, with the person who wrote as the Reply-To, so pressing Reply in Gmail answers them and not Kicklace. The subject is [help@your-domain.com] <their subject>, and the first three lines say who wrote, which address they wrote to, and when.
The person counts as engaged. Writing in is their own action, so a member may answer them from the record's Email button as well as from their own mailbox, and a transactional automation may answer a support message without anybody being on a list.
Their Last activity moves forward, and any automation waiting on a support message hears it.

Nothing is ever sent back automatically, and nobody is put on a list.

Attachments

An attachment stays on the record in Kicklace and is named in the forwarded copy rather than carried by it — "Attachments, which stayed on the record in Kicklace: screen.png (4096 bytes)". A forwarded copy is a courtesy so somebody sees the message in the mailbox they live in; re-uploading files through a second provider to get them there is not, and a customer's file has one home.

What is refused

Every refusal shows on Settings → Your website → Your website's heartbeat, in plain words, so nothing is lost quietly.

What arrived	What happens
Mail to an address nobody opened — `sales@` when only `help@` exists, an old alias, a guessed one	Dropped: No inbox here answers that address, so it was dropped. With the whole domain arriving, this is most of what turns up; none of it is somebody writing in, so no person is made for it and nobody is notified. One row a minute, because a run against guessed addresses would otherwise be the whole heartbeat.
The forwarded copy could not go out	The message is on the record and the bell rang anyway: It landed on their record; forwarding it on to your mailbox failed. Nothing is retried today.
More than a hundred new people have arrived by mail today	The rest wait for tomorrow. The cap is on people Kicklace has never seen; somebody already here always lands.
The same delivery twice — a retry, a replayed webhook	Recorded once, and forwarded once.

What does not change

The signed addresses keep working exactly as they did: a reply to an email Kicklace sent still finds the person it named (reply+…, #170), and the address a member BCCs still files the email they sent from their own mailbox (log+…, #208). Both are found by their signature, not by the domain they are on, so taking mail on the domain itself moves neither of them.

Removing the inbox never touches sending. The domain at Resend is the same record every one of your emails leaves from, so Stop taking mail switches the receiving capability off and leaves the domain exactly where it is. The screen says so: "Replies go back to your reply-to address and every inbox closes. Sending is not affected. Everything already on a record stays." For the same reason, removing the sending domain is refused while it is taking mail — stop that first.

For Kicklace itself

help@kicklace.com is printed on the site's footer, its privacy and terms pages, and its error pages. Until this is set up it resolves to whatever NEXT_PUBLIC_KICKLACE_SUPPORT_EMAIL is set to, which today is Michael's own Gmail. The steps, in order, and only Michael can do them:

Settings → Sending → Replies, in the kicklace workspace: the reply subdomain must be removed first if one is set — one domain takes mail, not two.
Settings → Sending → Inbox → Take mail on kicklace.com itself. Type kicklace.com to confirm.
Vercel → Domains → kicklace.com → DNS Records: add the MX record the screen shows, and remove any MX record already there, including a forwarding service's. Then Check DNS on the same screen. Verification can take a few minutes after DNS propagates.
Settings → Sending → Inbox: open help, forwarded to his own address.
Send a test to help@kicklace.com from somewhere outside, and check it lands on a record and arrives in his mailbox.
Vercel → Settings → Environment Variables: delete NEXT_PUBLIC_KICKLACE_SUPPORT_EMAIL, then redeploy. SUPPORT_EMAIL in src/lib/support.ts falls back to help@kicklace.com, so the site prints the real address from then on.

Nothing in the code names anybody's personal address; step 6 is the only reason one is on the site today.

How it works, for anybody who asks

Resend registers a domain once, and a domain can both send and receive: capabilities: { receiving: "enabled" } on the record the workspace already has, rather than a second domain, because Resend will not create one that exists. The MX comes back among that domain's records, and Kicklace stores onSendingDomain beside it so nothing anywhere can treat the two halves as separate domains — one read of that record answers both, and each half is judged by its own DNS records, so a receiving MX that is not in yet never makes a verified sending domain look broken.

An arriving message is read in this order: the BCC address (#208), then the signed reply address (#170), then the inboxes, then — only when the domain itself is taking mail — dropped. On a reply subdomain an unsigned address still lands as a person writing to a stale address, because nothing else is addressed there.

This page is still written partly for the people building Kicklace, so parts of it are about work that is not yours to do. It is here because what it describes is real; it is not listed on the documentation index until it has been rewritten.