Email

One rule runs through every part of it, and it is not a setting:

Kicklace only emails somebody who asked, or who got in touch first. A person who joined a list gets what that list is for. A person who bought, signed up, wrote in or replied can be written to about that. Anybody else — imported, bought, merely seen by the tag — cannot be emailed at all, and there is no switch that turns it off.

This page is the whole of email in one place, with a link to the page that goes deeper on each part.

---

Lists, and the words people agreed to

A list is a reason to write to somebody: Product updates, The waitlist. Every subscription carries the exact sentence the person read, stored word for word beside the day and their IP address — not the list's own current wording, and not a summary of it. That record is the proof, and it survives everything: taking somebody off a list keeps their consent record, because it is the evidence they once agreed.

A signup can come from the tag hearing your own form, a form Kicklace hosts for a builder that owns its own, POST /api/v1/events with subscribe, a member adding one person by hand, or a bulk action — and every one of them is refused without the sentence (missing_consent).

Every email tied to a list carries a line saying why the person is getting it, an unsubscribe link that is theirs alone, and the List-Unsubscribe headers that put an unsubscribe button in the reader's own mail app. /unsubscribe/<token> is the page; POST /api/unsubscribe/<token> is the one-click version mail apps use. Beside it, /preferences/<token> lists every list in that workspace the person is on and lets them leave the ones they no longer want. Neither ever re-subscribes anybody: fresh consent happens on your website.

Lists are made under Settings → Lists, and a list's own page is where you see who is on it, who left, and the consent proof behind each one.

Broadcasts: one email to a list

Draft, preview against real people, send now or schedule. It goes to everybody subscribed to that list at the moment it sends, so somebody who leaves between the schedule and the send does not get it.

• One row per person, so a send interrupted halfway is finished by running it again and nobody gets it twice.
• {{first_name}}, {{name}}, {{email}}, any field of your own, {{organization}} and {{signature}} are filled in per person. An unknown one is left empty, never as braces: nobody may receive an email that says {{phone}}.
• Each copy lands on that person's timeline, so the record says what they were sent.
• Only owners and admins send or schedule.
• Afterwards the broadcast's own page counts what happened: delivered, opened, clicked, bounced, complained, and how many left the list since.

One-to-one, and the engaged rule

The Email button on a person's record writes to that one person. It asks the engaged question first — an active subscription, or the newest of a purchase, a signup, an activation, a support message or a reply — and where the answer is no it shows the reason instead of the form, rather than a greyed-out button nobody can explain:

You can only email someone who has been in touch — bought, signed up, written in, replied, or joined one of your lists — so put them on a list with the words they agreed to, or wait until they get in touch.

A direct email carries a reason line saying which of those it was, and no unsubscribe link, because there is no list to leave; where the person is on a list as well it links to their preferences.

The same thing is an API. POST /api/v1/messages and POST /api/v1/people/<who>/messages take { to, subject, body } or a template's name, so your own admin console can write to a customer through Kicklace and the email lands on their timeline like any other. The refusals are not_engaged, no_such_person, no_email, unknown_template, missing_body and invalid_subject. GET /api/v1/messages with the same key reads them back — filtered by person, direction and date, newest first — and GET /api/v1/people/<who>/messages is the whole thread with one person, oldest first.

Transactional: an email caused by what they just did

A receipt, a thank-you, an answer to a support message. There is no list behind it, and there does not need to be — but there does need to be something the person did.

An automation's send step is transactional when it names no list, and Kicklace refuses to switch on an automation whose transactional send is not caused by the person's own action:

Send <template> needs a list, or a trigger that is the person's own action (a purchase, a sign-up, a support message, a reply, or an event your servers post)

At the moment it runs, a transactional send asks the same engaged question a one-to-one send does, and skips somebody who has not been in touch. The automation language has the step; the emails themselves are ordinary templates.

Replies come back

Every email Kicklace sends to a person carries a Reply-To that names them, so when they hit reply the answer lands on their own record as a message you can read, and the automation waiting to follow up in three days knows the conversation already happened.

The address is reply+<record>.<signature>@<your reply subdomain>, signed so it cannot be forged, and it needs a receiving subdomain — usually reply.your-domain.com — set up under Settings → Sending → Replies. A reply from somebody Kicklace has never seen makes a person with an address, on no list.

Nothing is ever sent back automatically. A reply is written down and the people who run the workspace are told; what happens next is a person's decision.

The email you send from your own mailbox

Most conversations still happen in Gmail, Outlook or Apple Mail, and Kicklace joins them without connecting to anything:

• BCC an address and the email you are writing lands on the customer's record as sent by you.
• Forward an email to a second address and it lands as received, from the person who really wrote it — read out of the forwarded message's own header block rather than off the envelope.

Both addresses are on Settings → Sending → Replies, both are signed, and both accept only a member's own address. No account is linked and nothing about your mailbox changes. Filing the emails you send and receive has the exact Gmail and Outlook filter steps.

A support inbox on your own domain

help@your-domain.com can really work, through Kicklace: the message lands on the writer's record with the words 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. A support message is also one of the things that makes somebody engaged, so you can answer from their record. A support inbox on your own domain has the steps.

What an email looks like

The words you write are plain text with a little markup — a blank line is a paragraph, - a list, # a heading, **bold**, [label](url) a link, a link alone on its line a button, --- a rule, ![caption](https://…) a picture — and Kicklace draws them inside a card with your name at the top. You choose the logo, the accent, the display face and the body font; a signature can be the workspace's or each member's own. What your emails look like is all of it.

Sending from your own address

Until you add a domain, mail goes from a shared Kicklace address with your workspace's name in front of it. Settings → Sending takes your domain, shows the DNS records to add, and checks them; from then on your email comes from you, which is most of what deliverability is. Kicklace re-checks daily, tells you if a domain stops verifying, and keeps sending from your domain while a check is in flight.

Bounces and complaints

A bounce or a spam complaint comes back to Kicklace, and it acts on it: the person is taken off every list, the note goes on their email identity, a line goes on their timeline, the send is marked, and the people who run the workspace are told. A transient bounce — a full mailbox, a server having a bad afternoon — is logged and nothing else. This is not optional and it is not configurable, because continuing to email an address that bounced is how a sending domain dies.

What never happens

• No cold outreach. There is no way to email a list you bought, and no setting that would allow one.
• No email because an AI asked. Claude, and the assistant inside the app, can write a draft and hand you the link. Sending is a person's act — through an approval, or by pressing send. What the AI does has that rule in full.
• No email you cannot leave. Every list email carries one-click unsubscribe, and the preferences page is one link away from all of them.