Setting up Cloudflare on an Australian domain, without taking the site down

By Angus Lewington, Alien Web Design · Last reviewed: 15 August 2026 · Reviewed every 6 months

The two ways this goes wrong, and they are both order of operations

One: you switch nameservers before the imported zone is complete. Cloudflare scans your existing DNS when you add a domain, but that scan is not guaranteed to catch everything. Whatever it missed stops working the moment Cloudflare becomes authoritative, and the records it most often misses are the ones that carry your email.

Two: you turn the proxy on before your server has a certificate Cloudflare will accept. That produces error 526 and takes the site down for everyone, immediately, with no warning at the moment you click.

Both are avoided by the same thing: do the DNS move and the proxy switch as two separate changes, with verification in between. This guide is written in that order.

Adding Cloudflare to a site that already works is a low risk job done in the right sequence and a genuinely bad afternoon done in the wrong one. The sequence is: capture what you have, import it, verify it, move the nameservers with nothing proxied, get a valid certificate on your server, then turn the proxy on. Most guides collapse those into one step, which is where the outages come from.

Before you start: full setup or partial?

Cloudflare offers two ways in, and the one nearly every tutorial describes is not available on the free plan.

Setup	What happens	Availability
Full setup	You point your nameservers at Cloudflare and it becomes authoritative for the entire zone.	All plans, including Free. This is the one you will use.
Partial (CNAME) setup	You keep your existing DNS provider and proxy only selected hostnames.	Business and Enterprise plans only, and not at all on domains registered with Cloudflare Registrar.

If you have read a guide describing the partial setup as the safe low commitment option, it was written for someone on a Business plan. On Free, moving the whole zone is your only route, which is precisely why the capture step below is not optional.

A note for .com.au owners

You do not move the domain itself. Cloudflare Registrar does not sell Australian domains: checked on 15 August 2026, Cloudflare's TLD policies page carries no .au or .com.au entry, though other country domains such as .nz are on it. Your domain stays with VentraIP, Crazy Domains, Synergy or whoever holds it now, and all you change there is the nameserver field. That is the whole Australian difference, and it is a small one.

Step 1. Capture the zone before you touch anything

This is the step that makes the rest of it reversible. Ten minutes here or a week of missing email later.

Command	Captures
`dig MX example.com.au +short`	Mail routing. The one that ends businesses.
`dig TXT example.com.au +short`	SPF and domain verification tokens.
`dig A example.com.au +short`	Where the website points.
`dig NS example.com.au +short`	Current nameservers, and how you confirm the switch later.

Export the full zone file if your current provider offers it. Lookups only return records you thought to ask for, and the two categories people forget are DKIM selectors, which live on subdomains like selector1._domainkey.example.com.au and never appear in a root TXT lookup, and SRV records used for mail client autodiscovery. The long version of this, including what to do if it has already gone wrong, is in changing DNS records and nameservers without killing your email.

Step 2. Add the domain, then audit what Cloudflare imported

Add the site in the Cloudflare dashboard and it will scan your existing DNS and present the records it found. Do not accept that screen at a glance. Cloudflare's own documentation is explicit that the scan is not guaranteed to find every record.

Compare it line by line against what you captured in step 1. Add anything missing now, while the old nameservers are still live and mistakes cost nothing.

Step 3. Turn the proxy off on everything, for now

Proxying is on by default when you onboard a domain through the dashboard. Turn it off on every record before you switch nameservers, so that your first change is purely a change of DNS host with no change in behaviour. If something goes wrong, you will know it was the DNS move rather than the proxy, which is worth a great deal at the point where you are trying to fix it.

Proxied and DNS only, and which records can even be proxied

Status	What Cloudflare returns	Applies to
Proxied (orange cloud)	A Cloudflare IP address. Traffic routes through Cloudflare, which caches, optimises and filters it. Your server's real address is hidden.	A, AAAA and CNAME records only.
DNS only (grey cloud)	Your server's actual IP address. Cloudflare answers the DNS question and nothing else.	Any record type.

Three rules from Cloudflare's proxy status documentation that catch people out:

