How to Put Your AI Agent on Your Company's Domain

If you've been playing with Atomic Mail Agentic, you've probably registered an agent on @atomicmail.ai and moved on with your life. Free, fast, proof-of-work signup, no captchas — it's a great way to get an agent reading and sending real email in under a minute.

But at some point the shared domain stops being enough. Maybe you're running a support bot and [e-mail] looks a lot more trustworthy in a customer's inbox than [e-mail]. Maybe you're coordinating multiple agents and want each one addressable under your own namespace — billing@, research@, outreach@ — instead of a pile of random usernames on someone else's domain. Maybe deliverability just matters and you don't want your agent's reputation tied to everyone else's.

That's what custom domains are for — and worth being precise about what it is and isn't. Atomic Mail doesn't sell or register domains for you. You keep your domain wherever you bought it. What Atomic Mail gives you is a way to point that domain's mail at their infrastructure, so an inbox living on it — and any agent using that inbox — sends and receives as [e-mail] instead of [e-mail]. The agent stops looking like a third-party tool bolted onto your stack and starts looking like it's on your team, because as far as the recipient's inbox is concerned, it is.

The setup is small enough to walk through in one sitting.

What you're actually doing
Atomic Mail speaks JMAP under the hood — a JSON-based email protocol over HTTPS, not the SMTP/IMAP stack you're used to fighting with. The nice side effect: the client code doesn't care what domain your mailbox lives on. Point an inbox at your own domain instead of atomicmail.ai, and every tool, preset, and JMAP call you already wrote keeps working unchanged.

So the work isn't in your agent's code. It's three things happening outside it:

Prove you own the domain
Point mail routing at Atomic Mail
Create an inbox on that domain and grab its API key

1. Verify domain ownership In the Atomic Mail dashboard, add your domain and you'll get a TXT record to drop into your DNS.

TXT  _atomicmail-verify.yourcompany.com   atomicmail-verify=xxxxxxxxxxxx

DNS propagation is the only real wait in this whole process — could be minutes, could be an hour depending on your registrar's TTL. Once it resolves, the dashboard flips the domain to verified.

1. Point MX records at Atomic Mail Verification proves ownership; MX records tell the internet where to actually deliver mail for that domain.

MX  yourcompany.com   10 mx.atomicmail.ai

Exact values will be in your dashboard once the domain is verified — copy those rather than guessing, since routing specifics can change.

If yourcompany.com already has mail flowing somewhere else, don't repoint the whole domain — use a subdomain instead (agents.yourcompany.com), so your existing mail server keeps its MX records untouched and Atomic Mail only owns the subdomain.

1. Create the inbox
   Once MX resolves, create an inbox on the verified domain from the dashboard — [e-mail], [e-mail], whatever fits. Open the inbox's Connect dialog and pull the API key from there.

2. Point your agent at it
   This is the part that doesn't change. Same MCP server, same AgentSkill CLI, same raw JMAP calls — you're just authenticating as a different address.

MCP config:

{
  "mcpServers": {
    "atomicmail": {
      "command": "npx",
      "args": ["-y", "@atomicmail/mcp-github"]
    }
  }
}

AgentSkill CLI, if you're running a shell-capable agent instead:

npx --package=@atomicmail/agent-skill-github atomicmail register --username "support" --api-key "$YOUR_KEY"
npx --package=@atomicmail/agent-skill-github atomicmail jmap_request --ops-file list_inbox.json

Drop the API key from step 3 into your credentials, and every preset — send_mail, list_inbox, reply — works exactly the same as it did on the shared domain. The domain change is invisible past the auth layer.

A couple of things worth knowing before you commit to this
Store the key like a secret. It lives in ~/.atomicmail/credentials.json with 0600 permissions by default — don't loosen that, and don't check it into a repo.
Only install from the @atomicmail npm scope. Same rule as any package that touches credentials — verify the source before you npx it.
Inbound mail is untrusted input. If your agent auto-replies or acts on anything in an incoming email, treat the email body the way you'd treat any other untrusted text hitting an LLM — it can contain instructions aimed at your agent, not you.
One domain, many agents. You don't need a new domain per agent. Verify yourcompany.com once, then create as many inboxes on it as you have agents — billing@, support@, outreach@ — each with its own API key and its own reputation.
Why bother
A shared domain is fine for prototyping. But the moment an agent is sending mail a human is going to read and trust — a support reply, an outreach message, an invoice confirmation — the address it comes from is part of the message. [e-mail] reads as your company. [e-mail] reads as a bot nobody vetted. Same JMAP calls either way; different inbox on the other end of them.

A few situations where that difference actually shows up:

Customer-facing support. An agent replying from [e-mail] is answering as your company. The same reply from atomicmail.ai reads like it got routed through a third-party tool — which, technically, it did, but the customer doesn't need to know that.
Outreach and cold email. Recipients (and their spam filters) trust a domain with history behind it. Sending outreach from a domain you've owned for years beats a fresh shared domain that thousands of other agents are also sending from.
Internal multi-agent systems. When you've got several agents doing different jobs — one triaging tickets, one drafting invoices, one watching a research inbox — giving each one its own address under your domain (triage@, billing@, research@) makes the whole system legible. You can tell at a glance which agent sent what, without a shared inbox full of unrelated usernames.
Domain reputation you actually control. On a shared domain, your agent's deliverability is tied to the behavior of every other agent registered there. On your own domain, it's tied to your own sending history — which you can manage.
None of this requires buying anything from Atomic Mail beyond the inbox itself — the domain stays yours, registered wherever you already registered it. Atomic Mail just becomes where its mail gets processed.

If you're already deep enough into Atomic Mail Agentic to have a registered agent, the domain setup is maybe fifteen minutes of DNS plus a dashboard click. Worth doing before you put an agent's name on anything that leaves your inbox.