How to Connect a Custom Domain to Substack Without Breaking Your Newsletter

To connect a purchased domain to Substack safely, register the intended subdomain in your publication’s Domain settings, copy the CNAME values Substack supplies, and add that record at the active DNS provider. Verify the new hostname before updating public links, and handle the bare domain with a separate permanent redirect.

This changes the newsletter’s public web address without moving its email delivery to your domain. Keep the original publication-specific settings URL available during setup, avoid altering unrelated DNS records, and remember that newsletters will still be sent from a substack.com address.

1. Preserve a recovery path before editing DNS

Record the publication’s existing address, normally in the form publicationname.substack.com. Also save its direct settings URL: publicationname.substack.com/publish/settings. This route can restore access to the publication dashboard if the custom hostname is not yet working.

Confirm where the domain’s authoritative DNS is managed. The registrar that sold you the domain may not control its records if the nameservers point to a web host, DNS service, or security provider. Make the change only in the service named by the active nameservers.

Save a copy of the current zone before editing it. Preserve all MX, TXT, DKIM, DMARC, verification, and unrelated subdomain records; the Substack connection concerns only the selected publication hostname and, if needed, a separate root-domain redirect.

• Confirm that the domain registration is active.
• Confirm that you can edit its authoritative DNS zone.
• Choose a hostname such as www.example.com or newsletter.example.com.
• Save the original Substack settings URL.
• Record the existing value of every DNS entry you intend to replace.

2. Register the hostname in Substack first

Open the publication dashboard, select Settings, choose Domain, and select Add custom domain. Enter the complete hostname readers will use, including the subdomain—for example, www.example.com, not only example.com.

Substack’s official custom-domain instructions, updated April 29, 2026, specify a one-time $50 USD fee, restrict setup to the publication owner or a group administrator, and require the domain to be added in Substack before its CNAME is created. The instructions also require a subdomain, allow up to 36 hours for configuration, recommend a 301 redirect from the root domain, and state that newsletters continue to use a substack.com sender address.

Copy the Name and Target displayed in your own dashboard. Do not borrow a target from another publication or an older tutorial: the dashboard values are the ones assigned to your configuration. Keep that page open while editing DNS so you can compare both fields exactly.

3. Map the CNAME to your provider’s fields

DNS interfaces use different labels for the same CNAME components. Substack’s Name may appear as Host, Hostname, Alias, or Subdomain. Its Target may be labelled Value, Destination, Points to, or Canonical name.

• Type: CNAME
• Name or Host: the selected label, such as www or newsletter, unless the interface explicitly requests the full hostname
• Target or Value: the complete destination shown by Substack
• TTL: the provider’s default or automatic value

As a conditional example, a provider that automatically appends example.com will usually expect www in the Host field. Entering www.example.com there could produce the unintended name www.example.com.example.com. An interface that asks for a fully qualified domain name may instead require the complete hostname.

A CNAME cannot share its hostname with an A, AAAA, or another CNAME record. If www already points to an old website, record its current value and replace that conflicting entry; do not delete records belonging to other hostnames. If your DNS service can proxy traffic, disable that proxy for the publication hostname during validation so the CNAME answer remains directly visible.

4. Treat the custom domain as an address change

A TechRadar review of Substack confirms that the domain must be purchased separately and connected through DNS, while describing the platform’s design customization as limited compared with fuller website-building systems.

This distinction sets the right expectations. The custom hostname provides a branded route to the publication, but Substack still operates the publishing, subscriber, payment, and email-delivery systems. If you need extensive templates, application hosting, or server-level control, the DNS change does not add those capabilities.

It also does not create a mailbox such as [email protected]. If you want a branded inbox for replies or business correspondence, purchase or configure email hosting separately. Do not disturb the domain’s MX and email-authentication records while adding the publication CNAME.

5. Redirect the root domain separately

The publication must use a subdomain such as www.example.com. To make example.com reach the same publication, configure an HTTP permanent redirect from the root domain to the complete HTTPS subdomain address.

