For startups · indie developers · hackathon teams
Signup confirmations, OTPs, password resets, receipts — sent from your own domain, signed with your own DKIM key, and tracked to whatever the receiving server actually said. Built for the projects that cannot justify an enterprise mail bill and still need mail that lands.

to=<customer@gmail.com> relay=gmail-smtp-in.l.google.com[142.250.31.26]:25
250 2.0.0 OK dkim=pass spf=pass dmarc=pass delay=0.9sMail providers price for volume you do not have yet. A side project sending forty confirmation emails a week should not need a sales call, and a hackathon team should not spend Saturday on deliverability.
Signup mails, OTPs, invoices and password resets from day one, on your own domain rather than a provider's.
Your domain's reputation belongs to you, so it survives changing providers later.
One API call from whatever you already write — Node, Python, PHP, plain cURL. No SDK required.
No per-message fee, so an experiment that sends nothing costs nothing.
A working sender in an afternoon: add a domain, publish four records, create a key, send.
Delivery you can actually demo, with the receiving server's reply on screen.
A monthly allowance, not a meter. Mail leaves through one mail server whose cost does not change with the fortieth email or the four-thousandth, so there is no per-message fee to pass on.
Counted per recipient — one message to fifty people spends fifty. Mailbox storage is for the mail you receive, pooled across the account, and every message is encrypted at rest. Past Pro it stops being a published number and becomes a conversation.
01
Add a domain and publish four records. Verification names the exact failure — a duplicate SPF record, a DKIM key that does not match, a lookup that timed out — instead of just refusing.
02
One POST. The API validates, checks the domain and your quota, writes the row and queues the job. It never waits for SMTP, because remote delivery takes seconds to minutes and that is not your request's problem.
03
Delivery is confirmed from the MTA's own log. Sent means our server accepted it; delivered means theirs did. Both are shown, because they are not the same claim.
04
Bounces are parsed to RFC 3464 and 5965, classified hard, soft or complaint, and hard failures are suppressed automatically. Replies arrive in an inbox you can read or receive by webhook.
Mail state is not a set of invented labels. It maps onto SMTP reply classes, which is how anyone reading a log already thinks. Khat shows the class, so you can tell at a glance whether something is still being retried or gone for good.


Turn receiving on for a domain, publish one MX record, and mail arrives in an inbox you can read — or as an email.received webhook. Attachments are kept, the original bytes are kept, and SPF, DKIM and DMARC results are reported for every message rather than filtered out of sight.
The default is a subdomain, not your apex — an MX record at the apex replaces wherever your mail currently goes, and that should never be a side effect of ticking a box.
Not paying per message means owning some work instead. If any of these three is a dealbreaker for your project, a metered provider is the better answer and you should know that now rather than in week two.
A new IP has none, and providers treat it accordingly. Volume ramps over two to three weeks, so this is not the choice to make the night before a launch. A shared pool like SES is warm on day one; that is the real thing you give up.
Most hosts block outbound 25 by default and Google Cloud never unblocks it. You also need to be able to set reverse DNS on the sending IP.
The logo beside a sender name is BIMI. It needs a trademark and a Verified Mark Certificate that costs four figures a year. Khat generates the record; it cannot make the certificate free.
Add a domain, publish four DNS records, create a key, send. Most people are through it in an afternoon — and the docs are open, so you can read the whole thing before signing up.