MX and TXT records are always DNS only. They cannot be proxied and there is no setting to change. If someone tells you Cloudflare's proxy is hiding your mail server, it is not.
Mixing statuses on the same name does not work the way it looks. If you have two A records on blog and only one is proxied, Cloudflare treats both as proxied.
Domain ownership verification records should stay DNS only. Proxying a CNAME that a third party uses to verify you own the domain will usually break that verification.

Step 4. Change the nameservers, then stop and verify

Cloudflare gives you two nameservers. Set them at your registrar, replacing what is there. The click paths for VentraIP, Crazy Domains and GoDaddy are written out in the nameserver guide.

Then wait, and check in this order. Do not skip to the website, which is the least informative of the three.

Confirm the delegation moved
dig NS example.com.au +short should return the Cloudflare nameservers. Until it does, nothing else you test means anything.
Confirm mail survived
dig MX example.com.au +short should match your captured copy exactly. Then send a real email to the domain from an outside account and confirm it arrives. A resolving MX record proves DNS is right, not that mail is being delivered.
Load the website
It should look exactly as it did yesterday, because nothing is proxied. If it does not, the problem is a missing record, not Cloudflare.

If some people see the change and others do not, that is ordinary cache expiry and it is more predictable than the 48 hours everyone quotes. Let it settle before moving on. There is no prize for doing step 5 the same hour.

Step 5. Get a real certificate on your server, before the proxy goes on

This is the step that separates a clean switch from an outage, and it is the one almost universally taught in the wrong order.

Grey cloud first, certificate second, orange cloud third

Issue your origin certificate while the DNS records are still DNS only. Let's Encrypt's HTTP validation works by fetching a file from your server over port 80 at the address the DNS record points to. While that record is grey, it points at your server and validation succeeds. Once it is orange, the request lands on Cloudflare instead, and validation behaves differently or fails outright depending on your configuration.

Then set the encryption mode. Then turn the proxy on. In that order there is no window in which Cloudflare is proxying a site whose certificate it will not accept.

We learned this one the ordinary way, on our own infrastructure: enabling the proxy first on a zone already set to Full (strict) returns 526 for every visitor, instantly.

Your two sensible options are a public certificate from Let's Encrypt, which most Australian hosts and control panels can issue for you, or a Cloudflare Origin CA certificate, which is free, lasts up to fifteen years and is trusted by Cloudflare but by nothing else. Origin CA is the better choice when traffic will always arrive through Cloudflare, and the wrong choice if anything connects to your server directly.

Step 6. Choose the encryption mode deliberately

The mode controls the leg between Cloudflare and your server. Visitors see HTTPS either way, which is exactly why the insecure setting survives on so many sites for so long.

Mode	Cloudflare to your server	Use it when
Off	No encryption anywhere. Everything is cleartext HTTP.	Effectively never for a business site.
Flexible	Visitor to Cloudflare is encrypted. Cloudflare to your server is not.	Only as a temporary measure on an origin that genuinely cannot do TLS. Visitors see a padlock that is telling them something untrue about half the journey.
Full	Encrypted, but the origin certificate is not validated.	Acceptable with a self signed certificate. Better than Flexible, weaker than it looks.
Full (strict)	Encrypted and the origin certificate is validated. Accepts a public CA such as Let's Encrypt, or Cloudflare Origin CA.	This is the target. Set it once step 5 is done.
Strict (SSL-Only Origin Pull)	Always connects to the origin over HTTPS regardless of how the visitor arrived.	Specialist. Leave it alone unless you have a reason.

Cloudflare now offers an Automatic SSL/TLS setting as the default, which selects a mode for you. It is a reasonable default and we still recommend setting Full (strict) explicitly on a business site, because a mode you chose is a mode you can reason about at 2am.

Step 7. Turn the proxy on, then verify like a visitor

Enable the orange cloud on the root record and www first. Leave subdomains that are not web traffic alone. Then check the site.

Verify in a browser, not with curl

Cloudflare treats browser and non-browser clients differently, and this misleads people during exactly this step. Two things we have hit repeatedly on our own zones:

Cloudflare injects its analytics beacon for browser clients only, so a command line fetch will show you a page with no beacon and tell you nothing useful about whether it is working. And on some zones Cloudflare returns 403 to default scripting user agents, so a verification script using a stock Python or urllib user agent reports every page as dead while the site is perfectly fine in a browser.

