Name.com

Webflow hosts the site, but the domain itself lives at a registrar, and Webflow only reaches it through DNS records set wherever that domain's DNS is managed. That split is where launches go wrong. Get a record value wrong and the site fails to publish; overwrite the wrong record and the company's email goes down with it.

Name.com is where a lot of those domains sit. Connecting one to a Webflow site means adding three records in Name.com's DNS panel: an A record for the root domain, a CNAME for www, and a TXT record Webflow uses to verify ownership. For teams holding domains at volume, Name.com's Core API and Webflow's Data API do the same work from a script, and Name.com now ships an MCP server so an agent can run domain and DNS operations under your credentials.

Freelancers launching one site do this once, in two dashboards, and agencies holding client portfolios at Name.com repeat the same three records on every launch. Platform teams handing each customer their own domain go further and drive registration, DNS, and publishing from code.

How to integrate Name.com with Webflow

What is Name.com? Name.com is an ICANN-accredited domain registrar and part of Identity Digital, founded in 2003. Alongside registration it handles DNS management, domain transfers, email services, and a REST API for programmatic domain operations.

Teams pair the two platforms when their domains sit at Name.com and their sites run on Webflow hosting. The connection happens at the DNS layer, or through each platform's REST API. Name.com publishes no Webflow app and no pre-built automation connector, so you wire up either path yourself.

Two approaches exist. Adding the Webflow DNS records at Name.com points the domain at Webflow hosting without writing any code, and it covers almost every site. Building with the Webflow and Name.com APIs gives you programmatic control over registration, DNS records, and publishing, and it earns its server-side development cost only once you manage domains at volume.

Add the Webflow DNS records at Name.com

Manual entry is the method for Name.com domains, because its DNS panel has no Webflow template. You need a paid Site plan on the Webflow site and Name.com's default nameservers active on the domain. Read the record values from Site settings rather than from any tutorial, including this one: the TXT value is specific to your site.

To set up the integration:

1. In Site settings > Publishing > Production, click Add a custom domain and choose the manual option. Copy the A, CNAME, and TXT values shown.
2. At Name.com, go to MY DOMAINS, click the domain, and open Manage DNS Records.
3. Add an A record. Leave Host blank, set Answer to 198.202.211.1, keep TTL at 300, and click Add Record. Webflow uses a single A record, so do not add a second one.
4. Add a CNAME record with www as Host and cdn.webflow.com as Answer.
5. Add a TXT record with _webflow as Host and the site-specific value beginning one-time-verification= as Answer.
6. Back in Site settings, click Verify domain.
7. Once verified, click Publish > Publish to selected domains.

A few things block or break the connection:

• Legacy record values no longer publish: Domains still pointing at proxy-ssl.webflow.com, 75.2.70.75, or 99.83.190.102 were blocked on January 13, 2026. Those values are retired, not a second supported option (migration guide).
• Existing MX records have to survive the edit: Webflow hosts the site, not the mail, so every MX record stays exactly as the mail provider set it. Clearing the zone or replacing records wholesale while adding the A record takes email offline.
• Extra A records on the root conflict: Remove any other root A record, including the wildcard * record Name.com's own guide suggests for generic hosting (troubleshooting guide).
• The root needs an A record, not a CNAME: Name.com does not allow a CNAME on the bare domain, which is why www gets the CNAME and the root gets the A record (DNS record types).
• Records apply only on Name.com's nameservers: Delegate DNS to a third-party host and the Webflow records belong at that provider instead, where Name.com's panel no longer has any effect.
• Keep www as the default domain unless you have deliberately configured the root as default. Switching the default without matching DNS can produce a redirect loop.

Publishing is what actually applies the connection, so republish once the records verify.

Connect a subdomain

A subdomain such as blog.yourdomain.com can point at its own Webflow site while the root serves something else. That takes a CNAME record plus a _webflow TXT record for verification.

To connect a subdomain manually:

1. At Name.com, open Manage DNS Records and add a CNAME with the subdomain label, for example blog, as Host and cdn.webflow.com as Answer (CNAME guide).
2. Add a TXT record with _webflow as Host and the verification value shown in Site settings as Answer.
3. In Site settings > Publishing > Production, add the subdomain, verify it, and publish.

Webflow also offers Quick connect, which writes these records for you through Entri, but only for registrars on Entri's supported-provider list. Start that flow and check whether Name.com appears in it; if it does not, the manual steps above are the path.

