# Cloudflare, firewall and email security — the setup most people get wrong URL: https://rootcr.com/cloudflare-firewall-email-security/ Updated: 2026-09-24 # Cloudflare, firewall and email security: the setup most people get wrong > **In short:** RootCR configures the protection layers of Cloudflare and the other major providers: web application firewall (WAF), bot and DDoS protection, hiding the server's real IP address, and business email authentication (SPF, DKIM, DMARC) so your mail stops landing in spam. The work is done in your existing accounts, and every step is measured. RootCR's own systems run 26 Cloudflare zones set up this way (2026-09-24). Under a custom agreement. ## Why do most Cloudflare setups go wrong? Switching Cloudflare on takes five minutes; setting it up well does not. In RootCR's experience, most mistakes produce no error message: the site looks fine in a browser, while the protection can be bypassed, Google cannot reach the pages, or payment confirmations do not get through. ### The seven most common cases What RootCR finds most often when it reviews an existing setup: | Symptom | Cause | What we set up | |---|---|---| | The "orange cloud" is on, yet attacks still hit the server | the server also answers on its own IP address, so the CDN can be bypassed | the server only accepts traffic from the CDN and silently drops everything else | | The IP address is "hidden", yet it can be found | an old DNS record, a grey-cloud subdomain, or mail pointing at the same machine | DNS clean-up, separating mail from the web | | Google and AI search engines rarely or never visit | a bot challenge applied to every visitor, which crawlers cannot solve | targeted allowances for verified search and AI crawlers | | Card payments "disappear" in the web store | the firewall treats the bank's callback (webhook) as a bot | an exception for the payment provider's callback | | After an update, visitors still see the old file | the CDN cache serves the old content of a replaced file | versioned file names, cache rules | | Redirect loop or "not secure" warning | the wrong SSL mode between the CDN and the server | an encrypted, certificate-verified connection end to end | | Email address missing from the machine-readable page | the CDN's email obfuscation rewrites the link | switching that feature off where it hurts | ### A real case: 13 hours of a stale file, with clean 200 responses The cache case is not theory: on 27 August 2026, on one of RootCR's sites, the CDN served the old version of a replaced font file for about 13 hours, while every request returned a clean 200. Since then every replaceable file gets a content-hashed name, and freshness is measured from a real browser. ## How is the server's real IP address hidden? RootCR hides the server's IP address in four layers, because one layer on its own is not enough: 1. **DNS.** Every web record goes through the CDN, old and forgotten records are deleted, and mail is handled separately so that the MX and SPF records do not give away the web server. 2. **The server's firewall.** The web port accepts connections only from the CDN's publicly listed address ranges and drops every other packet without a reply. We track those ranges and update them when they change. 3. **The web server's own check.** If a request ever got past the firewall, the web server checks where it came from and rejects anything that did not arrive through the CDN with a 403. 4. **Invisible administration.** Remote access only over an encrypted private network, with keys; no administration port is open to the outside. Measured from outside, from an independent network (2026-09-24): a web request sent directly to the server's address got no reply at all, and the connection timed out after six seconds; the administration port was closed; the same site answered with a 200 through the CDN. An often-missed detail: behind a CDN the server sees every visitor as coming from the CDN's address. Unless that is switched to the real visitor address, rate limiting lumps all visitors together, and a block would ban the CDN instead of the attacker. ## What do we configure on Cloudflare? RootCR configures Cloudflare item by item, in your own account, and you get a written description of everything. For most small and medium-sized businesses the free plan is enough when it is configured well; we only recommend a paid plan when measurements justify it. | Area | What we configure | |---|---| | Encryption | encrypted, certificate-verified connection end to end, HSTS, legacy protocols disabled | | DNS | DNSSEC, clean-up of unnecessary and leaking records, CAA record | | Web application firewall (WAF) | the managed ruleset, custom rules for the site's real paths, admin area locked down | | Bot and DDoS protection | challenges where needed; verified search and AI crawlers, payment and courier callbacks let through | | Rate limiting | per endpoint: login, forms, search, API | | Cache | rules per page type; checkout and account pages never cached | | Form protection | human verification without bothering the visitor | | Redirects | domain consolidation, old addresses with a single-hop 301 | Before every change a full export of the DNS zone is made, so any step can be rolled back. ## What protects the site behind Cloudflare? RootCR adds a second layer behind the CDN, because CDN rules can be bypassed at some point, and because the CDN itself can be misconfigured. A web application firewall runs on the server itself, with an open, industry-standard ruleset. New rules first go live in detection mode: they log but do not block. A rule that is too strict can stop orders, payments or quote requests, with no error message. We refine the rules from the log and only then switch to blocking. On RootCR's own systems, the server-side WAF runs in blocking mode on 6 sites and in detection mode on 24 (2026-09-24). On an attack, the block is applied at the CDN edge within about a second and covers the whole website: the attacker's next request does not even reach the server. The same system protects the [AI chatbot](/ai-chatbot-development/). ## Why does business email land in spam? The most common reason is that the domain does not state who may send on its behalf. Three DNS records do that, RootCR sets up all three, and since 2024 the big mailbox providers require them: | Record | What it says | What happens without it | |---|---|---| | SPF | which servers may send on behalf of the domain | the message looks suspicious, often goes to spam | | DKIM | a digital signature proving the message was not altered in transit | authenticity cannot be proven | | DMARC | what the receiver should do if the other two fail, and whom to report to | anyone can send in your company's name, and you will not even know | Google and Yahoo have required SPF, DKIM and DMARC from senders of more than 5,000 messages a day since February 2024, and Microsoft (Outlook.com, Hotmail) since 5 May 2025; since then Microsoft rejects non-compliant mail with a 550 error instead of putting it in the junk folder (the providers' announcements, 2023–2025). For smaller senders the bar is the same in practice: unauthenticated mail heads towards spam. ## What goes wrong in email setups? For email, RootCR starts from the full list of sending systems, because the fault is almost always a forgotten sender. Typical cases: - **Web store confirmations go to spam.** The order email is sent by the web store's server, which is not in the SPF record. The invoicing tool, the newsletter service and the CRM are often missing the same way. - **There are two SPF records.** The standard allows one; with two, authentication fails as if there were none. - **Too many includes in SPF.** The standard (RFC 7208) allows at most 10 DNS lookups; every provider include counts, and the 11th already causes a failure. - **DMARC "p=none" forever.** That only monitors, it does not protect; the domain can still be spoofed. - **A non-sending domain left open.** If a domain never sends mail, say so (SPF `-all`, DMARC `reject`), or fraudsters will send from it. One client domain managed by RootCR is locked down exactly this way. The rollout order: DMARC in monitoring mode, with reports; from the reports, the complete list of senders; every legitimate sender authenticated; then quarantine, and finally `reject`. RootCR's own domain runs with a `reject` policy. If needed, we also set up BIMI, which can show the company logo in the inbox; it requires a strict DMARC policy and a separate certificate. ## Which systems do we work with? RootCR configures the major providers' systems in your own account, through the provider's own console and API. The principle of protection is the same everywhere; the configuration differs by provider:

