How to give an AI agent an email address
An address is the one identity the rest of the internet already knows how to talk to. Here is why an agent needs its own, what the options cost you, and how to get a working one.
The short version: an AI agent needs an email address of its own because email is the last universal identifier — every service on the internet will send to one, and almost none will send to an API endpoint. Give the agent a real mailbox it controls, not a borrowed seat in a human's inbox, and not a send-only relay that can talk but never listen.
Why an agent needs its own address
Three things break without one, and they break in ways that are hard to work around.
It can't sign up for anything
This is the wall most people hit first. An agent asked to research a tool, file an expense or book a service needs to create an account, and creating an account means receiving a verification code. Without a mailbox the agent stops dead at the first confirmation email — and disposable-address services are widely blocked by exactly the sites worth signing up for.
Nobody can reply to it
An agent that only sends is a broadcaster, not a correspondent. Real work — a support request, a scheduling back-and-forth, a supplier question — is a thread. Threads need an address that accepts mail, keeps it, and lets the agent read what came back. A webhook that fires once and forgets is not a mailbox.
Its actions aren't attributable
If the agent works out of a person's inbox, every message it sends is from that person, and every message they receive is readable by it. Separating the agent onto its own address gives you an audit trail, a blast radius you can reason about, and a credential you can revoke without locking a human out of their own mail.
The options, and what each one costs
Four approaches people actually try. All of them work in some situation; three of them fail in ways that only show up later.
The human's inbox, over Gmail or IMAP
Free and immediate for a single agent, and genuinely fine for an internal tool on a Workspace account. It stops being fine at scale. The Gmail API wants a cloud project, an OAuth consent screen and scope configuration before the agent reads one message; unverified apps are capped at roughly 100 users and show a warning screen; and the mailbox scopes are restricted, so shipping externally means OAuth app verification and an annual third-party CASA security assessment — weeks of calendar time and real money, renewed yearly. Raw IMAP skips the paperwork but hands you connection management, MIME parsing and someone else's deliverability. The problem underneath both is blast radius: the agent can read everything.
A transactional send API
Excellent at the thing they are built for. If the agent's job is 95% sending, a transactional provider is the right answer and we would tell you to use one. The catch is that receiving is usually a different shape of product — a webhook you must host, sometimes a plan tier above the free one, sometimes with retention measured in weeks — so the agent gets a payload pushed at it rather than a mailbox it can go and read. That distinction stops mattering the moment the agent needs to look back at what arrived last Tuesday.
A disposable or temporary address
Free, instant, no key required, and exactly right for catching one verification code in a test suite. Do not build a product on it. The inboxes are commonly public or shared, so anything sent there is readable; the domains are widely blocklisted by the services you most want to sign up for; there is no sending, no reputation and no persistence. It is a testing tool that looks like infrastructure.
Run your own mail server
Complete control, no per-message cost, and an ongoing operational commitment most teams underestimate. You are now responsible for spam filtering, TLS, blocklist monitoring, bounce handling, IP warm-up and the reputation of every agent you host. Worth it if mail is your product. An expensive detour if mail is a feature of your agent.
A working address, in one POST
This is the Mailgi path. No signup form, no OAuth flow, no human reading a code — the program registers itself and gets a real, deliverable mailbox.
Register
One unauthenticated POST returns an address and an API key. The key is shown exactly once, so store it before the process exits. The address is a readable handle rather than a UUID, because humans have to be willing to write to it.
Pass no label and you still get an address; pass one and it shows up in your dashboard so you can tell your agents apart later.
# Register — no auth, no signup form
curl -X POST https://api.mailgi.xyz/v1/agents/register \
-H "Content-Type: application/json" \
-d '{"label":"research-agent"}'
# => {
# "emailAddress": "buzzing-falcon@mailgi.xyz",
# "aliasAddress": "x7k3mwf2qr5b@mailgi.xyz",
# "apiKey": "amb_..." # shown once — store it
# }
Receive, and read
Mail from any sender lands in the inbox and is readable over the API seconds later. List messages, then fetch one by id for the full body as JSON — no MIME parsing on your side.
Poll, or register a webhook. Polling is the simpler option and fine for most work — fast for a verification code, slowly for a support inbox. If you already run a public HTTPS endpoint, POST /v1/webhook-endpoints gets you told instead. There is no WebSocket, and no search: page through the list and match messages yourself.
# Wait for a verification code to arrive
for i in $(seq 1 20); do
BODY=$(curl -s https://api.mailgi.xyz/v1/mail \
-H "Authorization: Bearer $KEY")
echo "$BODY" | grep -q "verify" && break
sleep 3
done
# Fetch one message in full
curl -s https://api.mailgi.xyz/v1/mail/<id> \
-H "Authorization: Bearer $KEY"
Send
Plain text or HTML, to one recipient or several, from the address you just registered. Replies come back to the same mailbox.
Give it a few seconds after registering before the first send. The mailbox is provisioned asynchronously and sending in the same breath can fail while that finishes — retry once and it goes through.
# Let provisioning settle, then send
sleep 3
curl -X POST https://api.mailgi.xyz/v1/mail/send \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{
"to": ["alice@example.com"],
"subject": "Following up",
"textBody": "Hello from an agent."
}'
# => { "messageId": "..." }
What actually makes mail arrive
Three DNS records decide whether a stranger's mail server trusts you. They get name-dropped constantly and explained rarely, so — briefly.
Who may send
A DNS record listing the servers allowed to send mail for your domain. A receiving server checks the connecting server against that list. It answers "is this machine allowed to claim your name?"
Proof it wasn't altered
A cryptographic signature added to each message, verifiable against a public key you publish in DNS. It proves the message really came from your domain and wasn't tampered with on the way.
What to do on failure
A policy record saying how a receiving server should treat mail that fails the other two — ignore, quarantine, or reject — and where to send reports. Without it, failures are handled at each recipient's discretion.
Skip them and mail from a new domain goes to spam or is refused outright. On a shared @mailgi.xyz handle this is already done for you. On your own domain, Mailgi generates the full record set and verifies each one as you publish it — you still have to put them in DNS, because nobody else can write to your zone.
Moving to your own domain
A handle like buzzing-falcon@mailgi.xyz is fine for a prototype and wrong for a customer-facing agent. The upgrade path keeps the same API.
Attach the domain
A human does this part, once, in the dashboard — it needs a signed-in session, not an API key. Publish the TXT and MX records shown, and inbound mail starts arriving.
Publish the outbound records
Once inbound verifies, the DKIM, MAIL FROM and DMARC records appear, generated for you. Sending stays disabled until they verify — a deliberate gate, so an unauthenticated domain can't damage its own reputation on the first send.
Hand agents a registration token
Create a token in the dashboard and give it to an agent. It self-registers the address you tell it to claim — support@yourdomain.com — with the same POST as before, plus domainToken and localPart. One token can mint a whole team.
Questions, answered
01Can an AI agent receive a verification code by email?
Yes, if the agent has a real mailbox rather than a send-only API. Register an address, trigger the signup, then poll GET /v1/mail until the message arrives and read the code out of the body. This is the most common reason an agent needs an address of its own: most services won't accept a disposable domain, and an agent borrowing a human's inbox can read everything else in it.
02Why not just use the Gmail API on a human's account?
It works for one agent and one account, but it doesn't scale and it isn't free to operate. You need a Google Cloud project, an OAuth consent screen and scope configuration before the agent reads a single message. Unverified apps are capped at roughly 100 users and show a warning screen. Most Gmail scopes are restricted, so production requires OAuth app verification and an annual third-party CASA security assessment. The deeper problem is blast radius — an agent with mailbox access can read the human's entire correspondence.
03Does an agent's email need DKIM, SPF and DMARC?
To send to strangers, yes. SPF says which servers may send for your domain, DKIM signs each message so it can't be forged in transit, and DMARC tells receiving servers what to do when the first two fail. Without them, mail from a new domain lands in spam or is rejected outright. On a shared platform domain this is already handled; on your own domain Mailgi generates the records and you publish them.
04How does an agent know when new mail arrives?
Two ways. Poll GET /v1/mail on an interval suited to the task — every few seconds for a verification code, every minute or two for a support inbox. Or register a webhook with POST /v1/webhook-endpoints and we'll POST you a notification carrying sender, subject and a preview, signed so you can verify it came from us. Webhooks are only worth it if you already run a public HTTPS endpoint; polling is less work and no worse for most tasks. There's still no WebSocket.
05Do I need my own domain to give an agent an email address?
No. Registering with no arguments gives the agent an address on the shared @mailgi.xyz domain, which is a fully deliverable mailbox and free. Your own domain matters when an agent writes to customers — partly because people trust a company address, mostly because your sending reputation is then yours alone rather than shared with every other agent on the platform.
06Can one agent have more than one address?
Every agent gets two automatically — a readable handle and a deterministic alias, both delivering to the same inbox. Beyond that, an agent is one mailbox: for more addresses, register more agents. Registration is a single unauthenticated call with no quota, so one agent per role or per task is a normal, cheap pattern.
07Can an agent delete its own email address?
Yes — DELETE /v1/agents/me revokes every key and removes the mailbox. It's permanent and it burns the address: a deleted local part can never be registered again, by anyone, and there's no support path to reverse it. Don't use it to "reset" — register a second agent and stop using the first.
Still deciding which one to use?
We wrote an honest comparison of the alternatives — including the cases where you should pick something other than us.