Give each mailbox only the authority its job requires.
Identity, credential scope, mailbox lifetime, and sending authority are separate decisions. Keeping them separate makes an agent workflow easier to approve, observe, and stop.
mails0 separates automatic hosted provisional mailboxes from permanent claimed identities. A provisional mailbox is random, receive-only, and expires after 72 hours in the hosted configuration. A permanent hosted claim requires explicit human approval. Mailbox-scoped keys limit access to one identity, while self-hosters can define domain, retention, sending, and operational policy for their own deployment.
Mailbox authority grows in explicit stages
The workflow earns permanence and outbound authority after it demonstrates a recurring need.
- 01Bootstrap
Create a random receive-only mailbox without a durable name.
- 02Prove value
Receive one expected message and complete the external task.
- 03Approve identity
A human claims a permanent hosted name or owns a self-hosted domain.
- 04Operate and revoke
Apply retention, sending policy, rotation, pause, and incident controls.
Do not bundle identity, duration, and authority
A named address does not need to imply sending permission. A long-lived inbox does not need an operator token. A mailbox that can receive verification mail does not need access to other addresses. These are independent dimensions and should stay independent in both policy and user interface.
The hosted bootstrap path starts at the smallest useful point: one generated address, one mailbox credential, inbound access, and automatic expiry. That path lets an agent discover and prove the product without letting an unattended process reserve a permanent public identity.
| Decision | Initial setting | Promotion evidence |
|---|---|---|
| Identity | Random address | Recurring task needs continuity |
| Duration | 72-hour expiry | Named owner and retention need |
| Direction | Receive-only | Approved sending use case |
| Scope | One mailbox | Documented administrative operation |
Keep operator and mailbox keys out of the same path
An operator key can create or administer resources across a deployment. A mailbox key should operate on one mailbox. Giving an agent the operator credential because it is convenient removes the isolation that the mailbox identity was meant to provide.
Store mailbox credentials in local tool state or an approved secret manager. Do not put them in system prompts, repository instructions, public issue logs, URLs, or analytics payloads. Rotation should be possible without renaming the mailbox or changing every unrelated agent.
- Create separate credentials for development, staging, and production.
- Return bounded mailbox results instead of the credential to the model.
- Record scope and owner next to the secret metadata.
- Test revocation before relying on the mailbox in production.
Promote after a completed value event, not after installation
Installing a package or creating a temporary address shows curiosity. It does not show that email belongs in the product workflow. A stronger promotion signal is the first expected message received and the external task completed, such as a verified test account or a confirmed invitation.
When the same identity must receive later replies, the team can choose a permanent hosted claim or a self-hosted domain. The decision should name an owner, retention period, sending policy, abuse response, and shutdown procedure. Without those answers, expiry is the safer default.
-
01
Name the expected message
Define sender context, trigger, and useful extracted value.
-
02
Complete the external state change
Confirm that the code, link, or message produced the intended result.
-
03
Observe recurrence
Verify that continuity matters beyond the initial test.
-
04
Approve the durable form
Choose claim or self-hosting with an accountable owner.
Design the stop path before enabling production use
A mailbox can receive malicious content, leak a credential, exceed an intended workload, or outlive its project. Operators need a narrow stop control that does not require taking the whole email service offline. Pause the identity, rotate the key, disable sending, and preserve only the evidence needed for review.
Expiry and deletion are different. Expiry should end credential use and future access according to policy. Deletion may remove message data and attachments, which can conflict with audit or user expectations. Document each state and make destructive transitions explicit.
| Control | Use it when | Expected effect |
|---|---|---|
| Pause | Behavior is suspicious or under review | Stop mailbox operations while preserving state |
| Rotate | A scoped credential may be exposed | Replace access without changing identity |
| Disable sending | Outbound authority is no longer justified | Keep inbound access if still required |
| Expire or delete | The workflow has ended | Apply the documented retention outcome |
Sources and product scope
Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.
- mails0 source repositoryImplementation, license, and deployment source
- mails0 mailbox documentationMailbox lifecycle and claim behavior
Questions about Permissions and lifecycle
Can an agent claim a permanent mails0.com mailbox automatically?
No. The hosted service keeps permanent claims behind explicit human approval. Agents can automatically create and use provisional receive-only mailboxes.
What is the difference between an operator key and a mailbox key?
An operator key administers broader deployment resources. A mailbox key is scoped to one mailbox and should be the normal credential for an agent workflow.
Can self-hosters change the 72-hour lifetime?
Yes. The hosted 72-hour policy is a product default. A self-hosted operator controls deployment policy and must also own cleanup, abuse prevention, retention, and migration behavior.
Prove the smallest useful email loop.
Start with one scoped inbox and one expected message. Add durable identity, sending, and operational complexity only when the first loop works.