Skip to content

DOMAINS & DNS

Move a Domain to Cloudflare

Use this procedure whenever a domain's DNS needs to come under NetWise's Cloudflare management — for an existing NetWise client's domain, or for a domain arriving from elsewhere.

Registration, DNS management and the website itself can each move to NetWise independently of one another. Establish which of these actually apply before you start (see Step 2), rather than assuming all three are happening together.

1. Establish the domain's current state

Work out, for the domain as it stands today:

  • who controls registration, and with which registrar;
  • the current nameservers;
  • the current DNS records — website, MX, SPF, DKIM, DMARC, subdomains, redirects, verification records, and any Microsoft 365, Google or other third-party services — taken from a copy supplied by the existing registrar (see below);
  • where the website currently lives, and where it's moving to (if it's moving);
  • the current email provider and mail routing.

Get a copy of the DNS from the existing registrar

Ask the client to get a full copy of the domain's DNS records from their existing registrar, ideally an export of the whole zone. If NetWise is already the registrar, take the copy from the current zone instead. Get it before the domain moves or its nameservers change.

Important

Don't rely on Cloudflare's scan, or on what public DNS lookups reveal, to find the records. DKIM records live at selector-specific names that a scan or lookup can't reliably discover, and these are the records most often missed.

You can still inspect the domain's current public DNS as a cross-check, and reconcile it against the copy. If they disagree, find out why before going further.

The goal is to find everything that depends on this domain before you touch it, not just where the website points.

2. Decide what's actually transferring

Registration, DNS management and website hosting are separate operations, even when they're all happening for the same client at the same time.

Confirm explicitly:

  • is domain registration transferring to NetWise, staying where it is, or not applicable (already NetWise's)?
  • is DNS management moving to NetWise/Cloudflare?
  • is the website also moving to NetWise hosting?

A domain doesn't need its registration to move to NetWise for NetWise to manage its DNS through Cloudflare.

3. Prepare the website, if it's moving

Where the website is also moving to NetWise hosting, get it working correctly on the new hosting before DNS cutover.

Check that the origin serves HTTPS correctly and that the site behaves as expected when reached directly, before Cloudflare is put in front of it. Confirming this by editing your local hosts file to point the domain at the new origin is one common way to do this, though it isn't the only way — use whatever method reliably tests the real origin.

4. Add the domain to Cloudflare and build the DNS zone

Add the domain to Cloudflare, and when it offers the choice, import the DNS records from the copy you obtained in Step 1. Don't let Cloudflare scan for them.

Important

Reconcile the imported zone against the copy from Step 1, record by record, to check that everything came across.

Don't delete a record just because it doesn't look related to the website — investigate it first. It may serve mail, a subdomain, or a third-party integration you haven't identified yet.

Email authentication records (MX, SPF, DKIM, DMARC)

Cloudflare's own scan often misses DKIM records, which is why the zone is built from the registrar's copy rather than a scan. They live at selector-specific names such as selector._domainkey.example.com, which a generic scan can't reliably discover.

A DKIM record missing from the registrar's copy is still not evidence that the domain has no DKIM. Before nameserver cutover, check the domain's intended MX, SPF, DKIM and DMARC configuration against the mail provider as well.

Where FlexMail is the client's mail provider, establish the DKIM record FlexMail requires directly, rather than relying on Cloudflare discovery to surface it.

Set proxy status deliberately for each record:

  • normal web records can be proxied where appropriate;
  • mail and any other service that can't operate through Cloudflare's HTTP proxy must stay DNS-only.

Where the website is hosted on NetWise infrastructure, Full (strict) is the standard SSL/TLS mode for a correctly configured origin.

Note

NetWise's Cloudflare security baseline is handled by a scheduled daily auditor. It can add missing canonical rules when it discovers a genuinely new zone; established zones are audited for drift but are not automatically changed. The baseline therefore doesn't need to be recreated manually as part of normal domain onboarding.

5. Change nameserver delegation

Once the intended DNS state is built and checked, change delegation through the correct route for this domain.

Important

Don't change nameserver delegation until you've established enough about what depends on the existing DNS zone to migrate it safely — see Step 1.

.gov.uk domains

NetWise is an authorised Nominet registrar.

Domains registered through Enom

New Enom registrations and transfers-in are raised through the Domains tab on the client's account in WHMCS (separate from Products), selecting whether it's a registration or a transfer.

For a domain already registered through Enom, nameserver changes are also made through WHMCS, not by logging into Enom directly.

Domains with an external registrar

Where registration stays with an external registrar, change nameserver delegation directly with that registrar. Registration doesn't need to transfer to NetWise for NetWise to manage the domain's DNS through Cloudflare.

6. Verify the migration

A nameserver change alone doesn't mean the migration is complete. A working website is not evidence that the mail DNS migration is complete — the two are independent and must be verified separately.

Check, based on what Step 1 identified as depending on this domain:

  • nameserver delegation and Cloudflare authority for the zone;
  • the domain's email authentication records — MX, SPF, DKIM and DMARC — against the configuration established in Step 4, not just whatever Cloudflare's import carried across;
  • other DNS records that matter for this domain — website, subdomains and third-party services;
  • origin HTTPS and public HTTPS;
  • any redirects that should still work.

Actual email send/receive testing is occasionally worth doing where the pre-migration audit flagged something specific to check, but it isn't a mandatory step for every migration.

← Domains & DNS · Wiki home