Can an AI agent have its own email address?

An email address for an agent is two things: somewhere mail can reach it, and a From line it can send under. There are three common ways to get both, and they differ mostly in whose identity the agent uses and who can take it away.

What are the ways to give an agent an address?

1. A person's mailbox, through OAuth. The agent signs in to someone's Gmail or Outlook account and reads and sends as them.
2. An inbox-per-agent product. A service creates mailboxes through an API, one or more per agent.
3. An address on your own domain. You point a subdomain's MX record at a service that receives mail and calls your webhook, and the agent sends through that service's API from the same domain.

When does a person's mailbox make sense?

For an assistant that works for one person and writes as them: drafting replies, sorting the inbox, sending the follow-up they asked for. It has the person's whole context, replies come back to the person, and there is nothing to set up in DNS.

The costs come from the same fact. Every message goes out under that person's name, and recipients can't tell the agent from the human. The agent can read whatever its grant allows, and anyone who emails that person writes into its context. Reading Gmail through its API needs restricted scopes such as gmail.readonly or gmail.modify; Google requires restricted-scope verification for apps that use them, and a security assessment if the app stores or transmits that data on its servers (Gmail API scopes). Revoking is up to the person, in their account settings, and if they leave the company the agent's identity leaves with their mailbox.

What are inbox-per-agent products good at?

They make a mailbox a thing an agent can create with one API call. Each agent gets its own address and a real inbox it can list, search and thread, and some add IMAP and SMTP access, webhooks and an MCP server. That suits an agent that runs its own correspondence over days or weeks and needs a mailbox to come back to, or a system that creates many isolated inboxes on the fly.

The trade-offs are practical ones. It is another vendor beside the one that sends your product's mail, and the agent's address may sit on the vendor's domain unless you bring your own. Check whether the same product also fits your receipts and newsletters; if not, you run two. Email APIs for AI agents compares them.

How does an address on your own domain work?

You publish an MX record on a subdomain such as reply.yourdomain.com. Every message sent to any address there is received, stored and posted to your webhook, and the agent replies through the same provider's send API, from the same domain. The agent can be support@reply.yourdomain.com while your team's mailboxes stay on the root domain.

What you take on is the handler: verifying the webhook, fetching the message, deciding what the agent may do. There is no mailbox to open in a mail client.

How do the options compare?

• Identity. A personal mailbox writes as a person. An inbox product writes as the agent, on its domain or yours. Your own domain writes as your brand, under your DMARC policy.
• Deliverability. On your own domain, its reputation is yours to keep, and a subdomain keeps agent mail apart from your product's other mail (separate your sending domains).
• Revocation. A person removes the app from their account. With an inbox product you delete the inbox or revoke its key. On your own domain you revoke the agent's API key, or turn receiving off.
• Prompt injection. Every option lets strangers write into the agent's context. A personal mailbox exposes the most, because the agent sees all of that person's mail. On your own domain your code fetches one message at a time and can check its DMARC verdict first (how to protect an AI email agent from prompt injection).
• Replies. They land with the person, in the agent's inbox, or on your webhook and in a shared inbox your team can read.

How do you set it up with Unitpost?

1. Verify a subdomain for sending. Receiving can only be turned on for a verified domain; anything else answers 409.
2. Turn receiving on in the domain's Receiving tab, or with PATCH /email/domains/{id} and { "capabilities": { "receiving": "enabled" } } (MCP email_domains_update).
3. Publish the MX record the API returns as receiving.record. It is live when receiving.status is verified. Our MX must have the lowest priority number on its name, which is why it belongs on a subdomain: on a root domain that runs Google Workspace or Microsoft 365 it would take mail away from those inboxes.
4. Subscribe a webhook to email.received. The event carries metadata only: sender, recipients, subject, message_id and attachment descriptors. Verify the svix-signature header and dedupe on event_id or data.email_id.
5. Fetch the message with GET /email/received/{id} (emails:read). It returns the text and html bodies, reply_to, thread_id and the SPF, DKIM and DMARC verdicts.
6. Reply in the thread. Send with POST /email, or the MCP tool email_send, and set in_reply_to to the inbound id. Unitpost reads the stored Message-ID and References chain, fills the In-Reply-To and References headers, and adds Re: to the subject when it's missing. Headers you set yourself win.

Use an idempotency key built from the inbound id, so one message gets one reply even when a worker retries. How to have an AI agent reply to inbound email walks through the handler with code.

Receiving is catch-all, so support@, billing@ and reply+4821@ all arrive with no setup per address. Route on the to field to split work between agents. There is no IMAP or POP, and no separate mailbox per address.

Who owns the replies?

When the customer answers, the reply comes back to the same subdomain as another email.received, with the same thread_id. Your code decides what happens next: the agent answers, up to a cap per thread, or a person takes over.

A person can always take over. Every received message is in the dashboard inbox under Emails, Received, threaded with what you sent, and a teammate can reply from there from the same domain and thread. Hand off when the sender's DMARC doesn't pass, when they ask for a person, or when the thread is about money or anything legal.

Two things to filter before the agent sees a message: auto-replies, and copies of your own sends that come back to the receiving domain. Answering either is how two machines start mailing each other.