{"slug": "dns-for-agent-mailboxes-mx-and-txt-records-explained", "title": "DNS for Agent Mailboxes: MX and TXT Records Explained", "summary": "Nylas explains how to configure MX and TXT DNS records for custom domains used by AI agent mailboxes. The MX record routes inbound mail to Nylas's hosted infrastructure, while TXT records verify domain ownership and enable email authentication. Nylas recommends using a dedicated subdomain to avoid disrupting existing company email.", "body_md": "You've created an agent mailbox at `agent@yourcompany.com`\n\n, the dashboard says the domain isn't verified, and your DNS provider is showing you a form with record types you haven't touched since you set up Google Workspace. Two records stand between you and a working inbox: an MX record and some TXT records. Here's what each one actually does.\n\nQuick context first: [Nylas Agent Accounts](https://developer.nylas.com/docs/v3/agent-accounts/provisioning/) (currently in beta) are hosted mailboxes for AI agents, and every account lives on a domain. A shared `*.nylas.email`\n\ntrial domain needs zero DNS work; your own domain needs records published before it can host accounts. This post is about the second path.\n\nMX (Mail Exchange) records are how the rest of the internet finds your mailboxes. When someone emails `agent@yourcompany.com`\n\n, their mail server looks up the MX record for `yourcompany.com`\n\nand delivers to whatever host it names. No MX pointing at the mailbox provider, no inbound mail — outbound might work, but replies vanish.\n\nWhen you register a domain in the Dashboard (or [through the API](https://developer.nylas.com/docs/v3/email/domains/)), Nylas generates the exact MX record you need to publish at your DNS provider. It routes inbound mail for that domain to the hosted inbound infrastructure, where it's processed and delivered to the right agent's inbox.\n\nThis is also why the docs push hard on one piece of advice: **use a dedicated subdomain**. If you point `yourcompany.com`\n\n's MX at the agent infrastructure, you've rerouted your *entire company's* email. Point `agents.yourcompany.com`\n\ninstead:\n\n```\n# What your DNS zone ends up looking like (illustrative)\nyourcompany.com.         MX  →  your existing mail host (unchanged)\nagents.yourcompany.com.  MX  →  the Nylas-generated mail host\n```\n\nYour team's mail keeps flowing where it always did; only addresses under the subdomain route to agent mailboxes.\n\nTXT records are free-form DNS entries that other systems read for verification and policy. For a custom agent domain they do two jobs, per the [provisioning docs](https://developer.nylas.com/docs/v3/agent-accounts/provisioning/):\n\nSo the MX record is about *receiving*, and the TXT records are about *trust* — proving you own the domain and telling the world your agents' outbound mail is legitimate.\n\nThe flow has exactly three steps:\n\n`verified`\n\non its own, and the domain can host accounts.Propagation is the only genuinely unpredictable part. DNS changes can be visible in minutes or take longer depending on your provider and TTLs, so if verification hasn't flipped immediately, give it time before assuming you've mistyped a record.\n\nWith the domain verified, account creation is trivial. From the CLI:\n\n```\nnylas agent account create agent@agents.yourcompany.com\nnylas agent account list\nnylas agent status   # confirm the connector is ready\n```\n\nOr one API call to `POST /v3/connect/custom`\n\nwith `\"provider\": \"nylas\"`\n\nand the email address — no OAuth, no refresh token. The response is worth seeing once, because it's the whole handoff:\n\n```\n{\n  \"request_id\": \"5967ca40-a2d8-4ee0-a0e0-6f18ace39a90\",\n  \"data\": {\n    \"id\": \"b1c2d3e4-5678-4abc-9def-0123456789ab\",\n    \"provider\": \"nylas\",\n    \"grant_status\": \"valid\",\n    \"email\": \"agent@agents.yourcompany.com\",\n    \"scope\": [],\n    \"created_at\": 1742932766\n  }\n}\n```\n\n`data.id`\n\nis the `grant_id`\n\nyou'll use for every message and event on that mailbox, and `grant_status`\n\nis already `valid`\n\n— no pending state, no confirmation email.\n\nBoth are optional, and both are easier to set now than to retrofit:\n\n`workspace_id`\n\n`settings`\n\nentry) places the account in a specific workspace, so it inherits that workspace's policy limits, spam settings, and rules from its first second of existence. Omit it and the account is auto-grouped into a workspace whose `domain`\n\nmatches the address (when `auto_group`\n\nis enabled) or lands in the application's default workspace. You can move it later with `PATCH /v3/grants/{grant_id}`\n\n.`app_password`\n\nOne domain registration also scales further than you might expect: a single application can manage accounts across any number of registered domains. The docs describe teams using that for per-customer domains, sender-reputation isolation (splitting volume across `sales-a.yourcompany.com`\n\nand `sales-b.yourcompany.com`\n\n), and keeping staging traffic on `agents.staging.yourcompany.com`\n\naway from production.\n\n**Can I mix trial and custom domains in one application?** Yes — many teams prototype on the zero-DNS `alias@<your-application>.nylas.email`\n\ntrial domain and register the custom domain in parallel, moving agents over before launch. Same application, same code, only the address changes.\n\n**Do I re-register the domain for every environment?** No — registration is once per Nylas organization, and after that you create as many Agent Accounts under the domain as your plan allows. For environment separation, the docs recommend separate subdomains (`agents.staging.yourcompany.com`\n\nnext to `agents.yourcompany.com`\n\n) rather than separate registrations of the same name.\n\nIf you just want to see the records in action, register a domain, publish the two record types, and send a test email to the new address from your phone — then list the mailbox via `GET /v3/grants/{grant_id}/messages`\n\nand watch it arrive. Stuck on a verification that won't flip? Drop your DNS provider in the comments; propagation quirks tend to cluster by provider.", "url": "https://wpnews.pro/news/dns-for-agent-mailboxes-mx-and-txt-records-explained", "canonical_source": "https://dev.to/qasim157/dns-for-agent-mailboxes-mx-and-txt-records-explained-2e31", "published_at": "2026-06-15 14:58:59+00:00", "updated_at": "2026-06-15 15:07:21.257206+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents"], "entities": ["Nylas", "Google Workspace", "DNS"], "alternates": {"html": "https://wpnews.pro/news/dns-for-agent-mailboxes-mx-and-txt-records-explained", "markdown": "https://wpnews.pro/news/dns-for-agent-mailboxes-mx-and-txt-records-explained.md", "text": "https://wpnews.pro/news/dns-for-agent-mailboxes-mx-and-txt-records-explained.txt", "jsonld": "https://wpnews.pro/news/dns-for-agent-mailboxes-mx-and-txt-records-explained.jsonld"}}