Build with the Webflow and Name.com APIs

Both platforms expose REST APIs, so registration, DNS records, and publishing can all run from one script. Name.com's current API is CORE v1, released in June 2025, and it authenticates with HTTP Basic Auth using an API username and token. The older v4 API still works but sunsets at an unannounced point in 2026, so build new work against CORE v1. Webflow's Data API v2 authenticates with a Bearer token, and the v1 API is deprecated. Either path needs server-side code.

What each side covers:

• Name.com Core API: Handles domain search and availability checks, registration, DNS records, transfers, email forwarding, and webhook notifications.
• Webflow Data API: Handles sites and publishing, along with Webflow CMS collections and items.
• Webflow webhooks: Fire on site events such as form_submission and site_publish, though webhooks created in the dashboard rather than the API arrive without the headers needed to validate signatures.
• Name.com MCP server: Exposes Core API operations to an agent through npx namecom-mcp@latest, with the API username and token passed as environment variables.

Generate a Webflow token under Site settings > Apps & Integrations > API access, and a Name.com token under Settings > API Tokens (token guide). Scope is worth thinking about before an agent holds either credential: a Name.com production token can register domains, delete them, and rewrite a live zone, so keep development on a sandbox token and treat the production one as a publishing credential rather than a convenience.

Check domain availability from a Webflow form

A Webflow form plus a server-side handler is enough for a live availability check, which is the core of any registration flow or reseller storefront built on Webflow. The handler takes the submitted name, queries Name.com, and returns the result to the browser.

To implement this:

1. Test against the Name.com sandbox at https://api.dev.name.com with a -test suffix on your username (testing guide). New sandbox credentials can take up to 15 minutes to activate, so confirm connectivity with GET /core/v1/hello first.
2. For an interactive result, have browser-side code post the submitted name to your handler. For asynchronous processing instead, register a webhook with POST /v2/sites/{site_id}/webhooks and set triggerType to form_submission (webhook reference).
3. In a webhook handler, validate the x-webflow-signature header against the x-webflow-timestamp, then send the submitted name to POST /core/v1/domains:checkAvailability (endpoint reference). Leave the colon in that path unencoded.
4. To register the domain the visitor chose, call POST /core/v1/domains with the domain name in the request body (quickstart).

Webflow's signature is a SHA-256 HMAC signed with either the site token secret or your OAuth app's client secret, so reject anything that fails that check before it reaches the registrar API.

Automate DNS setup and site publishing

For agencies and platforms launching many sites, record creation and publishing run from the same script once the custom domain is attached to the Webflow site. Attaching a brand new custom domain still happens in Site settings.

To implement this:

1. Create the three Webflow records with POST /core/v1/domains/{domainName}/records, passing type, host, answer, and ttl for each (create record reference).
2. Read the site's customDomains array from GET /v2/sites/{site_id} to get each domain's ID (sites reference).
3. Publish to those domains with the publish endpoint:

const site = await webflow.sites.publish("SITE_ID", {
  customDomains: ["CUSTOM_DOMAIN_ID_1", "CUSTOM_DOMAIN_ID_2"],
  publishToWebflowSubdomain: true,
});

To watch domain health afterwards, subscribe to Name.com webhook notifications with POST /core/v1/notifications. Events report transfers, expirations, and lock changes, and every request carries an X-NAMECOM-SIGNATURE header for HMAC verification (webhook overview).

What you can build with the Name.com Webflow integration

Integrating Name.com with Webflow lets every site in a portfolio run on its own domain without moving registrars or repeating manual DNS work at each launch.

The pairing supports several patterns:

• Client site launches at agency scale: Manage every client domain from one Name.com account, then use its bulk domain tools to edit nameservers or add and delete DNS records across a selection of domains at once.
• A domain search tool on your own site: Send a Webflow form entry to a handler that calls domains:checkAvailability and returns live results to the visitor. Pair it with Name.com's reseller program and the same page can sell the domain it just found.
• Custom domains for every customer of a product: A provisioning layer can check availability, register the domain, set nameservers, and hand back a working hostname during signup, which is the pattern behind most white-label domain features.
• Branded email alongside the site: Add the mail provider's MX records in the same Name.com panel that holds the site records, since Webflow hosting does not include email.

Both API paths run on the same Webflow credential that publishes the site, which means the script that connects a domain can drive the site's content too. See how to apply custom code to pages through the Data API.