Six Cloudflare Settings Not On By Default

So I ran an audit on every Cloudflare zone I own this morning, and the report came back with 59 high-severity findings and 49 medium. My first reaction was, "Okay, this is worse than I thought." My second reaction, once I started reading the list, was, "Oh, this is mostly the same six settings missing across every zone."

Cloudflare does not turn a bunch of security knobs on by default. Some of that is historical (they used to default to the weaker settings and never flipped the switch for existing zones). Some of it is intentional (a few of these are semi-permanent once you turn them on, so Cloudflare makes you opt in). Either way, if you have not touched a zone in a while, there is a really good chance your zone looks like mine did this morning.

Here are the six settings, what each one does, and why it matters. Plain English, not jargon.

1. SSL mode — set it to Full Strict

Cloudflare sits between your visitor and your origin server. Your visitor talks to Cloudflare over HTTPS. Then Cloudflare talks to your origin separately — and that connection can be secure, sort of secure, or not secure at all, depending on this setting.

• Flexible means visitor-to-Cloudflare is HTTPS but Cloudflare-to-origin is plain text. Padlock in the browser, but the traffic is not actually secure.
• Full means Cloudflare-to-origin is HTTPS, but Cloudflare does not check if the cert at the origin is valid. Expired or self-signed passes.
• Full (strict) means Cloudflare-to-origin is HTTPS AND the cert has to be valid.

Set it to Full Strict. The only catch is that your origin actually has to serve a valid cert. Most modern hosts (Cloudflare Pages, Vercel, Netlify, GoHighLevel, anything on AWS with ACM) already do. If yours does not, fix that first.

2. Always Use HTTPS — turn it on

When someone types your domain into a browser without typing "https://" first, the browser sends an HTTP request. Cloudflare gets that HTTP request. With Always Use HTTPS on, Cloudflare sends back a redirect to the HTTPS version. With it off, Cloudflare just serves the page over HTTP.

The risk of leaving it off: someone on hostile WiFi (airport, coffee shop, conference center) types your domain. The first request goes out unencrypted. A sniffer on the same network can see which page they landed on and even inject content before Cloudflare ever responds.

Turning it on is free. It only changes what happens to the handful of requests that came in HTTP-first. No downside.

3. Minimum TLS Version — set it to 1.2

TLS is the protocol that negotiates the encryption. There are four versions — 1.0 (1999), 1.1 (2006), 1.2 (2008), 1.3 (2018). The older two have known weaknesses. Cloudflare let you accept anything from 1.0 up for years, to support ancient clients.

Set the minimum to 1.2. Modern browsers will still negotiate 1.3 automatically (1.2 is the floor, not the only). You are cutting off things like iOS 12 or older, Android 9 or older, corporate proxy appliances that never got updated. Nobody you actually want on your site.

Why not 1.3? Because the cutoff would be more aggressive — you would lose the long tail of clients that support 1.2 but not 1.3. Revisit in a year or two. For now, 1.2 is the compliance floor (PCI, HIPAA) and the practical one.

4. HSTS — enable it with preload

HSTS is the "never use HTTP for this domain, period" header. Once a browser sees it, it remembers — for up to a year by default — that your domain is HTTPS-only. The browser stops even trying HTTP. Every request goes straight to the secure version.

There are four knobs:

• max-age — how long the browser remembers. Use one year (31536000 seconds). Anything less than six months is considered weak.
• includeSubDomains — extends the rule to every subdomain. Harden everything at once.
• preload — adds your domain to a list that ships inside Chrome and Firefox. Even a visitor who has never been to your site gets HTTPS-only from the first click.
• nosniff — a bonus header Cloudflare bundles. Stops browsers from guessing content types, which defends against some cross-site scripting tricks.

Turn on all four.

The one thing to know: preload plus includeSubDomains is close to permanent. Removal takes months to propagate through browser releases. Before you enable it, make sure every subdomain you care about is actually on HTTPS. If you have a legacy subdomain on some dusty server that still does HTTP, fix that first. On a typical modern setup (Pages, Vercel, GHL), you are fine.

5. DNSSEC — turn it on

Regular DNS is trust-based. When your browser asks "what IP is domain.com," it accepts the first answer that comes back. An attacker poisoning a DNS cache, or your ISP injecting responses, or a local attacker on the same network — all of that works.

DNSSEC adds cryptographic signatures to DNS responses. The resolver can actually verify the answer came from the real authoritative source and was not tampered with. It is a chain of signatures — your zone is signed, the signing key is signed by a higher key, which is signed by your registrar, which chains up to the root.

Cloudflare makes this one click if your domain is registered with Cloudflare Registrar. They publish the required DS record at the registrar side automatically. If your domain is at GoDaddy or Namecheap, you have to copy the DS record over manually — and if you forget or mistype it, your domain goes dark. That is why Cloudflare leaves it off by default. Turn it on, but be ready to confirm the DS record lands if your domain is not on Cloudflare Registrar.

6. Root SPF — and the trap that broke my email

Here is the one that almost cost me. The audit flagged every zone for missing an SPF record at the root. SPF is the TXT record that tells email receivers "these mail servers are allowed to send email from me." Without one, spoofed emails from your domain can land in inboxes because the receiver has nothing to check against.

The documented fix for a domain that does not send email is v=spf1 -all. Null SPF. "No mail server is authorized." Receivers reject anything claiming to be from the domain. Clean and simple.

So I did that on one of my domains. Set the null SPF. Moved on.

My buddy (Claude, actually — I was working through this with Claude Code) asked, "Do you use Resend for any email on this domain?" I checked. The domain was a verified sender in Resend.

The issue is subtle. Resend sets its own SPF on the send. subdomain, not the apex. So the send. subdomain is handled — Resend's own records authorize Amazon SES (which Resend uses under the hood). But if any email gets sent with a FROM address on the bare domain — like hello@mydomain.com instead of hello@send.mydomain.com — my null SPF at the apex would block it.

The fix: at the apex, set v=spf1 include:amazonses.com ~all instead of the null SPF. That authorizes Amazon SES to send from the bare domain too. Softfail (~all) instead of hardfail (-all) — flagged as suspicious, but not rejected outright. Mirrors what Resend already has on the subdomain.

If your domain sends through anything — Resend, Google Workspace, Mailgun, SendGrid, a CRM, custom SMTP — check it before you null out SPF. Every sender needs to be in the chain. Google Workspace would add include:_spf.google.com. Mailgun adds its own include. You can stack them.

The test: if you send email from the domain through any service, the null SPF is wrong. Use the includes.

The Pattern

The reason all six of these are off by default is the same reason. Cloudflare does not want to break existing sites. Strict SSL can break a site with a broken origin cert. HSTS preload is hard to undo. DNSSEC can break a domain if the DS record is wrong. So Cloudflare makes you opt in, one at a time, when you are ready.

Which means: if you never opt in, none of them are on.

Every zone should run through all six. The audit script I use runs on cron every day and emails me a report. When something drifts — a new zone added without the knobs flipped, an SPF that stopped matching the senders, a DNSSEC that went inactive after a registrar transfer — it shows up in the morning email.

You do not need a fancy audit script to do this once. Walk through the six knobs on any zone you care about. It takes about five minutes per domain. The security baseline it gives you is miles better than what Cloudflare ships by default.

If any of the six did not make sense, drop a question in the comments and I will explain.