The redirect and CNAME perform different jobs. The CNAME makes the publication hostname resolve to Substack; the redirect answers a browser request for the bare domain and sends it to that hostname. Depending on the provider, the relevant feature may be called URL forwarding, domain forwarding, or redirect rules.

Use a standard permanent redirect instead of masked forwarding. Where the forwarding service supports it, preserve paths and query strings so a request for a specific root-domain page reaches the corresponding publication URL. If the DNS provider cannot serve HTTP redirects, the root domain needs a redirect-capable host or edge service; DNS records alone do not perform browser redirects.

If the root domain already hosts a company website, store, or portfolio, leave it in place. Connect Substack at a dedicated hostname such as newsletter.example.com rather than sending the entire root domain to the publication.

6. Verify DNS before announcing the address

Save the CNAME, return to the Domain settings, and select Check status. An immediate failure is not conclusive because recursive DNS resolvers may retain an earlier answer or a cached record indicating that the hostname did not exist.

Inspect the public result from a terminal by replacing the example hostname in one of these commands:

• dig +short CNAME www.example.com
• nslookup -type=CNAME www.example.com
• host -t CNAME www.example.com

The response should contain the Target supplied for your publication. A trailing dot in DNS output is normal. If a regular lookup is empty or stale, identify the authoritative nameserver and query it directly with dig @nameserver.example CNAME www.example.com. A correct authoritative answer alongside an old recursive answer points to caching; an incorrect authoritative answer means the active DNS configuration still needs attention.

After the status changes to ready, test the custom address in a private browser window and, if practical, through another network. Open the homepage, an existing post, the archive, and the subscription flow. Then request the root domain and confirm that it redirects to the intended HTTPS subdomain.

7. Recover from missing settings or failed validation

If Domain is absent from Settings, first confirm that you are viewing a publication dashboard rather than a reader profile or general account page. Check your publication role as well, because contributors with narrower permissions cannot perform an owner-level domain change.

A Substack community troubleshooting thread documents the same missing-menu confusion and suggests opening the publication-specific settings path. The thread is anecdotal, so use it as a navigation clue rather than evidence of a platform-wide dashboard problem.

If dashboard navigation fails after the DNS edit, log in and open the saved publicationname.substack.com/publish/settings address directly. Avoid making repeated speculative changes while caches update; each edit makes it harder to determine which version a resolver is returning.

When validation still fails after the documented configuration window, compare the hostname and Target character by character. Check for a missing subdomain, a duplicated domain suffix, a conflicting record, changes made at an inactive DNS provider, an intervening traffic proxy, or whitespace copied into a field.

8. Launch with a reversible configuration

Make the final switch during a quiet publishing period. Wait for confirmation and complete the DNS, browser, redirect, and subscription checks before updating profile links, media kits, sponsor documents, or scheduled campaign URLs.

1. Record the verified CNAME and root redirect settings.
2. Confirm that the custom hostname and original Substack settings route both work.
3. Test a low-risk post before a time-sensitive send.
4. Watch for certificate, redirect-loop, or unreachable-host reports.
5. Retain the pre-change DNS record until the publication has completed a normal send cycle.

If the custom hostname fails, restore the recorded value for that hostname or remove the custom-domain configuration through the options shown in the publication dashboard. Leave unrelated mail and verification records untouched. Because cached answers may temporarily differ, confirm the rollback through both an authoritative DNS query and a normal browser lookup.

The setup is ready for promotion when the selected subdomain returns the assigned destination, the root-domain behavior matches your plan, the publication and subscription flow open correctly, and you can still reach the original settings route. The newsletter’s web address is then branded, while its expected Substack sender identity remains unchanged.

Also read:

• Garmin Cirqa Smart Band Launches Without a Screen or Required Subscription
• Substack Now Lets Readers Check If a Newsletter Was Written by AI
• Substack Adds Pangram AI Detection to Posts, Notes, and Comments