Open the site in a real browser, check for console errors, and only then trust a command line tool, with a browser user agent set.

When it breaks: the Cloudflare 5xx triage table

Cloudflare errors in the 52x range are generated by Cloudflare about your server, which is why they are useful. Each one narrows the problem considerably. Details below are from Cloudflare's own error documentation, checked 15 August 2026.

Error	What it means	Where the fault is
520	Your server returned an empty, unknown or unexpected response.	Your server or its application. Check error logs first.
521	Your server actively refused the connection from Cloudflare.	Almost always a firewall blocking Cloudflare's IP ranges, or the server not listening on the port your encryption mode requires: port 80 for Flexible, port 443 for Full and Full (strict).
522	Connection timed out. No SYN+ACK within 19 seconds, or no acknowledgment of the request within 90 seconds after the connection was established.	Most commonly Cloudflare IPs rate limited or blocked in `.htaccess`, iptables or a firewall. Also an overloaded origin, disabled keepalives, or a DNS record pointing at an IP your host no longer uses.
524	Cloudflare connected fine, but your server sent no HTTP response within the 125 second proxy read timeout.	Your application is too slow, not unreachable. A heavy query, an export, a struggling database.
525	The TLS handshake between Cloudflare and your server failed, with Full or Full (strict) set.	No valid certificate installed, port 443 closed, no SNI support, or a cipher suite mismatch.
526	Cloudflare could not validate your server's certificate, with Full (strict) set.	Expired, revoked, self signed, wrong hostname, or an incomplete chain. This is the one you get for turning the proxy on too early.

Fixing a 526 specifically

Because it is the one this guide is built to prevent, in order of preference:

Fix the certificate. Confirm it is not expired or revoked, is signed by a certificate authority rather than self signed, carries the right hostname in its Common Name or Subject Alternative Name, and that your server sends the full chain including intermediates. An incomplete chain is the subtle one: it often works in browsers, which fill the gap themselves, and fails at Cloudflare, which does not.
Install a Cloudflare Origin CA certificate, if the origin only ever serves Cloudflare traffic.
Drop to Full temporarily to get the site back while you fix the real problem. Cloudflare lists this as a quick fix and it is, but it is a downgrade, so treat it as an outage workaround with a deadline rather than a resolution.

If your site is down and you are not certain Cloudflare is involved at all, start with the broader website down triage, which separates DNS, origin and gateway faults before you start changing settings.

Afterwards: the one setting everyone forgets

Once traffic is proxied, Cloudflare caches your static files, which means your changes will not always be what visitors see. Update a stylesheet and get the old one back, and nothing is broken: it is a cached copy with life left in it.

Purge the cache from the dashboard after a deploy, or better, add a version string to your asset URLs so each change requests a genuinely new file. A site that needs a manual purge after every edit will eventually get one that someone forgets.

The short version

Capture your DNS zone, including DKIM selectors that lookups miss. Add the domain, then audit Cloudflare's import against your capture rather than trusting the scan. Set everything DNS only, switch the nameservers, and verify mail with a real test message before you go further. Then get a valid certificate onto your origin while records are still grey, set Full (strict), and only then turn the proxy on, one record at a time, checking in a real browser. If you get a 526, you did steps 5 to 7 in the wrong order, and dropping to Full will get you back up while you sort the certificate out.

General guidance only, current at the review date above. Cloudflare's dashboard and defaults change regularly, so trust what is on your screen and Cloudflare's own current documentation over any guide, including this one.

Where this comes from

The primary sources behind the above, so you can check any of it yourself:

Cloudflare: set up a primary zone (full setup) and partial (CNAME) setup, including the plan restriction.
Cloudflare: proxy status, the source of which record types can be proxied, the on-by-default behaviour, and the mixed status rule.
Cloudflare: encryption modes, the source of the mode table.
Cloudflare: 5xx errors, and the individual pages for 521, 522, 524, 525 and 526, the source of the triage table and the timeout figures.
Cloudflare TLD policies, checked 15 August 2026 for .au and .com.au.