An agent that signs itself up for its own inbox

Most email infrastructure assumes a person: someone signs up, verifies a domain, creates a mailbox, and pastes credentials into a config file. That assumption breaks the moment an agent needs an address before any of those steps have happened, which is exactly the situation for an agent spawned by another agent, a scratch environment in CI, or a swarm where the number of participants is decided at runtime.

27 July 2026 · 5 min read

The bootstrap problem#

An agent that cannot be reached is not autonomous, it is a job. To hold a conversation it needs an address, and to get an address it usually needs a human with an account, a browser, and five minutes. That human is the bottleneck, and in the cases that matter most they are also asleep, or they are the very thing you were trying to remove from the loop.

Self-signup closes that gap: one call provisions a workspace and a key, and the agent is reachable.

curl https://mcpmailer.com/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"handle": "scout", "email": "you@yourcompany.com"}'

The handle is the agent's identity: globally unique, stable, and the thing its address and its tunnel hostname are built from. The optional email is where the claim link goes, so a person can take ownership when there is one.

The claim URL is the interesting part#

A workspace created by an agent has no owner. That is fine for a scratch environment and unacceptable for anything real, so signup returns a claim URL: a link that binds the workspace to a human account.

The sequence that follows is deliberately boring. A person opens the link, signs in or registers, and the workspace becomes theirs, with the agent's identity, keys, and history intact. Nothing is migrated and no address changes, which matters because the address may already be in someone's contacts by then.

The pattern worth adopting: provision immediately, claim eventually. An agent that needed an inbox at 2am should not wait for a person, and a workspace that has been running for a fortnight should not still be unowned. Keep the claim URL somewhere a human will actually look, which usually means sending it to a real address at signup rather than leaving it in a log.

Where this is genuinely useful#

The common shape: the number of inboxes is not known when a human is available, and waiting for one would change what you can build.

The guardrails that make it safe to allow#

Open self-provisioning is an obvious abuse vector, so the limits are structural rather than advisory.

• Rate limited per IP, so a script cannot mint workspaces in bulk.
• Nothing sends until the workspace email is verified. An unverified workspace is refused with sending_locked_verify_email, which is a reason an agent can act on rather than a silent failure.
• The same allowances as any other workspace: a daily and a monthly send allowance, five recipients per message, and the duplicate-content and velocity tripwires on cold sends. Provisioning yourself does not buy you different rules.
• One key, one identity. The key returned by signup is scoped to that agent, so a leaked key costs you one inbox rather than a fleet.

That combination is what makes it reasonable to leave the door open: the cost of an abusive signup is bounded, visible, and cheap to revoke.

Naming handles you will not regret#

The handle is permanent in every way that matters: it is in the address, in the tunnel hostname, and in whatever people saved to their contacts. A few rules that save pain later.

• Name by function and instance, not by model or vendor. support-eu ages well; gpt-bot-2 does not.
• Keep them short. They appear in addresses that people type.
• Make them unique per running agent, not per deployment, so restarting does not orphan a conversation.
• Avoid anything that reads as a person's name if the agent is not a person. Being obviously an assistant is a feature, as argued in keeping an autonomous agent from becoming a spam problem.

Provisioning inside a product#

If you are building something multi-tenant, self-signup is how each tenant's agent gets an address without your onboarding flow blocking on it. Create the workspace when the tenant activates, send the claim URL to the tenant's admin, and let the agent start working immediately. The tenant claims it when they get round to it, and the audit trail from before the claim is still there afterwards.

Two things to plan for. Decide who owns the domain: tenants who want mail from their own domain need DNS records, while everyone else is fine on a mcpmailer.email subdomain from day one. And decide what happens to unclaimed workspaces after a while, because an inbox nobody owns eventually accumulates mail nobody reads.

After provisioning#

The agent has a key and an address, so the next steps are the ordinary ones: connect over MCP or use the REST API, register a webhook so inbound mail starts a run, and give it a system prompt that says what it is for. If it also needs to sign up for third-party services, the verification and two-factor mechanics are in login codes, 2FA, and verification email.

Questions#

Can an AI agent create its own email address?

Yes. POST /v1/signup with a handle provisions a workspace, an address, and an API key, and returns a claim URL a person can use later to take ownership. It is rate limited per IP.

What is a claim URL?

A link that binds an agent-provisioned workspace to a human account. Everything created before the claim, including the address and its history, stays exactly as it was.

Is self-signup safe to leave open?

It is bounded rather than unlimited: rate limited per IP, unable to send until the workspace email is verified, held to the same send allowances and tripwires as any other workspace, and scoped to one identity per key.

What handle should an agent choose?

Something short, functional, and stable, named for the job and the instance rather than the model. The handle appears in the address and the tunnel hostname and is effectively permanent.

Should production agents self-provision?

They can, as long as a person claims the workspace promptly. Unclaimed is a fine temporary state and a poor permanent one, because ownership is what gives you billing and a named human to escalate to.

Does a self-provisioned agent get a working address immediately?

Yes, on a mcpmailer.email subdomain, so it can be reached before any DNS work. Moving to your own domain is a set of records you publish once and can happen later.