Give an AI agent its own email address: what it takes, what goes wrong
Give an AI agent its own address on your domain, not your inbox login: a scoped key, a sender allowlist and human approval. Here is what breaks without them.
On this page(10 sections)
- What is an agent mailbox?
- Why not just connect the agent to your own inbox?
- What does it take to set one up?
- What does the agent's key actually allow?
- What can go wrong?
- Who sends the email: the agent or a person?
- A first-week checklist
- What about testing sign-up emails?
- Choosing between a shared domain and your own
- Bottom line
The safest way to give an AI agent email is to give it its own address on your domain, not a login to a person's inbox. The agent gets one mailbox, a key that reaches only that mailbox, a list of senders it will listen to, and a human who approves what it sends. The rest of this post covers what that takes and what goes wrong when you skip a step.
What is an agent mailbox?
An agent mailbox is a real email address that belongs to an agent or a workflow instead of a person, such as [email protected]. The agent reads and writes through an API or an MCP client, and your team can open the same conversation in the normal inbox.
That second part matters. If the address lives in a separate agent-only service, a person who wants to step in has to go and find the thread somewhere else. In Koltrix, agent mailboxes sit next to your team's mailboxes on a domain you have already verified, so people and agents share one thread.
Why not just connect the agent to your own inbox?
Because the agent then inherits everything you can do. OWASP's LLM06:2025 entry on Excessive Agency names three root causes of agent incidents: excessive functionality, excessive permissions and excessive autonomy. A shared personal login has all three: it can read every thread, it can send as you, and nothing stops it.
A dedicated address fixes the first two by construction. The agent only ever sees the mail sent to its own address, and anything it sends comes from that address, so a reply from support-agent@ never pretends to be a founder. Our earlier posts on least privilege for AI email agents and which tasks are safe to delegate go deeper on the policy side.
What does it take to set one up?
You need four things, and none of them is exotic.
| Step | What you do | Why it matters |
|---|---|---|
| 1. A verified domain | Use a domain you have already verified, with SPF, DKIM and DMARC in place | Mail from the agent authenticates like any other mail from you |
| 2. A mailbox for the agent | Create the agent mailbox in the app, which counts against your plan | One purpose per address keeps the blast radius small |
| 3. A scoped key | Create an API key for that mailbox only | A leaked key reaches one mailbox, not the workspace |
| 4. A sender allowlist | Name the people or domains the agent should hear from | Strangers cannot hand the agent instructions |
Koltrix limits agent mailboxes by plan: the free trial allows 1, and paid plans allow 3, 10 or 25 depending on the plan. An agent mailbox is also an address, so it counts against your address limit too.
On the domain step, authentication is not optional for the agent either. Google's email sender guidelines say all senders need SPF or DKIM, and bulk senders (5,000 or more messages a day to Gmail) need SPF, DKIM and DMARC. An agent will rarely be a bulk sender, but a domain with all three in place is the safe default. If you are not sure yours is, start with SPF, DKIM and DMARC in plain English.
What does the agent's key actually allow?
In Koltrix the key created for an agent mailbox can call only that mailbox's routes in the API. Everything else in the public API answers with a refusal, and a different mailbox id answers as if it does not exist. The key can be revoked without touching the mailbox, and changes to the agent, its keys and its settings are written to an audit log that owners and admins can read.
Compare that with protecting email API keys, where the general advice is to scope and rotate. A mailbox-scoped key makes the scoping automatic rather than something you have to remember.
What can go wrong?
Most failures come from a handful of causes. Here they are with the control that addresses each.
| What goes wrong | How it happens | Control |
|---|---|---|
| The agent obeys a stranger | A message contains instructions and the model treats them as orders | Sender allowlist, plus an injection scan with a quarantine mode |
| The agent sends something wrong | A bad guess goes out as a real email | A person approves each send |
| A key leaks | It ends up in a repo, a log or a chat | Mailbox-scoped key, easy revocation |
| Nobody knows what the agent did | No record | Audit log and an Activity feed of drafts, proposals and held mail |
| Quiet runaway | The agent keeps working while you are not looking | One workspace kill switch puts every agent back to drafting |
The first row deserves attention. OWASP LLM01 on prompt injection says plainly that no foolproof prevention method is known, and lists mitigations: least privilege, labeling untrusted content, filtering, and human approval for high-risk actions. We cover how these attacks look in prompt injection in email.
In Koltrix, every inbound message is scanned when it arrives, with fast rules first and an AI check second, and gets a risk level of none, low or high with reasons. What an agent reads is wrapped as untrusted data. For each agent mailbox you pick off, flag or quarantine, and quarantine is the default: a high-risk message is withheld from the agent and shown to a person with a warning. The sender allowlist only counts mail that passed DMARC, so a spoofed "boss@" does not get through. None of this is perfect, which is why the next section matters.
Who sends the email: the agent or a person?
Today, a person. Each agent mailbox has an autonomy setting, and two levels are live.
-
Suggest is the default. The agent writes drafts and proposals, and a person reads and sends them. The agent has no way to send.
-
Approve lets the agent propose a send, which then waits in your Action center. You approve it, edit then approve, or reject it. Pending approvals expire after 7 days.
-
Auto (Beta) lets an agent reply on its own when it is sure. It is off by default for every agent, and it sends alone only when it is highly confident and can point to what its answer is based on, to allowlisted recipients it already knows, inside a daily cap, with every send logged. Anything that fails a rule waits for your approval.
The practical advice is the same as for any new hire: start on Suggest, read what the agent drafts for a couple of weeks, then consider Approve, and only then consider Auto for a narrow job.
A first-week checklist
- Pick one narrow job, such as triaging the first email to a support address.
- Create one agent mailbox for it on a verified domain.
- Create a key for that mailbox and store it in your secret manager, not in the prompt.
- Add the senders the agent should hear from, even if that is only your own domain at first.
- Leave the injection mode on quarantine and the autonomy on Suggest.
- Check the Action center and the audit log every day for the first week.
- Revoke and recreate the key if it is ever pasted somewhere it should not be.
If you would rather not build the instructions yourself, Koltrix also ships five recipes (support triager, invoice collector, lead qualifier, meeting scheduler and follow-up chaser) that create the mailbox and rules in one click, set to Suggest.
What about testing sign-up emails?
An agent mailbox can also receive the verification email your own product sends. The wait_for_email call, over the API or MCP, waits up to 60 seconds for a matching message and returns it with the one-time code or magic link. It works only on agent mailboxes, never on your team's mail, which makes it a safer way to automate sign-up tests than pointing a script at a real inbox.
Choosing between a shared domain and your own
Some agent-email services give you an address on a shared domain with no setup. At the time of writing, AgentMail's documentation says its default addresses are on a domain shared with all its users, including the sending reputation, and that custom domains need a paid plan. A shared domain is fine for a prototype. For anything customers will read, an address on your own domain keeps your reputation yours and looks like you. Koltrix agent mailboxes always live on a domain you have verified.
Bottom line
Give the agent an address, not your inbox. One mailbox per job, a key that reaches only that mailbox, a sender allowlist, an injection scan set to quarantine, and a human approving sends covers the real risks, and you can loosen the settings later as the agent earns trust. You can read how it works on the agent mailboxes page and the injection shield page.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
