Custom Domains for Thousands of Agent Inboxes

Give your AI agents domains you own, decide which agents share a domain and which get their own workspace, and run agent inboxes without reputation bleeding across tenants — on Mermail.

Why domains matter for agent fleets

Every email you send is judged partly by the domain it comes from. Gmail and Outlook keep a reputation score for each sending domain. When mail from that domain gets marked as spam, everything else sent from it starts landing in spam too.

With one agent, that is easy to manage. With dozens, it is not. A sales agent sending cold emails and a billing agent sending receipts should not share a reputation. If you sell agents to your own customers, one customer's mistakes should not sink another's.

Shared @mermail.app addresses are fine for prototypes. Production agents need domains you control, so each mailbox can send and receive as you@mail.yourcompany.com.

Plan fit (live pricing)

Custom domains are available on Developer and above. Free is for trying one mailbox -- no custom domains. Each workspace supports one custom domain.

Requirements before you start

Follow the custom domains guide. You need:

• A Developer, Growth, or Enterprise workspace (custom domains are not on Free)
• Workspace admin access -- other members can view setup but cannot add, check, or remove a domain
• Permission to edit DNS records for the domain
• A dedicated subdomain such as mail.example.com. Mermail does not accept a domain that already receives email, so a subdomain keeps company mail untouched.

Add and verify a domain

On the Mermail home page, open Custom Domains for the selected workspace. The flow has three steps.

1. Choose your domain

Enter the domain or subdomain that should appear after @ and click Check domain. Mermail confirms it is valid, not already used by another workspace, and does not already have MX records. If the apex already receives email, Mermail suggests a subdomain such as mail.example.com.

2. Add DNS records

Mermail lists every record to publish. Create each one exactly as shown (type, name, value, and MX priority). Copy from the console -- do not invent SPF, DKIM, or MX values.

3. Verify the connection

Click Check connection. Mermail re-checks every record and updates status. DNS can take a few minutes or longer depending on TTL. The domain is ready when both Sending ready and Receiving ready appear.

Sending means the records used to sign and send mail are verified. Receiving means the MX record used to receive mail is verified. If only sending is ready, add the pending MX record and check again.

What happens to your mailboxes

When the domain is ready, every mailbox in the workspace moves to the custom domain and keeps its username -- so support@mermail.app becomes support@mail.example.com. Existing mail stays in place. New mailboxes are also created on the custom domain.

Create mailboxes on the verified domain

Wait until status is ready, then create a mailbox in the console, via the API, or with MCP tools such as add_email_domain, verify_email_domain, and create_mailbox (custom domains need Developer+).

# Conceptual Mermail flow (console, API, or MCP)
# 1) add_email_domain -> publish DNS Mermail returns -> verify_email_domain
# 2) Wait until Sending ready + Receiving ready
# 3) create_mailbox on that workspace (username stays; domain switches)
# Pass an idempotency key on create; list mailboxes before blind retries

Isolate tenants with workspaces

Mermail's multi-tenant boundary is the workspace. Each workspace owns mailboxes, members, one custom domain, billing, and usage. Put each customer in its own workspace with scoped API keys so reads and credentials cannot cross tenants.

Be precise about what that buys you. A workspace separates data and credentials. Reputation still lives on the domain. Because each workspace has its own custom domain slot, giving each customer (or each risk profile) its own workspace and domain keeps deliverability from being each other's problem.

Improve deliverability

Once SPF and DKIM records from Mermail are verified, Mermail signs outbound mail. Mermail does not create a DMARC record for you -- add a TXT at _dmarc. Start relaxed (p=none), then tighten to quarantine and later reject as you gain confidence.

A new domain has no sending reputation. Warm it up: about 150 emails on day one, roughly double each day, and keep bounce and complaint rates low.

Remove a domain

Only one custom domain is supported per workspace. To switch domains, remove the current one first. After removal, every mailbox switches back to @mermail.app (or a numbered variant if the exact address is taken). Stored mail stays intact. Reusing the domain later means adding and verifying from scratch.

Fleet checklist

1. Upgrade to Developer+ if you are still on Free
2. As workspace admin, add a dedicated subdomain that does not already receive email
3. Publish every DNS record Mermail returns (DNS-only CNAMEs), then Verify until Sending + Receiving are ready
4. Create mailboxes (console, API, or MCP create_mailbox)
5. Split workspaces per tenant when you sell agent email as a product

Wiring agents through MCP first? Start with How to Use MCP with Mermail's Email API.

FAQ

Which plans include custom domains?

Custom domains on Developer+. Free has none. Growth and Enterprise include them too -- see mermail.app/pricing.

Can I use my company's main sending domain?

You can try, but think first. Mermail rejects a domain that already has email (MX). Most teams add a dedicated subdomain so the agent builds its own history without replacing existing company mail.

What if a domain never finishes verifying?

Check records one at a time. Common causes: a proxied CNAME, a hostname with the domain doubled, a TXT value that does not match, or wrong MX priority. Fix the record, wait for DNS, then Check connection again.

What happens to inboxes if I remove the domain?

Addresses switch back to @mermail.app. Stored mail remains readable. Remove a domain only after nothing depends on those addresses.

References

• Custom domains — connect a subdomain, DNS records, Sending/Receiving ready
• Workspaces — multi-tenant boundary (one custom domain per workspace)
• Mailboxes — agent inboxes on your verified domain
• Create a mailbox — console, API, or MCP after the domain is ready
• Pricing — custom domains on Developer and above