Connecting Cloudflare is a configuration change with several dependencies. Start with a record of the working InterServer setup, then verify the website and email after each meaningful change. This guide covers an existing domain using Cloudflare as its authoritative DNS provider, with practical checks before and after the nameserver switch.
Prepare access and a configuration record
Identify who controls the registrar, DNS, InterServer and Cloudflare accounts. Each service needs an owner and recovery method. Prefer individual invitations and scoped accounts where supported instead of sharing passwords.
Export the DNS zone or save a complete record list. Note the server address, nameservers, certificate details, email provider and verification records. Keep the original configuration available, including subdomains not linked from the main website.
Confirm that the origin works first
Check the main domain, www, important pages, images and contact form before enabling a proxy. Record the preferred hostname and existing redirects. Confirm that HTTPS works at the hosting side before introducing another layer.
Cloudflare cannot repair an application that already fails to save requests. Avoid combining the DNS change with a CMS upgrade, PHP migration or major release. A separate change window makes it easier to identify the cause if something stops working.
Add the domain and compare every record
Add the apex domain to Cloudflare and choose an appropriate plan. Treat automatic DNS discovery as a starting draft. Cloudflare explicitly warns that its quick scan may miss existing records.
Compare imported records against the saved zone. Check website A and AAAA records, subdomain CNAME records, mail MX records and TXT entries for SPF, DKIM, DMARC and service verification. Confirm whether an imported IPv6 address is still valid rather than keeping it automatically. Ask the responsible administrator about unfamiliar records before removing them.
Separate web proxying from mail DNS
Only A, AAAA and CNAME records used for suitable web traffic can be proxied. MX and TXT records remain DNS-only. A mail hostname used by email clients should also remain DNS-only rather than being treated as a normal web page.
Check the purpose of each CNAME before changing its proxy status. Domain verification and third-party services may require DNS-only resolution. An orange icon is not a universal success indicator; the correct setting depends on what service the hostname actually provides.
Coordinate DNSSEC and change nameservers
If DNSSEC is active, coordinate the transition with the registrar before replacing nameservers. An old DS record combined with the new DNS configuration can break domain resolution. Follow the current Cloudflare instructions and the registrar's procedure, then verify the new DNSSEC chain when appropriate.
Enter the nameservers assigned specifically to the domain. Save the previous values and change time. Resolvers do not all refresh simultaneously, so a successful result on one laptop is not sufficient evidence that the transition is complete.
Enable Full (strict) with a valid origin certificate
Full (strict) requires the origin to accept HTTPS and present a valid certificate covering the relevant hostname. Cloudflare documents support for certificates from a publicly trusted authority or its Origin CA when the stated requirements are met.
Check validity dates, hostnames and the server's HTTPS configuration. An Origin CA certificate has different trust implications for direct browser access to the origin. Do not weaken encryption simply to hide a certificate error. Repair the underlying certificate or hosting configuration and then repeat the check.
Start with conservative caching rules
Cache suitable public assets first. Do not apply broad page caching to authenticated areas, carts, checkout, administrative screens, personal responses or form handlers. Review any CMS and server cache alongside Cloudflare's settings.
Write down which cache needs clearing after a content change. When an outdated page appears, identify the layer returning it before rewriting several rules. A controlled sequence is easier to troubleshoot and reduces the chance of exposing personalized content through an incorrect cache policy.
Test the complete user journey
Check the site on a phone and computer, including both hostnames, redirects, downloads and CMS login. Submit an agreed test request and follow it through the application to the receiving system.
Verify incoming and outgoing email separately; a working webmail login does not prove both directions work. Check expected analytics events under the applicable consent settings. If protection blocks a legitimate request, inspect that request and the relevant rule instead of switching off the site's entire protection layer.
A conditional troubleshooting example
Suppose pages load after the switch but contact requests disappear. Compare the form response with the previous behavior, inspect application logs and review cache exclusions. If the server accepted the request, investigate notification delivery separately rather than assuming DNS caused the failure.
For rollback, reverse the specific problematic setting where possible. Returning nameservers also requires a current old zone and time for DNS responses to change. Keep the previous DNS service intact until the transition has been checked.
Keep a usable handover record
For hosting context, see Standard vs Boost hosting: resources and limits and WordPress hosting: Standard, Boost or VPS. View hosting offers. Configuration requirements can be discussed through hosting selection.
Save the final DNS record list, account owners, cache clearing procedure and verification results. The next person maintaining the website should be able to understand the arrangement without reconstructing it from private messages.
Sources and verification date
Checked on 3 November 2026. This workflow combines documented requirements with practical implementation guidance; dashboard labels may change.