AI Control Plane · Custom domain
Custom domain
Connect a custom domain to serve MCP servers from a branded URL, with DNS verification, an optional IP allowlist, a default MCP server at the domain root, and ChatGPT app verification.
The Custom Domain page connects one domain to the organization so MCP servers are served from a branded URL instead of the platform default. Open it from Organization settings > Custom Domain in the dashboard.
Adding a custom domain requires an enterprise plan. Organizations on the base tier see a prompt to request the feature.
Access requirements
Section titled “Access requirements”Viewing the page requires the org:read scope, so both default Admin and Member roles can see it. Connecting, editing, reverifying, or deleting a domain requires the org:admin scope, held only by the Admin role by default.
Domain card
Section titled “Domain card”Each organization can link one custom domain. The card shows the domain name, a status icon indicating whether the domain is being verified, verified and active, or failed verification, and a “Linked” line with the date the domain was added. An Allowed IPs row shows either “All (no restriction)” or one badge per allowed IP address or CIDR range.
Connecting a domain
Section titled “Connecting a domain”Click Connect a Custom Domain to open a three-step dialog. Enter the domain, then create two DNS records at the domain provider. The first is a CNAME record pointing the domain at the platform. The second is a TXT record at _gram.<domain> containing a verification value. Both steps include a copy button for the required record value. An optional advanced step configures an IP allowlist before registration. Click Register (or Reverify when retrying) to submit.
Verification depends on DNS propagation, so a newly registered domain may show as being verified until the records resolve. If verification fails, click Reverify to run the check again.
How network access works for MCP
Section titled “How network access works for MCP”The IP allowlist restricts which networks can reach the branded domain. Enforcement happens at the platform’s network edge, before requests reach any MCP server: a request from an address outside the allowlist receives a 403 response and never touches the server behind it.
The restriction covers everything the custom domain serves, uniformly:
- The MCP endpoints themselves, including a default MCP server mapped to the domain root
- The OAuth authorization and token endpoints
- The OAuth discovery documents under
.well-known - The ChatGPT app verification URL
Entries are IPv4 addresses (1.2.3.4) or CIDR ranges (10.0.0.0/24); IPv6 isn’t supported. There’s no limit on the number of entries, and an empty allowlist allows all traffic. Saving the allowlist completes only after the network configuration updates, so changes enforce near-immediately.
Scope of the restriction
The allowlist protects the branded hostname only. The same MCP servers stay reachable at their default platform URLs, which the allowlist doesn’t cover — so treat it as a network perimeter for the branded domain and rely on server authentication and visibility as the primary access control.
Managing the allowlist
Section titled “Managing the allowlist”Click Edit allowlist to open the Edit IP allowlist side sheet. Each entry accepts an IPv4 address or CIDR range and is validated individually. Click + Add IP address to add entries; leave the list empty to allow all traffic.
Default MCP server
Section titled “Default MCP server”By default, MCP servers on a custom domain are served under /mcp/<slug>. The Default MCP server control routes the domain root itself to one of those servers, so clients can connect at https://your-domain.com/ with no path.
Pick any MCP endpoint attached to the domain from the dropdown; endpoints are grouped by project. Once set, the root behaves like the chosen server’s own URL: MCP clients connect and get the server directly, while browsers see the server’s installation page. Renaming the chosen server’s slug updates the routing automatically, and selecting No root mapping stops serving the root again.
The same mapping can also be set from an MCP server’s own settings page under Distribute. Changing the mapping requires the org:admin scope.
ChatGPT app verification
Section titled “ChatGPT app verification”Submitting an app built on one of the domain’s MCP servers to OpenAI’s ChatGPT app directory requires proving ownership of the domain. OpenAI’s app-submission flow issues a verification token and then fetches it from a well-known URL on the domain:
https://your-domain.com/.well-known/openai-apps-challengePaste the token into the ChatGPT app verification field and click Save; the domain serves it at that URL immediately, and OpenAI’s verifier can complete the check. The card shows the exact verification URL with a copy button. Click Clear to stop serving the token once verification is done; it can stay in place harmlessly, since the token is public by design.
Tokens are a single line of up to 256 characters. Saving or clearing the token requires the org:admin scope.
IP allowlists can block verification
The IP allowlist applies to the verification URL too. If the allowlist is enabled, OpenAI’s verifier is likely to be blocked and verification will fail. Temporarily clear the allowlist while verifying, then restore it.
Deleting a domain
Section titled “Deleting a domain”Deleting the custom domain opens a confirmation that lists the MCP endpoints that will be deactivated. Traffic to those branded URLs stops once the domain is removed.