An email address is the first thing a recipient reads and one of the first things a spam filter scores. For prototypes, an agent on the shared trylumbox.com domain is fine. Once an agent writes to your customers, signs up for services that matter, or holds accounts you would miss if you lost them, the address should be on a domain you own. This post is about why that is and how to lay out addresses for several agents. The DNS steps are in the custom domain setup guide.

What the recipient sees

When a Lumbox inbox sends a single message, the From header is the inbox's bare address, with no display name. The recipient's client shows support-agent@agents.yourcompany.com or k3x9-worker@trylumbox.com, and nothing else tells them who sent it. A domain they already associate with you is the only identity the message carries.

It also decides where replies go. A customer who answers a message from your domain is writing to your domain, and if you ever change how that mail is handled, the address they have saved still works. The same holds for everything the agent signed up for. Accounts are tied to their email address, and password resets go to it. If an agent registered for a service with an address on a domain you control, you can always receive that reset. On a shared domain, the address belongs to the platform's namespace, not to you.

Reputation you own

Mailbox providers judge mail partly by the sending domain's history. On a shared domain, that history is everyone's. Because that reputation is pooled, Lumbox runs extra rules on the shared domains: names like support and billing are reserved there, inbox names that look like well-known brands are refused with IMPERSONATION_BLOCKED, and new Free accounts are held to 5 sends in the first hour and 25 in the first day.

On your own verified domain those shared-domain rules do not apply. You can create support@, and the new-account ramp and the Free-plan recipient-domain check are lifted. The trade is that the reputation is now entirely yours. If an agent sends something people report as spam, it is your domain that pays, and nobody else's good behaviour cushions it.

That is the argument for putting agents on a subdomain such as agents.yourcompany.com rather than on yourcompany.com itself. The recipient still sees your company's name in the address. The subdomain gets its own MX records, so your team's mail keeps flowing where it does today, and a subdomain can carry its own DMARC policy, so you can tighten or loosen it without touching the main domain. Some mailbox providers also weigh the parent domain, so treat a subdomain as limiting the damage rather than removing it.

There is one more benefit people overlook. With DMARC published on your domain, you decide what receivers should do with mail that claims to be from your agents but is not. A shared domain's policy is set by whoever runs it.

One address per agent

Inboxes are cheap to create, so give each agent, or each job, its own. Separate inboxes mean separate histories to read, separate webhooks, and no chance that one agent consumes a verification code meant for another. Some layouts that work:

  • By role. support@, billing@, research@. Stable, readable, good for anything customer-facing.
  • By tenant. acme-onboarding@agents.yourcompany.com for an agent working on behalf of one customer. Put the tenant ID in the inbox's metadata so your code never has to parse addresses.
  • By task. A fresh inbox per sign-up or per run, deleted afterwards. These rarely need your domain unless the target service rejects unfamiliar domains, which some do.
curl -X POST https://api.lumbox.co/v1/inboxes \
  -H "X-API-Key: ak_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "acme-onboarding",
    "domain": "agents.yourcompany.com",
    "metadata": { "tenant_id": "acme", "agent": "onboarding" },
    "project_id": "proj_..."
  }'

Pick local parts a person can read. Random strings are fine for throwaway sign-up inboxes and look like spam in a customer's inbox. Remember that each inbox counts toward your plan's inbox limit, which is 3 on Free and goes up to 250 on Scale.

Keeping agents out of each other's mail

Separate addresses keep mail apart. Keeping agents apart also means not giving every agent the organization key, which can read every inbox, change domains and manage webhooks. Project keys are the mechanism for that. Create a project per agent or per tenant with POST /v1/projects, create that agent's inboxes with its project_id, and mint a key with POST /v1/projects/{id}/keys. Every inbox lookup made with that key is limited to the project's inboxes, and the key is refused on organization-level routes such as domains, webhooks, the credential vault and bulk sending. Domains, webhooks and outbound configuration stay under an organization key held by your own backend.

Several customers, several domains

If you run a product where each customer's agent should send from that customer's identity, you have two choices. Addresses per tenant on your own subdomain (acme@agents.yoursaas.com) are one DNS setup and one reputation shared across all tenants. A subdomain per customer (agent@acme.yoursaas.com) gives each tenant a separate sending history, but each one is its own domain in Lumbox, added with POST /v1/domains and verified with its own DNS records. That is real work per customer, and each new subdomain starts with no sending history. Start with the first layout and move a tenant to its own subdomain when their volume or their risk justifies it.

What the domain needs

Four kinds of DNS records, all returned by the API when you add the domain: MX records so mail for the domain reaches Lumbox, an SPF include and DKIM records so receivers can authenticate what the agents send, and a DMARC record that states your policy for mail that fails. Verification only requires the ownership TXT record, the MX and the SPF include, so check the DKIM and DMARC results too before the agent starts sending. The SPF, DKIM and DMARC post explains why DKIM is the one to get right.

A new domain has no sending history, so start the agent at low volume and raise it as replies come back without complaints. The warm-up post covers the first weeks. Custom domains are listed on the Starter plan and above on the pricing page.