A real mailbox for the project.
Support mail arrives in somebody’s personal inbox, gets forwarded twice, and dies there. A Kontacts mailbox closes that gap: the address belongs to the project, the mail lands where the team can all see it, and you reply from there. GitHub issue routing is a mode — if you want it, mail to the addresses you list opens an issue in the repository you already use. Bookings work the same way — one page for the project, not one per person.
An address that belongs to the project, not to whoever set it up
You point a domain at Kontacts — your own, or a subdomain you can spare like mail.yourproject.dev. Kontacts declares hello@ for you the moment the domain verifies, and seeds support@ and billing@ as sendable aliases on that same mailbox. You add whichever other addresses the project wants — bugs@, whatever a contributor invents next. Declaring an address is not what lets it receive mail — anything sent to the domain arrives in the inbox either way. Prefer not to declare them one at a time? Turn on the catch-all and every address at the domain counts as declared.
The inbox is shared by everyone on the project, and the bill follows the organisation rather than the seat. What a plan limits is how many people the org may hold — 1 on Free, 3 on Indie Hacker — not what each of them costs. Somebody joining sees the history. Somebody leaving takes nothing with them — the address was never theirs.
Mailbox, alias, forward, catch-all
Four words people mix up. The longer comparison is on its own page; this is the short form.
Mailbox— the project’s shared inbox. One per project. Alias — an extra From/To name on that same mailbox, not a second seat. Forwarding — an optional copy to a verified personal mailbox; the original stays here. Catch-all — optional, off by default; counts every address as declared for issue routing, and does not decide whether mail is received.
Mail in, issue out — for the addresses you list, once you switch it on
Routing is off by default on purpose: an inbox that starts filing issues the day you connect it is a bad surprise. When you do enable it, install the GitHub App, pick the repositories it may see, and point the project at one of them. From then on a message to one of the addresses on your list opens an issue in that repository, carrying the message and who sent it. The person who emailed you never learns any of this.
The App only ever sees the repositories you selected at install time, private ones included, and you can change it whenever you like.
Which addresses may open issues is a separate list, and you write it. Mail to an address nobody declared is held — it shows up in the inbox under the Quarantined label, naming the reason, and one click releases it. It does not reach the repository.
Sender authentication, not a spam folder
Anything that can open an issue in your repository is a publishing surface, so mail has to prove who sent it first. Kontacts reads the SPF, DKIM and DMARC results on each message and holds anything that fails, anything that carries nothing to check, and anything whose results we cannot read at all. Held mail is not discarded. It shows up in the inbox under a Quarantined label, naming the check that did not pass, and one click releases it if the sender turns out to be legitimate.
This is authentication, not moderation. A sender who really is who they claim to be, writing to an address on your list, opens an issue however unwelcome the message — the check answers “is this who it says it is”, never “is this worth reading”.
Domain setup is held to the same standard: SPF and DKIM are verified for you, and when a record is wrong we name the record.
Zero to hello@ — then, optionally, your first issue
- 1.Sign up — free, no card. GitHub is not required.
- 2.Create a project mailbox and name it. A repository can wait.
- 3.Point your domain’s MX, SPF and DKIM records at Kontacts and wait for green ticks. That seeds hello@, plus support@ and billing@ as aliases.
- 4.Send yourself a test at hello@. It lands in the inbox.
- 5.Optional: install the GitHub App, connect a repository, and flip routing on. A test to hello@ or another address on your list then opens an issue.
GitHub routing is optional. The mailbox works without it.
Where your mail goes out from
Once your domain is verified and you have declared an address on it, mail you send from the dashboard leaves from that address — your domain, your name in the recipient’s inbox. Until then the project sends from an address on our shared domain, so sending is never blocked waiting on DNS. The switch happens on its own; there is no setting to find.
You can reply inside a thread from the inbox. The reply leaves from the project address that received the mail, and if that thread is linked to a GitHub issue it is posted as a comment on the issue. Compose-and-send a new message is still there too — a different path, not a substitute for answering in place.
What a Kontacts mailbox is not
It is not a mail client. There is no IMAP, so you cannot point Thunderbird or Apple Mail at it. It is project communication infrastructure: mail that reaches a team and turns into work.
Outbound has two paths — the dashboard composer, and POST /api/v1/send with a project API key you mint under Settings → API keys. Authenticate with Authorization: Bearer …; the body is { to, subject, text, html? }. How to call it. The same key also authenticates the hosted MCP at POST /api/v1/mcp for Cursor or Claude— list and read mail, send or reply, list domains and bookings. That is still not IMAP. Both send paths draw on the same pool, capped on Free at 10 sends per UTC day. That ceiling belongs to the organisation, not to each person in it — and it is shared across every project in the org, not counted again for each.
What it costs
Signing up puts you on Free. Indie Hacker is billed per organisation, not per seat, on the pricing page. Nobody is converted into a paid plan by silence. Cancelling returns the org to Free at period end; existing projects are not deleted.