Before You Start

This guide covers how to connect a domain you have already registered to your website, without taking your email offline. It is written for whoever is managing the technical side of a launch, typically a Digital Manager, or a Communications Director comfortable following step-by-step instructions.

What you need before starting:

  • A registered domain (see Domain Registration for Charities and Nonprofits if you have not done this yet)
  • Access to wherever the domain's DNS is managed, directly or through a named invitation
  • A website on a plan that allows a custom domain

Check the plan first. Some website builders only publish to a custom domain on a paid plan, and trying to add a domain before upgrading is a common reason this stalls. The organisation should pay for that plan in its own account: hosting billed through a supplier is a dependency it cannot unwind on its own if the relationship ends.

What it does not cover: the exact screens in your host's dashboard, which change often and are best taken from the host's own documentation. On Webflow, that is its guides to connecting a custom domain manually and connecting a Cloudflare domain.

What DNS Actually Is

DNS stands for Domain Name System. It translates a human-readable name, yourcharity.org.uk, into the address computers use to find a server. When you connect a domain to a website, you are updating its records to say: when someone looks up yourcharity.org.uk, send them here.

Three types of record are usually involved:

  • A record. Points a domain at an IP address. It is normally used for the root domain, the version without www.
  • CNAME record. Points a domain at another domain name. It is normally used for the www version.
  • TXT record. Holds a string of text. Many hosts use one to confirm that you control the domain.

Your host may ask for something different. Enter what it shows you. Both versions of your address need to work and land in the same place, because visitors will try each.

Step 1: Find Out Which System Answers for Your Domain

Your DNS may not be managed where you bought the domain, often because a previous supplier moved it. Changes made in the wrong place have no effect at all, and look exactly like a propagation delay.

Run the ICANN Lookup for a generic extension or Nominet's lookup for .uk, and read the nameservers. They name the system that answers for the domain. A domain registered with Cloudflare Registrar always uses Cloudflare's nameservers, so its records are edited there.

Step 2: Get the Values From Your Host

Add the domain in your host's dashboard, both the www and the root versions if it asks for them, and keep the screen with the DNS values open.

Copy the values from that screen rather than from any guide. They change, and they can differ: Webflow says so plainly, and some of its sites need more than one A record.

If your site is hosted on Cloudflare, the work is smaller. When you add a custom domain to the hosting project, Cloudflare creates the DNS record and issues the certificate for you. It will refuse a hostname that already has a CNAME record, so export your record list and remove the old one first. Then skip to Step 5.

Step 3: Get Access Without Sharing a Password

If a developer or consultant is doing this for you, invite them under their own name. Nobody needs your login, and you can withdraw the access when the work is done. That is a governance point as much as a security one: this account decides whether the organisation still controls its own address, and it should never sit only in a supplier's inbox.

  • On Cloudflare, a Super Administrator invites them as a member and gives them a DNS role. Cloudflare can limit a member to specific domains, but its documentation does not say which plans include that, so assume the free plan does not and keep only your organisation's domains in the account.
  • In GoDaddy, use Delegate Access. Read the access levels on screen, because GoDaddy renames them from time to time.
  • Elsewhere, ask your registrar for its equivalent, and ask what the invited person can reach: some grant access to every domain in the account.

Be careful with automated connect flows. Some hosts offer a button that writes the records for you. Webflow's own documentation warns that its quick connect flow can overwrite existing MX, SPF and other records. If the charity's staff email runs on this domain, that is a real risk for a little saved work, and I would enter the records by hand.

Step 4: Update the DNS Records

Before you change anything, export or screenshot the existing record list. If something breaks, that list is how you put it back.

On Cloudflare, records are on the DNS Records page, under Add record. Other registrars have an equivalent screen, usually called DNS or Manage DNS.

  • Root domain (A record). Edit the existing record whose Host or Name shows @, or add one. @ means the root domain. Set the value to what your host shows, and add every A record it lists.
  • www (CNAME record). Edit the existing record whose Host or Name shows www, or add one. Set the value to what your host shows.
  • Verification (TXT record). Add a new record with the name your host gives. Paste the value rather than typing it: a single clipped character means the domain never verifies.

The proxy setting, if you are on Cloudflare

Each A and CNAME record on Cloudflare has a proxy status. Proxied puts Cloudflare between your visitors and your host. DNS only just answers with the address.

