{"slug": "trial-domains-vs-custom-domains-for-agent-accounts", "title": "Trial Domains vs Custom Domains for Agent Accounts", "summary": "Nylas introduced trial domains for its Agent Accounts beta, allowing developers to create and test mailboxes without DNS configuration. Trial domains under *.nylas.email enable instant mailbox provisioning, while custom domains require MX and TXT records for production use. The two-tier model lets teams prototype quickly and migrate to branded domains before launch.", "body_md": "A team I'll generalize from experience: they spend a sprint planning their AI agent's email integration, then stall for a week because nobody can get a DNS change through the infrastructure review queue. The agent code was done. The mailbox didn't exist yet, because the mailbox needed a domain, and the domain needed MX records, and the MX records needed a ticket.\n\nThis is exactly the gap trial domains exist to close. With [Nylas Agent Accounts](https://developer.nylas.com/docs/v3/agent-accounts/provisioning/) (currently in beta), every mailbox lives on a domain — and you get two very different ways to supply one.\n\n| Strategy | Address format | Setup | When to use |\n|---|---|---|---|\nTrial domain |\n`alias@<your-application>.nylas.email` |\nNone — register from the Dashboard | Prototyping, local testing, demos |\nYour own domain |\n`alias@yourdomain.com` |\nMX and TXT records at your DNS provider | Production, customer-facing agents, branded mail |\n\nBoth produce identical mailboxes from the API's perspective: same `grant_id`\n\n, same Messages and Events endpoints, same `message.created`\n\nwebhooks. The difference is entirely about who controls the domain and what the address says about you.\n\nTrial subdomains under `*.nylas.email`\n\nare provided per application. Register one from the Dashboard and you can create accounts on it immediately — no DNS provider, no infra ticket, no waiting on propagation:\n\n```\nnylas agent account create test@your-application.nylas.email\n```\n\nOr through the API with `POST /v3/connect/custom`\n\nand `\"provider\": \"nylas\"`\n\n— no refresh token, just the address:\n\n```\ncurl --request POST \\\n  --url \"https://api.us.nylas.com/v3/connect/custom\" \\\n  --header \"Authorization: Bearer $NYLAS_API_KEY\" \\\n  --header \"Content-Type: application/json\" \\\n  --data '{\n    \"provider\": \"nylas\",\n    \"settings\": { \"email\": \"test@your-application.nylas.email\" }\n  }'\n```\n\nThe quickstart goes from nothing to a sending-and-receiving mailbox in under 5 minutes, and the trial domain is the reason that number is honest. Verification emails arrive, webhooks fire, calendars RSVP. Everything works.\n\nAnd it's genuinely testable end to end. Send a message to the new address from your personal account, then list the inbox:\n\n```\ncurl --request GET \\\n  --url \"https://api.us.nylas.com/v3/grants/<GRANT_ID>/messages?limit=5\" \\\n  --header \"Authorization: Bearer $NYLAS_API_KEY\"\n```\n\nIf you've registered a `message.created`\n\nwebhook, the notification lands as soon as the mail does — same payload shape as any other grant. The full receive-and-respond loop you'll run in production is exercisable on day one, on a domain you didn't have to configure.\n\nWhat a trial domain *isn't* is a brand. `test@your-application.nylas.email`\n\nscreams \"automated system\" to every recipient, and you don't own the reputation story for a shared infrastructure domain. For an internal prototype, who cares. For a sales agent emailing prospects, it matters a lot.\n\nRegistering your own domain means publishing the MX record (routes inbound mail) and TXT records (prove ownership, configure SPF/DKIM for outbound) that the platform generates for you. Once they propagate, verification is automatic — the status flips to `verified`\n\nand the domain can host accounts. You register a domain once per organization, picking the US or EU data-center region, then create as many accounts under it as your plan allows.\n\nIn exchange for that setup you get:\n\n`assistant@yourcompany.com`\n\nreads like a colleague, not a test rig.`agents.yourcompany.com`\n\nso agent traffic can't dent your primary marketing domain.`sales-a`\n\nand `sales-b`\n\nsubdomains, or `agents.staging.yourcompany.com`\n\nkeeping test traffic off production.Here's what makes the two-tier model work in practice: you don't choose once. You can mix both strategies in one application, and the documented pattern is to prototype on `*.nylas.email`\n\nand move to a custom domain before launch.\n\n\"Move\" is lighter than it sounds. Agent Accounts are created per address, so migrating means registering the custom domain, waiting for verification, and provisioning new accounts on it — your application code is unchanged because everything keys off `grant_id`\n\n, not the address. Start the DNS registration *early* (it's the only step with real wall-clock wait), and build the whole agent against a trial-domain mailbox in parallel. By the time the domain verifies, you swap in a production grant ID and you're done.\n\nWorth being precise here, because \"trial\" suggests a degraded product and that's not what this is:\n\n`*.nylas.email`\n\nor your own domain. Moving to a custom domain doesn't raise quotas; upgrading your plan does.One wrinkle worth planning for: policies and rules attach through workspaces. Pass a `workspace_id`\n\nwhen creating the account and it inherits that workspace's send limits, spam settings, and mail rules; omit it and the account lands in your application's default workspace (or is auto-grouped into a workspace matching the email's domain when `auto_group`\n\nis enabled). Set your production workspace up before the migration so the new accounts inherit the right guardrails on day one.\n\nIf you've got an agent idea queued behind an infra ticket right now, flip the order: grab a trial domain today, build the full loop against it, and let the [provisioning guide](https://developer.nylas.com/docs/v3/agent-accounts/provisioning/) walk you through the custom-domain registration while you ship. The [quickstart](https://developer.nylas.com/docs/v3/getting-started/agent-accounts/) is the fastest on-ramp — what would your agent's production address be?", "url": "https://wpnews.pro/news/trial-domains-vs-custom-domains-for-agent-accounts", "canonical_source": "https://dev.to/qasim157/trial-domains-vs-custom-domains-for-agent-accounts-3kjh", "published_at": "2026-06-15 14:59:04+00:00", "updated_at": "2026-06-15 15:07:16.453920+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-products"], "entities": ["Nylas", "Agent Accounts", "Nylas API"], "alternates": {"html": "https://wpnews.pro/news/trial-domains-vs-custom-domains-for-agent-accounts", "markdown": "https://wpnews.pro/news/trial-domains-vs-custom-domains-for-agent-accounts.md", "text": "https://wpnews.pro/news/trial-domains-vs-custom-domains-for-agent-accounts.txt", "jsonld": "https://wpnews.pro/news/trial-domains-vs-custom-domains-for-agent-accounts.jsonld"}}