Picture this: your outreach agent has a rough week — a stale prospect list, a few hundred hard bounces — and the following Monday, marketing asks why the company newsletter is suddenly landing in spam. Same domain, shared fate. The agent's deliverability problem just became everyone's deliverability problem, and untangling it takes far longer than preventing it would have.

The prevention is one DNS decision: put your agents on their own subdomain.

Why subdomain isolation works

Mail receivers score reputation per domain. Every sender on yourcompany.com — human employees, marketing tools, and your AI agents — deposits into and withdraws from the same reputation account. An autonomous agent is the riskiest depositor you have: it sends at machine speed, doesn't read the room, and a bug or a bad list can generate weeks' worth of damage in hours.

Hosting agents at agents.yourcompany.com splits the ledger. The agents build (and risk) their own reputation while your primary domain stays clean — and the provisioning docs recommend exactly this dedicated-subdomain pattern for production use. You keep the brand association people expect in an address, without the shared blast radius. There's an operational bonus too: any human can tell at a glance that scheduler@agents.yourcompany.com is automation, which is the kind of transparency that builds trust instead of eroding it.

The DNS setup

Agent Accounts (currently in beta) are hosted mailboxes, so pointing a subdomain at them is a standard domain registration. You register once per organization, picking the data center region — US or EU — where your application lives, and then create as many accounts under the domain as your plan allows. Two kinds of records do the work:

• MX routes inbound mail for the subdomain to the hosted infrastructure, so the agents can receive.
• TXT records prove you own the domain and carry the SPF/DKIM configuration that authenticates outbound mail.

The values are generated for you; you publish them at your DNS provider, and verification happens automatically once the records propagate — the domain status moves to verified and it's ready to host accounts. No certificate dance, no manual review.

From there, creating a mailbox on the subdomain is one call:

curl --request POST \
  --url "https://api.us.nylas.com/v3/connect/custom" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "provider": "nylas",
    "settings": {
      "email": "sales-agent@agents.yourcompany.com"
    }
  }'

The response includes a grant_id that drives everything else — messages, calendar, webhooks. Unlike OAuth providers, there's no refresh token involved — just an email address on a registered domain. If you live in the terminal, the CLI covers the whole lifecycle:

# Create the account (optionally with IMAP/SMTP access from the start)
nylas agent account create sales-agent@agents.yourcompany.com
nylas agent account create sales-agent@agents.yourcompany.com --app-password "MySecureP4ssword!2024"

# Inspect the fleet
nylas agent account list --json
nylas agent status

# Tear down (--yes skips the confirmation prompt)
nylas agent account delete sales-agent@agents.yourcompany.com --yes

The app_password is what lets a human connect Outlook or Apple Mail to the agent's mailbox for supervision. It must be 18–40 printable ASCII characters with at least one uppercase letter, one lowercase letter, and one digit, and it's stored as a bcrypt hash — you can reset it later, never retrieve it. Omit it and protocol-level access stays disabled, which is the right default for agents nobody needs to log into.

Let the subdomain assign policy automatically

Subdomains aren't just a reputation boundary — they can be a governance boundary. Policies and rules attach to workspaces, and a workspace can carry a domain with auto_group: true: any new Agent Account whose address matches that domain joins the workspace automatically and inherits its policy limits, spam settings, and rules.

That turns the address itself into configuration. Create a workspace for agents.yourcompany.com with your production policy, another for agents.staging.yourcompany.com with tighter limits, and every account you provision lands under the right rules without anyone remembering to pass a workspace_id. Accounts that match nothing fall into your application's default workspace — attach a baseline policy there as the catch-all.

Prototype on a trial domain first

You don't need DNS access to start. Trial subdomains under *.nylas.email register from the Dashboard with no setup at all, giving you addresses like test@your-application.nylas.email immediately — the quickstart goes from API key to a sending-and-receiving mailbox in under 5 minutes that way.

Both strategies coexist in one application, and the common arc is exactly what you'd expect: prototype on the trial domain, prove the agent's behavior, then register the production subdomain before launch. The trial domain keeps experiments off any domain you care about — isolation all the way down.

Patterns beyond one subdomain

Once you treat domain layout as an isolation tool, more structure follows naturally:

• Environment separation. agents.staging.yourcompany.com next to agents.yourcompany.com, on the same application, so load tests and integration suites never touch the production domain's reputation.
• Reputation sharding. High-volume senders split across sales-a.yourcompany.com and sales-b.yourcompany.com, so trouble on one shard doesn't contaminate the other.
• Per-customer domains. Multi-tenant products can register each customer's own domain and provision agents there — scheduling@customer-a.com — keeping every tenant's reputation in the tenant's hands. A single application manages accounts across any number of registered domains, so none of this multiplies your infrastructure.

These compose. A mature setup might run trial domains for development, a staging subdomain for CI, a production subdomain for first-party agents, and customer domains for tenant-facing ones — all one application, one API key, one code path.

Verify before you scale

Once the domain shows verified, prove the round trip before you point real traffic at it. Send a test email from any client to the new address, then list the mailbox:

curl --request GET \
  --url "https://api.us.nylas.com/v3/grants/$GRANT_ID/messages?limit=5" \
  --header "Authorization: Bearer $NYLAS_API_KEY"

If you've registered a message.created webhook, the notification should arrive within seconds of the SMTP handoff — the payload is identical in shape to message.created for any other grant, so branch on the grant's provider field ("nylas") if your handler also serves connected Gmail or Microsoft accounts. Then send a reply from the agent and confirm it lands back in your client. Three checks, and the subdomain is ready for production.

Set it up before you need it

Domain reputation is earned slowly and lost fast, which makes the subdomain decision much cheaper on day one than after an incident. The whole production setup is an afternoon: register agents.yourcompany.com, publish the MX and TXT records, wait for verification, and update one line in your provisioning script.

If your agents currently send from your primary domain, that's the move to schedule this sprint. And if you're just starting: which would your team rather explain later — a subdomain in the address, or a week of the company's mail in spam folders?