Cloudflare recommends proxying web traffic, but your host's instruction wins. Webflow, for example, says to set its records to DNS only on standard hosting, and warns that the proxy can cause a 525 Handshake Error. If your host says nothing, ask it before launch day.

Leave the email records alone

Do not touch MX, SPF, DKIM or DMARC records. They deliver and authenticate the organisation's email and have nothing to do with where the website is hosted. The launch-day disaster to fear is not a website that failed to appear; it is a mailbox that stopped receiving, discovered hours later.

Existing web records

If the domain pointed at a previous site, update its A and CNAME records rather than adding new ones alongside them. Two A records for the root domain pointing to different places cause conflicts. Delete any other A or CNAME records for the root domain and www that are not the ones you have just set.

Step 5: Wait for Propagation

Once the records are saved, the update spreads across DNS servers worldwide. There is no way to speed it up. Webflow's guidance is typical: a few hours in most cases, and up to 48 hours in all locations. TXT records are often the slowest, which is why a domain sometimes resolves correctly while the host still reports it unverified.

During propagation some visitors may see the old site and some the new one. Plan the switch for a quiet period to minimise this.

To check progress, use a propagation checker such as dnschecker.org or whatsmydns.net. Enter your domain, choose the record type, and see whether servers in different locations have picked up the new value.

Step 6: Verify, and Choose One Main Address

Once the records have spread, use your host's check or verify control. It reads the records itself and reports whether the domain is connected.

Choose which version is the main address, following your host's recommendation if it makes one. The other should redirect to it rather than serving the site twice at two addresses, which splits your search signal and confuses anyone linking to you.

Step 7: Confirm HTTPS

Most hosts issue a certificate on their own once the domain is verified. Until that completes, visitors may see a security warning, which resolves itself.

One exception. If your domain has CAA records, which name the certificate authorities allowed to issue for your domain, they must include the ones your host uses, or certificates may fail to issue or renew. Most charity domains have none. If yours does, Let's Encrypt's CAA documentation explains the mechanism, and your host's documentation names the authorities it needs.

Common Problems and How to Fix Them

The domain still shows as unverified

Check the records again. The usual causes:

  • You edited DNS somewhere that does not answer for the domain (Step 1)
  • The root record's Host field is set to the full domain name instead of @
  • The TXT record is missing, or was typed rather than pasted
  • A conflicting record from the previous host is still there
  • The site is on a plan that does not allow a custom domain

One version of the address loads and the other does not

One of the two records is misconfigured or has not spread yet. Check both with a propagation checker. Whichever version is not resolving has a problem with its own record.

A 525 error after moving to Cloudflare

Check the proxy setting on the web records and what your host says about it. See "The proxy setting" above.

The site worked for years and now will not publish

Your host may have changed its requirements. Webflow moved its hosting and retired its old values, and since 13 January 2026 a custom domain still pointing at them cannot be published to: the site stays up, but changes do not go out. Compare your records with what your host's dashboard shows today.

A security warning after the domain connects

The certificate is still being issued. Check again later. If it persists for several hours while your host shows the domain as connected, check for CAA records, then contact your host's support.

The old site still appears

Check in a private window, because your browser may be holding the old site. If a private window shows it too, use a propagation checker for your region.

A Note for Communications Directors

If you are not the person configuring DNS but need to understand what is happening, here is the short version.

Before launch, someone updates settings at the company that manages your domain, to tell the internet where your website now lives. It is quick to configure and can take a while to take effect everywhere. Done properly it does not touch your email. Done carelessly it can.

Two things are worth your attention, and neither is technical.

The first is access. Make sure someone at the organisation can get into that account, and use a named invitation rather than passing a password around. If you are unsure who owns the domain or how to get into the account, resolve that well before launch day rather than on the morning you intend to go live. A domain that only a former supplier can reach is not really the charity's domain.

The second is that this is not a one-off. Platforms change their DNS requirements: Webflow changed its own, and since January 2026 sites that did not follow cannot publish. Someone needs to be accountable for noticing that, which is the difference between a site that is hosted and a site that is looked after.

On Webflow? The platform-specific steps are in Platform Notes.

Next Step

Once the domain is connected, confirm the padlock is doing its job: SSL and HTTPS: What Your Charity Needs to Check. If this domain replaces an old site, your next job after that is keeping its old links alive with 301 redirects.

Related resources: