KoltrixHow we send ReminderIt's email
ReminderIt is our other product. Every reminder, receipt and support reply it sends goes through Koltrix. Here is the whole setup, including the awkward parts.
On this page(5 sections)
Koltrix was not built as a product first. It was built because ReminderIt — our reminder-calling service — needed to send email, and the options were a transactional API that could not receive a reply and a mailbox host that could not send at volume. We ended up running both, badly, and then wrote the thing we wanted.
So the honest version of this case study is: ReminderIt is customer number one, we are the founder of both, and nothing below is a reference from a stranger. It is a description of a setup you can copy.
One domain, three kinds of mail
ReminderIt sends three things that people usually treat as three products:
- Transactional mail — “your reminder was placed”, password resets, receipts. Machine-generated, must arrive, nobody expects a conversation.
- Support mail — a human reading and answering questions at an address a human owns.
- Replies to transactional mail — the category that usually disappears. Somebody hits reply on a receipt, and at a normal setup that mail hits a
noreply@black hole.
All three run on the same domain, with one set of DNS records, one DKIM key and one reputation to look after.
The sending side
The application posts to one endpoint. There is no SDK to install; it is a JSON POST with a bearer token.
curl https://api.koltrix.com/api/v2/emails \
-H "Authorization: Bearer kx_live_..." \
-H "Content-Type: application/json" \
-d '{
"from": "[email protected]",
"to": "[email protected]",
"subject": "Your reminder is set",
"html": "<p>We will call you at 7:00.</p>"
}'Anything that already speaks SMTP points at the relay instead and needs no code change at all. The full reference, including idempotency keys and the delivery webhooks, is in the docs.
The part that actually changed how we work
Every message sent through Koltrix carries a signed Reply-To that points back at the workspace. When someone replies to “your reminder was placed”, the reply arrives in the team inbox, threaded under the exact message that provoked it, with the customer's earlier mail attached to the same timeline.
That sounds small. In practice it removed an entire category of support work: we no longer have to ask “which email are you replying to?”, because the thread already says.
The token is signed rather than guessable for a reason worth stating: an unsigned reply+<id>@ address is an oracle, and anyone who can count could staple mail onto someone else's thread.
What was awkward
- DNS is still DNS. The wizard generates the records and checks them live, but a registrar that appends your domain to a TXT record you already fully qualified will still ruin your afternoon. We wrote a plain-English guide to the three records mostly so we could stop explaining it in support.
- Reputation is earned slowly. A new domain sending to a cold list will be filtered no matter whose infrastructure it uses. We ramped ReminderIt's volume over weeks.
- Bounce handling has to be automatic or it does not happen. Hard bounces and complaints suppress the address without anyone deciding to.
Numbers
We are not publishing volume, bounce-rate or time-saved figures on this site until they are measured from production and can be shown to anyone who asks. Made-up metrics are the reason most case studies are worthless, and we would rather have a short one that is true.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
