Set up Cloudflare from scratch

Sign up at dash.cloudflare.com/sign-up with an email address and a password, then confirm the verification email. The Free plan is genuinely free and does not ask for a card. One account can hold as many domains as you like.

Two things worth getting right now rather than later. Use a company mailbox nobody is going to lose access to — not a personal address, and not one belonging to a staff member who might leave. This account ends up controlling where your entire domain points. For the same reason, turn on two-factor authentication before you add the domain.

Choose Add a site and enter your domain without any prefix — example.com, not www.example.com and not a full URL. Pick the Free plan when offered.

Cloudflare then scans your current DNS and imports what it can find. Treat that import as a draft, not a copy. The scan can only see records it knows to ask for, so anything it misses will simply not exist once Cloudflare becomes authoritative. That record does not degrade gradually; it stops answering at the moment you cut over.

Open your current DNS provider's zone in another tab and compare it line by line against what Cloudflare imported. If you cannot get into that zone, whoever manages the domain can export it for you.

MX — mail delivery

Where your inbound email is delivered. If these are missing or wrong when Cloudflare goes live, mail to your domain stops arriving. It does not bounce back to you, so nobody tells you: the sender gets the rejection.

TXT (SPF) — who may send as you

A single TXT record starting v=spf1. Lose it and your outbound mail starts failing authentication at the receiving end, which usually shows up as your mail landing in spam rather than as an outright error.

DKIM — mail signing keys

Published on provider-specific names such as google._domainkey or selector1._domainkey. These are the records an automatic scan misses most often, because you cannot find them without already knowing the selector name. Get them from your mail provider if the import came up empty.

TXT (DMARC) — _dmarc

Tells receiving servers what to do when SPF or DKIM fails. If your policy is p=reject and the SPF record did not come across, your own mail is the thing being rejected.

A / AAAA — the apex and subdomains

Your domain and anything under it that points at an IP address directly. Check every one, not just the apex.

CNAME — subdomains pointing elsewhere

www, shop, app, mail, help, staging, and anything a third-party service asked you to add. Each one is a service that stops resolving if it does not come across.

TXT — domain verification records

Google Search Console, Microsoft 365, Atlassian, Facebook and similar all park a verification string in DNS. Drop one and the service quietly treats your domain as unverified, sometimes weeks later.

SRV — service records

Less common, but Microsoft 365, Teams and VoIP systems use them. If your old zone has any, copy them exactly.

Do not delete a record because you do not recognise it. Copy it across and work out what it was afterwards. An unexplained TXT record is almost always something verifying your domain to a service you have forgotten you use.

At your current provider, drop the TTL on your records to five minutes and leave it a day before going further. This shortens how long a mistake in one record — the wrong IP, a missed subdomain — takes to clear once you fix it.

It will not speed up undoing the nameserver change itself if that goes wrong. NS records (and the DS record if DNSSEC is on — see the next step) are cached by the parent zone and other resolvers on their own schedule, outside your control, so reverting a bad cutover can still take hours regardless of any TTL you set here. Skip this step if you cannot reach the old provider, but take it if you can: it still shrinks the blast radius of an ordinary record mistake.

Check whether DNSSEC is on at your current provider before you touch anything. If it is, turn it off there (or delete the DS record at your registrar) and wait for that change to clear before repointing nameservers. Leaving it on points validating resolvers at a signing key Cloudflare doesn't hold, so they reject every answer for the domain with SERVFAIL — mail included, not just the web site. It is the one mistake on this page that breaks resolution outright rather than degrading gracefully. Once Cloudflare reports the zone active, re-enable DNSSEC there using the new DS record it gives you — do not reuse the old one.

Cloudflare gives you two nameserver names — something like amy.ns.cloudflare.com and rick.ns.cloudflare.com. They are specific to your account, so use the pair Cloudflare shows you rather than any pair you find written down elsewhere.

This change is made at your registrar, which is often not the company serving your DNS today. Your registrar is whoever you pay to renew the domain each year. If your web host, developer or agency currently runs your DNS, the nameservers still have to change at the registrar — changing anything in the old DNS panel will not do it. If you are not sure who your registrar is, look the domain up at lookup.icann.org and read the registrar field.

Replace the existing nameservers with Cloudflare's two. Do not add them alongside the old ones: a zone answered by two different providers gives different answers to different people.

Cloudflare emails you when the domain goes active. It is usually minutes to a few hours, and occasionally up to 24. Leave the old zone in place at your previous provider for a week or two afterwards — do not cancel that hosting the same day. If something turns out to be missing, the original zone is what you compare against.

Work through this on the day of the change, while you still remember what you touched.

The zone is Active

Cloudflare emails you and the dashboard stops saying "Pending nameserver update". Until then the old provider is still answering, and nothing you change in Cloudflare has any effect.

Your site loads over https

Visit the apex and the www version. Both should load without a certificate warning.

SSL/TLS mode is Full or Full (strict)

Full (strict) if your origin server has a valid certificate, Full if it has a self-signed one. Do not set Flexible to make a broken page load: it sends traffic between Cloudflare and your server unencrypted and commonly causes infinite redirect loops.

Email works in both directions

Send a message from an outside address to your domain, and send one out. Do this the same day, not next week, while you still remember what changed.

Subdomains still resolve

VPN endpoints, webmail, staging sites, a shop on a different host. These are what the import scan misses, so they are what breaks.

Your site record is Proxied (orange cloud)

In the DNS tab, the record for your site must show the orange cloud, not the grey one. A grey-cloud DNS-only record bypasses Cloudflare completely, which means a NORG worker installed later never runs.

There is no separate Workers account. Every Cloudflare account includes Workers on the free plan, so once your domain is active you already have everything a NORG mirror install needs.

One caveat worth knowing before you install rather than after. A mirror binds a worker to the route {domain}/*, so every request to your site passes through it, and the Free plan stops invoking workers after 100,000 requests in a day. What that means depends on how you install:

• Installed with the API token or the dashboard (Route 2 or 3 on the next guide) — NORG creates that route to fail open, so hitting the cap serves your ordinary site directly and skips the mirror. Nothing goes down; AI-agent traffic just stops seeing the mirrored version until usage resets or you upgrade.
• Installed with the Deploy button (Route 1) — that route is one you create yourself in the Cloudflare dashboard, so it keeps Cloudflare's own default: fail closed. Hitting the cap there errors every request to your site, not only the AI-agent traffic the worker exists to serve.

Either way, Upgrade to Cloudflare Workers Paid removes the cap rather than just softening what happens when you hit it.