All names are trademarks of their respective owners. RootCR is not a partner or reseller of any of them: configuration is done in the client's own account.

In text, by category: content delivery network and web application firewall (Cloudflare, Akamai, Fastly, Amazon CloudFront and AWS WAF, Azure Front Door, Google Cloud Armor, Imperva, Sucuri); network firewall (FortiGate, pfSense, OPNsense, MikroTik, Linux nftables and iptables); business email and email sending (Microsoft 365 and Exchange Online, Google Workspace, Amazon SES, SendGrid, Mailgun, Brevo); DNS (Cloudflare, Route 53, Azure DNS). Email authentication is aligned with the rules of Gmail, Outlook.com and Yahoo. ## How does the work run? RootCR does not ask for passwords. We get access as a restricted member or through a narrowly scoped API key in your account, which you can revoke at any time. The steps: 1. **Assessment, read-only.** DNS, CDN, firewall, email, sending systems; also measured from outside, the way an attacker would see it. 2. **A written plan.** What changes, in what order, what the risk is, and how to roll back if needed. 3. **Backup.** An export of the DNS zone and the existing rules before every change. 4. **Step-by-step rollout,** starting in detection mode where possible, outside busy hours. 5. **Measurement and handover.** A dated report on what is configured and what was measured. 6. **Monitoring on request.** A weekly automated check that nobody has accidentally switched the settings, and an alert if email authentication starts failing. ## What does it cost? RootCR does this work under a custom agreement, because the scope differs hugely between companies: one domain with one mailbox, or ten domains with three mail-sending systems, a web store and an office firewall. After the assessment you get a written quote with a fixed price and a fixed deadline. Ongoing monitoring can be ordered separately. ## What I do not promise There is no unbreakable system, and no CDN replaces a well-written, up-to-date application. What RootCR commits to: 1. **No gap next to the CDN.** From outside, the server can only be reached through the protection. 2. **No silent damage.** Anything that affects search engines, payments or email is measured after the change, not assumed. 3. **Everything can be rolled back.** A backup before every step, a written description of every setting.
Not sure where you stand? Send me your domains and the systems that send email in your name. I will tell you what is visible from outside: whether your server can be reached by going around the CDN, and whether your mail passes the major providers' authentication.
## Frequently asked questions ### Do I need a paid Cloudflare plan? Most small and medium-sized businesses do not. On RootCR's own systems all 26 zones run on the free plan (2026-09-24). We recommend a paid plan when traffic, a specific rule or a required availability level justifies it by measurement. ### Will the site go down during the setup? It does not have to. The steps are ordered so that visitors notice nothing; where a short switchover is unavoidable (for example a nameserver change), it is agreed in advance and scheduled outside busy hours. ### Can it be set up in front of an existing WordPress site or web store? Yes: the CDN, the firewall and email do not depend on what the site runs on. On hosted store platforms (for example Shopify) the CDN proxy is not always allowed; there the job is putting the DNS in order and authenticating email. ### Our emails already go to spam. What can be done quickly? The first step is the list of sending systems and a check of the existing records; the most common faults (a forgotten sender, a duplicate SPF record) can usually be fixed the same day. Moving to a strict DMARC policy, however, takes a few weeks of report collection so that not a single legitimate message gets stuck. ### Someone else set up our Cloudflare. Can you review it? Yes. The assessment starts read-only, so nothing changes until you accept the plan. You get in writing what is risky, what is unnecessary and what is missing. ### Do you also take on office networks and firewalls? Yes: configuring network firewalls (FortiGate, pfSense, OPNsense, MikroTik) and encrypted links between sites, under a custom agreement. The server side is described on the [security and monitoring](/security-and-monitoring/) and [managed hosting](/managed-hosting/) pages.