Custom Domains for Agent Accounts

What is a custom domain for an agent account?

A custom domain lets an agent account use an address on a domain you own — support@your-company.com — instead of the managed *.nylas.email address every account gets by default. The mail still flows through Nylas's managed infrastructure; the only change is the domain on the address and the DNS records that authenticate it. The agent's grant, workspace, and CLI commands stay exactly the same.

The managed domain and a custom domain are the same product with a different label on the envelope. The default address is live in under 2 seconds with zero DNS; a custom domain trades a one-time DNS setup for an address that reads as your brand. Both send DKIM-signed, authenticated mail — the difference a recipient sees is whether the sender is *.nylas.email or you.

Why use a custom domain instead of *.nylas.email?

For a customer-facing agent, the sender domain is part of the brand and the trust signal. A receipt from billing@your-company.com reads as legitimate; the same message from an unfamiliar *.nylas.email address invites a second look. When the agent talks to your customers, sending from your domain is the difference between looking official and looking like a third party.

There's a deliverability angle too. With DKIM aligned to your own domain, the agent's mail builds toward a domain-aligned reputation and passes the alignment checks that mailbox providers and DMARC evaluate — though delivery still depends on content, IP reputation, and recipient engagement. For an agent sending real volume to real customers, domain alignment is worth the DNS setup.

What DNS records does a custom domain need?

A custom domain needs the standard email-authentication records pointed at Nylas's infrastructure. Nylas generates the exact values in the dashboard; the record types are the familiar email trio plus the MX that routes inbound. Add them at your DNS provider:

DNS changes propagate on their own schedule — usually minutes, sometimes up to 24-48 hours depending on your provider's TTL. Use the values from the dashboard verbatim; a single transposed character in a DKIM record breaks verification silently. Verify propagation with a DNS lookup before you point production traffic at the domain.

How do I configure the custom domain?

Custom domain setup happens in the Nylas Dashboard, not the CLI, because it involves verifying domain ownership and generating per-domain DKIM keys. The flow is: add your domain in the dashboard, copy the generated DNS records to your provider, wait for verification, then create agent accounts on the verified domain. Once the domain is verified, the CLI treats an address on it exactly like a managed one:

# After the domain is verified in the dashboard, create the account on it
nylas agent account create support@your-company.com

Nothing about the command changes — the only difference from a managed address is the domain after the @. For the architecture behind the grant this creates, see getting started with agent accounts.

How do I send and receive on the custom domain?

Once the account exists on your domain, sending and receiving are the same commands you'd use on any agent account. Creating the account stores it as your active grant, so these commands run against it; the sender address comes from that grant, so a send goes out from your custom domain automatically — no --from flag, no relay config:

# Sends from support@your-company.com, DKIM-signed on your domain
nylas email send \
  --to customer@example.com \
  --subject "Your receipt" \
  --body "Order #4821 confirmed."

# Inbound to the custom address is read the same way
nylas email list --unread --json | jq '.[] | {from: .from[0].email, subject}'

Because the CLI surface is identical, you can develop the agent against a *.nylas.email address and switch to the custom domain at deploy time by changing only the account address. Everything else — rules, policies, webhooks, the agent code — carries over unchanged.

When should I stay on *.nylas.email?

The managed domain is the right default for anything that isn't customer-facing. Prototypes, internal tools, test automation, and agent-to-agent communication never need your brand on the envelope, and the *.nylas.email address skips the DNS setup entirely — an account is live in under 2 seconds.

Reserve the custom domain for the moment the agent starts talking to your customers, where the sender domain is part of the product. A common pattern is both: managed addresses for internal and test agents, a custom domain for the customer-facing ones. The decision is per-account, so you don't commit the whole application to either. For where agent accounts fit among email options, see Best Email Infrastructure for AI Agents.

Next steps

• Getting Started with Agent Accounts — the architecture the custom domain plugs into
• Build a Transactional Email Agent — customer-facing receipts where a custom domain matters most
• Check Email Deliverability — verify SPF, DKIM, and DMARC before a customer send
• Migrate from SMTP to Agent Accounts — configure the custom domain before the cutover so the address is right from day one
• Best Email Infrastructure for AI Agents — when managed vs custom domain is the right call
• Full command reference — every nylas agent account flag and subcommand
• Nylas v3 API documentation — domains, grants, and the send API