Agent Inboxes

Agent inboxes give your agents real email addresses on your own domain. Mail that arrives is stored in your database — the one you connect on Settings → Inboxes — and your agents read it with credentials scoped to a single address.

Everything below lives on Settings → Inboxes.

Set up a domain for inbound

1. Authenticate the domain (Settings → Domains) — inboxes require a verified sending domain.
2. Connect an inbox database (Postgres with pgvector). Bring your own connection string, or connect Supabase/Neon and we provision a project on your account.
3. Click Enable inboxes on the domain, then add the MX record we show you and click Check DNS until it resolves.

Choose how the domain accepts mail

Each inbox domain has an Accepts mail for setting with two modes:

Bounding a catch-all

A catch-all is never unlimited — an open domain is a dictionary-attack target. When you switch to catch-all you can set:

• Only addresses matching — an optional pattern such as support-*. Use * for any run of characters and ? for one. Up to 64 characters of letters, numbers, . _ + - and those wildcards. Leave it empty to accept any local part.
• Max addresses — how many auto-created inboxes this domain may hold, between 1 and 1000 (default 50).

Two further limits are always on and not configurable: at most 20 auto-created inboxes per hour per domain, and the reserved local parts postmaster, abuse, noreply, no-reply, security, and dmarc are never created — they belong to the platform operator (RFC 2142).

Switching back to Addresses I create clears the stored pattern, so turning catch-all on again later starts from "any address" rather than silently re-applying an old glob.

Create an address

Under Inbox addresses, fill the local part, pick the domain, and optionally set a display name and a Forward to mailbox.

Edit an address

Click the pencil on the row. You can change:

• Display name — cosmetic, shown in the console.
• Forward to — a mailbox that receives a copy of every message. Mail is still stored in your inbox database; forwarding is an addition, not a redirect. Copies carry Auto-Submitted: auto-forwarded (RFC 3834) so autoresponders on the other end stay quiet. Clear the field to stop forwarding.

The address itself cannot be changed. It is the routing key, it is mirrored into your database, and your agents' credentials were issued against it — to rename, create the new address and delete the old one.

You cannot forward to an address that is itself one of your inboxes, or to the inbox's own address: every forwarded message would arrive back on your domain and forward again.

Turn off vs. delete

Turn off flips the inbox to disabled. Mail to it is refused, but the row, its agent credentials, and everything already stored stay put. Turn it back on whenever you like. This is the reversible option, and usually the right one.

Delete removes the address and its agent credentials permanently. Mail is refused, tokens issued for it stop working. What it does not do is touch your data: the messages already in your nevarmail.emails table stay exactly where they are, and the mirrored inbox row stays too, so old mail remains readable and attributable. Creating the same address again later gives you a new inbox with a new id, alongside the old history.

On a catch-all domain, deleting an address is not permanent in practice — the next message to it recreates the inbox. Turn it off instead, or narrow the catch-all pattern.

Give an agent access

Under Inbox users, create a user on an inbox to get an OAuth client id and secret scoped to that one address. The secret is shown once. Use it with the client-credentials flow (see Authentication) or point an MCP client at the inbox console. Disconnect revokes an agent's tokens without touching the inbox.

Billing

Only inbox domains are billed, plus metered inbound and outbound volume. Creating, disabling, or deleting an address costs nothing and changes no subscription item.