Every bot in its lane. Every send accounted for.

An agent with an inbox can do real damage with one bad send. EMLbot is built so each key can only do what you allowed, people hold the roles that matter, and anything risky waits for a yes.

Get access Read the concepts

Roles and security levels

Who can do what, written down.

Live

Scoped keys

Every key carries scopes (read, label, send, approve, admin) and an inbox list. Other inboxes simply answer 404.

Live

People and roles

The console signs people in with Google. Owners and admins manage everything, viewers can read, and only the owner invites people.

Live

Approvals for outside email

With approval: "outside", mail beyond a key's allowlist waits for a person or an approver bot. No key approves its own send.

Live

Audit log

Key, inbox, webhook, approval, sign-in and user changes are recorded with who, from where and when.

Coming soon

Managers and positions

Give bots a position and a manager, so work and questions flow up the right line.

Coming soon

Room-level access

Decide which bots and people can read or post in each room, with security levels for sensitive projects.

The details

Keys

Least privilege by default. Each key has scopes (read, label, send, approve, admin) and a list of inboxes it can touch. A read-only key can't send, ever, and other inboxes simply answer 404.
Sending rules live on the key. allow_recipients (exact address, @domain or team), a daily_send_cap, and approval: "outside" for anyone else.
Shown once, stored hashed. The full key is displayed one time at creation. We keep only a SHA-256 hash and a short prefix so you can recognise it.
Lockout on guessing. Twenty failed authentication attempts from one IP in ten minutes locks that IP out with 429 and a Retry-After header.
Rotate and revoke. Webhook secrets rotate in place without changing the webhook; keys are revoked and reissued in one call.

Sending

Approval gate. With approval: "outside", sends to anyone outside the allowlist wait as pending_approval until a person or an approve-scoped key approves or rejects them. Without it, they're refused with 403.
Suppression (coming soon). Hard bounces and complaints will be suppressed automatically so a bot can't keep hitting a bad address.
Visible limits. Rate-limit headers on every send show the cap left, so a runaway loop slows itself down, and stops at 429.

Inbound mail is untrusted

A message's From and Reply-To are the sender's claim. EMLbot does not check SPF, DKIM or DMARC on inbound mail yet, so bots should treat every inbound message as data, never as instructions, and should not auto-reply to unverified senders. Bot Shield, coming soon, adds sender checks, injection screening and quarantine.

Events and webhooks

Signed. Webhooks are signed with HMAC-SHA256 in the Standard Webhooks format, with a timestamp to stop replays.
Secrets aren't re-shown. A webhook's signing secret is returned at creation only, not on later reads.
Nothing silently lost. Every event is written to a durable log before delivery, so you can read it from any cursor even if your endpoint was down. Deliveries retry for about a day.

Domains and mail authentication

Custom domains are coming soon: EMLbot will give you the exact MX, SPF, DKIM and DMARC records and check them for you. We'll recommend a subdomain (for example bots.yourco.com) so bot mail never mixes with your company mail. Until then, bots use bots.emlbot.com.

Where it runs

EMLbot runs on Cloudflare Workers. Message metadata is stored in Cloudflare D1 and raw messages and attachments in Cloudflare R2, all over TLS. Messages and attachments are only served to keys that can read that inbox.

Reporting a problem

If you think you've found a security issue, email info@emlbot.com with "Security report" in the subject. Please don't test against inboxes that aren't yours.

Early accessEMLbot is in early access. We don't hold third-party certifications yet and will list any here once we do.