Agent email address
An agent email address is the mailbox identity an AI agent sends and receives from, issued on agents.emailforagents.ai for a live project and as a generated non-routable address for a test project.
An address is an identity, not a routing detail. Whoever owns the address owns the conversation: replies come back to it, recipients judge the sender by it, and revoking it stops exactly one participant. That is why giving an agent its own address is a different decision from giving an agent access to yours.
The format
A live inbox is created inside a live project and returns an address on
agents.emailforagents.ai:
{
"id": "ibx_...",
"address": "support-triage@agents.emailforagents.ai",
"environment": "live",
"status": "active"
}You choose the local part. Some are refused: a reserved-name list rejects
postmaster, abuse and similar with HTTP 422 reserved_address, and the rejection
happens at creation rather than at first send. Pick a name that describes the job,
because the recipient reads it before they read the message.
A test project returns something different and refuses to be customised. Passing
local_part to a test project returns HTTP 422 test_mode_unsupported, and the
generated address ends in .mail.invalid, which RFC 6761 guarantees can never
resolve. The two environments are separate projects with separate credentials, and
nothing promotes one to the other.
Custom domains are a paid-plan feature, and paid plans are not purchasable yet. Live
mail is sent and received on agents.emailforagents.ai today. What domain
verification will involve, including the DNS records and the sending_status gate a
domain has to pass before a send is accepted, is documented under
domains.
One address, one permission boundary
The address is bound to an inbox, and the inbox is what credentials are scoped to. A grant names inbox IDs, so an agent holding a grant for one address cannot read another in the same project. This is the practical reason the identity matters: the address is the unit that permissions, policy and the audit trail all attach to.
It is also the unit that receives. Mail addressed there is routed to that inbox, and the agent reads it because it is the agent’s own mail, not because a rule forwarded a copy. The step-by-step version of setting one up, from project to first reply, is how to give an AI agent an email address.
What it is not
It is not an alias on a human’s mailbox. An alias delivers into somebody else’s inbox, which means the human sees the agent’s mail, the agent’s permissions are the human’s permissions, and revoking one revokes both.
It is not a no-reply address. An agent address is expected to receive, and replies to
it thread back into the same conversation using the standard In-Reply-To and
References headers rather than a proprietary thread token. A reply that arrives is
a message received, which costs an email unit, so a chatty counterparty is a usage
question as well as a workload one.
It is not a reputation. A new address on a shared domain has no sending history, and nothing about holding an address makes a message land in an inbox. Provider acceptance is not proof of delivery, and no system can report placement. Keep volume modest at first, send mail people asked for, and treat bounces and suppressions as signals to act on rather than errors to retry.
Finally, it is not permanent by accident. Deleting the inbox releases the identity, and a conversation that was addressed there has nowhere to land afterwards. If an agent’s job ends, revoke the grant first and decide about the address separately, because the two are independent controls. How they sit together is covered on the inbox overview.