Cloudflare Command Center: Domains, DNS, Zero Trust, and Tunnels from Beginner to Expert Part 20: The Expert Cloudflare Playbook. Full Stack Implementation from Domain to Zero Trust

Twenty parts. Twenty layers of domain configuration, DNS architecture, security policy, and access control methodology. If you've followed this series from Part 1, you've built a working mental model of how Cloudflare operates at every layer of the stack. That's not a small thing. Most people who touch Cloudflare start with the free tier, point their nameservers, and stop. You went further. You learned why the decisions matter, not just which buttons to click.

Part 19 closed out the Zero Trust access policy work, covering identity provider integration and the device posture rules that make application access decisions trustworthy rather than just gated. That was the policy summit. The rules exist. The infrastructure is configured. The pieces are all present.

This is where they connect. Part 20 is the full-stack implementation playbook, and it runs from domain registration through Zero Trust enforcement using a single fictional company as the through-line. Every decision gets justified. Every configuration gets sequenced. Nothing gets hand-waved.

Welcome to the Capstone: What This Playbook Covers

Twenty-three parts is a long series. Parts 1 through 19 built the vocabulary, the concepts, and the individual skills. This part applies all of them in sequence, on a single domain, for a company that looks like the kind of company that actually uses Cloudflare's free and Pro tiers to punch above its weight.

The fictional company is Meridian Stack. Twelve-person SaaS startup. They sell project analytics tooling to mid-market operations teams. They have a marketing site, a web app, an API layer, a status page, and a small internal toolset that shouldn't be publicly accessible. They use Google Workspace for email, Mailchimp for marketing sends, and SendGrid for transactional notifications. They're not enterprise. They don't have a security team. They have one technically capable founder and two developers who care about doing things right.

That's the test case for everything that follows.

The sequencing philosophy throughout this playbook is infrastructure before policy before access. You can't write a firewall rule for a subdomain that doesn't exist yet. You can't enforce Zero Trust access on a tunnel you haven't configured. Order matters. Every step in this playbook depends on the step before it being correct.

Who This Guide Is For

This guide is for readers who've worked through the earlier parts of this series, or who arrive with equivalent experience. You should be comfortable navigating the Cloudflare dashboard, understand what an A record and a CNAME record do, and have at least a passing familiarity with what Cloudflare Tunnel is and why it exists. If DNS propagation and orange-cloud vs. grey-cloud are familiar concepts, you're in the right place.

If you're brand new to Cloudflare, Parts 1 through 5 of this series will get you oriented before this playbook makes full sense.

How to Use This Playbook

Work through this in order. Each step builds on the previous one. The Meridian Stack examples aren't decorative. They show the exact record names, policy names, and configuration choices a real team would make, so you can adapt them directly to your own domain.

Step One. Acquiring and Registering Your Domain Through Cloudflare

Domain registration is the first infrastructure decision, and it has downstream consequences for everything else. Where your domain is registered determines how easily you can manage DNSSEC, how quickly you can update nameservers, and how much friction exists between you and your DNS configuration. Getting this right at the start saves real time later.

Why Buy Through Cloudflare Registrar

Cloudflare Registrar sells domains at cost. No markup. The price you pay is the wholesale registry price, which means .com domains run around $9 to $10 per year rather than the $15 to $20 that most retail registrars charge. That's a minor financial point. The more important point is that WHOIS privacy is included by default at no additional charge, which is not universal among registrars.

The operational advantage is tighter integration. When your registrar and your DNS provider are the same platform, DNSSEC activation is a single click rather than a multi-step process involving DS record submission to an external party. That matters in Step Four.

Transferring an Existing Domain vs. Registering Fresh

Meridian Stack is registering meridianstack.com for the first time, so the process is a direct purchase through the Cloudflare dashboard under the Registrar section. Fill in the contact details, confirm the registration period, and the domain is live within minutes.

For teams transferring an existing domain from another registrar, the process requires an EPP authorization code from the current registrar, which is sometimes called an auth code or transfer code. Request it from the current registrar's dashboard. Be aware of the 60-day transfer lock: ICANN rules prohibit transferring a domain that was registered or previously transferred within the last 60 days. Plan accordingly if you're working against a launch deadline.

Initial Nameserver Delegation

After registration, Cloudflare automatically assigns authoritative nameservers, typically in the format ns1.cloudflare.com and ns2.cloudflare.com with account-specific variants. For a fresh Cloudflare Registrar purchase, nameserver delegation is handled automatically. For transferred domains or domains pointed to Cloudflare from an external registrar, you update the nameserver fields in the external registrar's dashboard to the values Cloudflare provides.

DNS propagation after nameserver delegation typically completes within a few hours globally, though the full propagation window can extend to 48 hours in edge cases. Cloudflare's authoritative nameservers support TTL values as low as 1 minute on proxied records, which gives you tight control during migrations when you need to move fast without long cache windows trapping users on old IP addresses.

From day one, understand the distinction between orange-cloud records (proxied through Cloudflare, hiding your origin IP and enabling Cloudflare's security and performance features) and grey-cloud records (DNS-only, resolving directly to your origin). Most records for Meridian Stack's public-facing services will be orange-cloud. Records that need direct resolution, like mail exchanger records, stay grey.

Step Two. Building the DNS Foundation

DNS is the foundation that every other configuration sits on. Get it wrong and everything downstream is harder to debug. Get it right and the rest of the stack assembles cleanly.

Core A, AAAA, and CNAME Records for Meridian Stack

Meridian Stack needs the following records at minimum for a functional production environment:

meridianstack.com (root domain): A record pointing to the origin server IP, proxied (orange-cloud). This serves the marketing site.

www.meridianstack.com: CNAME pointing to meridianstack.com, proxied. This catches the www-prefixed traffic and routes it consistently.

app.meridianstack.com: A record pointing to the application server IP, proxied. This is the authenticated product environment.

api.meridianstack.com: A record pointing to the API server IP, proxied. Cloudflare's proxy layer provides DDoS protection and rate limiting here without any additional configuration.

status.meridianstack.com: CNAME pointing to their status page provider's hostname, grey-cloud. Status pages often need direct resolution to function correctly with external monitoring tools.

MX Records and Mail Routing Setup

Meridian Stack uses Google Workspace for company email. MX records must be grey-cloud only. Proxying MX records through Cloudflare will break mail delivery, because the Cloudflare proxy doesn't handle SMTP traffic.

Google Workspace requires five MX records with the following priority values: ASPMX.L.GOOGLE.COM at priority 1, ALT1.ASPMX.L.GOOGLE.COM and ALT2.ASPMX.L.GOOGLE.COM at priority 5, and ALT3.ASPMX.L.GOOGLE.COM and ALT4.ASPMX.L.GOOGLE.COM at priority 10. These values come directly from Google's workspace setup documentation and shouldn't be approximated.

Third-party service verification records, like the TXT records Stripe and Intercom require to confirm domain ownership, go into DNS as plain TXT records at the root or at specified subdomains. They don't need to be proxied. Add them as grey-cloud TXT records and they'll resolve correctly for the verification systems that check them.

TTL Strategy for a Production Environment

TTL decisions carry real operational weight. During a migration or initial setup, set TTLs low, around 300 seconds (5 minutes), so that if you need to correct a record, the old value expires quickly and clients pick up the new one without a long wait.

After the configuration is stable and tested, raise TTLs on records that don't change frequently. A root domain A record that points to a stable origin server can reasonably carry a TTL of 3600 seconds (1 hour) or higher. Higher TTLs reduce query volume against Cloudflare's nameservers and improve resolution speed for end users whose local resolvers cache the record.

Wildcard DNS records, written as *.meridianstack.com, match any subdomain not explicitly defined. They're useful for development environments where you're spinning up temporary subdomains, but they carry risk in production: a wildcard will resolve traffic to subdomains you didn't intend to expose. Use wildcards deliberately and with a matching Cloudflare rule to handle or block unexpected subdomain traffic.

SRV records are less common in SaaS environments but occasionally required by communication tools or internal services. Add them as needed using Cloudflare's SRV record type in the DNS editor, which provides structured fields for priority, weight, port, and target rather than requiring you to format the raw record string manually.

Step Three. SSL/TLS Configuration and HTTPS Enforcement

SSL configuration is where a lot of teams make a choice that seems fine in development and becomes a security problem in production. The setting you choose here determines whether data between Cloudflare and your origin server is actually encrypted or just encrypted between the user and Cloudflare's edge.

Choosing the Right SSL Mode: Full Strict Explained

Cloudflare offers four SSL modes: Off, Flexible, Full, and Full (Strict). Full (Strict) is the only mode that's appropriate for a production environment. It requires a valid SSL certificate on your origin server, either a certificate from a trusted CA or a Cloudflare Origin Certificate, and it validates that certificate on every connection from Cloudflare to your origin.

Cloudflare Origin Certificates are free, available in the dashboard under SSL/TLS, and valid for up to 15 years. They're trusted by Cloudflare's proxy but not by browsers directly, which means they only work correctly when Cloudflare's proxy is active. For Meridian Stack's origin servers, these are the right choice: they eliminate certificate renewal overhead and work seamlessly with Full (Strict) mode.

Edge Certificates, Always Use HTTPS, and HSTS

Cloudflare's Universal SSL provisions edge certificates automatically after a domain is added. The provisioning process typically completes within 15 minutes for most domains, though it can take up to 24 hours in cases where DNS propagation is slow or the domain has unusual configuration.

Enable Always Use HTTPS in the SSL/TLS settings. This forces a 301 redirect from any HTTP request to the HTTPS equivalent. It's a one-toggle change that eliminates the entire class of mixed-content and cleartext access issues.

HSTS (HTTP Strict Transport Security) goes further. Once a browser sees an HSTS header, it refuses to make HTTP connections to that domain for the duration of the max-age period. Cloudflare lets you set this at the edge, including the preload directive, which submits the domain to browser preload lists. The preload commitment is serious: it sets a minimum 12-month max-age and is difficult to reverse. Don't enable preload until the domain is fully committed to HTTPS with no HTTP fallback requirements.

Minimum TLS Version and Cipher Suite Hardening

Set the minimum TLS version to TLS 1.2 in the SSL/TLS settings. TLS 1.0 and 1.1 have known vulnerabilities and are deprecated by all major browser vendors. There's no legitimate reason to support them in a new SaaS deployment.

Cloudflare manages cipher suite selection at the edge, and the default configuration in the current dashboard already excludes the weakest options. For most teams on the Pro tier, the default cipher configuration is acceptable. The minimum TLS version setting is the meaningful lever available at this tier, and setting it to 1.2 is the right call for Meridian Stack's environment.

Step Four. DNSSEC: Locking Down the Chain of Trust

DNS is, at its core, an unauthenticated system. When a resolver asks for the IP address of app.meridianstack.com, nothing in the base protocol proves that the answer came from Meridian Stack's legitimate nameservers rather than from a poisoned cache or an attacker intercepting the query. DNSSEC fixes that by adding cryptographic signatures to DNS responses.

What DNSSEC Actually Protects Against

DNS cache poisoning is the attack where a malicious actor inserts false DNS records into a resolver's cache. A user trying to reach Meridian Stack's app gets directed to an attacker-controlled server instead. DNS spoofing is the broader category: any technique that causes a resolver to return fraudulent DNS data. For a SaaS company, these attacks can redirect customer logins to credential-harvesting pages. The consequences are significant and the attack surface is real.

DNSSEC doesn't encrypt DNS queries. It authenticates them. Each DNS response carries a cryptographic signature that resolvers can verify against a chain of trust running from the root zone down to the specific domain. A poisoned record fails signature verification and gets rejected.

Enabling DNSSEC and Adding the DS Record

Enabling DNSSEC is a two-part job. Cloudflare signs the zone, and the parent zone, which for Meridian Stack is the .com registry, has to publish a DS record that tells resolvers which key to trust. Without the DS record the signatures exist, but nothing links them to the chain.

In the Cloudflare dashboard, open the zone, go to DNS, then Settings, and select Enable DNSSEC. Cloudflare generates the keys and shows the DS record values: key tag, algorithm, digest type, and digest. Meridian Stack registered through Cloudflare Registrar in Step One, so Cloudflare can publish the DS record for them, and the dashboard will tell you whether anything is left to do. For a domain registered elsewhere, you copy those four values into the registrar's DNSSEC settings by hand.

Verifying the Chain of Trust

Don't assume it worked. The DS record has to appear at the registry before validation succeeds, and a mismatched DS record is the one DNSSEC failure that makes a domain unreachable for validating resolvers. Check it with dig against a validating resolver:

dig +dnssec meridianstack.com A @1.1.1.1
dig DS meridianstack.com +short

In the first response, look for the ad flag in the header. It means the resolver verified the signatures. The second command should return the DS record you published. If you'd rather see the chain drawn out, a DNSSEC visualizer such as DNSViz shows each link from the root down and highlights the one that's broken.

Step Five. Email Authentication: SPF, DKIM, and DMARC

Meridian Stack sends mail from three places: Google Workspace for people, Mailchimp for marketing, and SendGrid for transactional notifications. Each of them can send as @meridianstack.com, and without authentication, so can anyone else. SPF, DKIM, and DMARC are the three DNS records that let receiving servers tell the difference. All three are plain DNS records, and none of them should be proxied.

SPF: Declaring Who May Send

An SPF record is a single TXT record at the root of the domain that lists every service allowed to send mail for it. For Meridian Stack:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

Each include: hands trust to one provider, and ~all soft-fails everything else. Two rules trip people up. A domain can have only one SPF record, and a second one invalidates both, so new providers get added to the existing record. SPF also limits evaluation to ten DNS lookups, and every include: counts toward that limit, including the includes nested inside it. Check each provider's current documentation for its include value, because providers change them.

DKIM: Signing the Mail Itself

DKIM attaches a cryptographic signature to every message, and the matching public key lives in DNS. Each provider signs with its own key, so Meridian Stack ends up publishing a few DKIM records, one set per sender.

• Google Workspace: generate the key in the Admin console's email authentication settings, then publish the TXT record it shows under the google._domainkey hostname.
• SendGrid: complete domain authentication in the SendGrid dashboard. It supplies a small set of CNAME records, including _domainkey ones, that let SendGrid sign mail with your domain.
• Mailchimp: authenticate the domain in the Mailchimp settings. It supplies CNAME records for its DKIM keys.

Every one of these goes in as DNS only, the grey cloud. The exact hostnames and values come from each provider's dashboard, so copy them exactly rather than retyping them from a guide.

DMARC: Telling Receivers What to Do

DMARC ties SPF and DKIM to the address people actually see in the From line, and tells receiving servers what to do when the checks fail. Start in monitoring mode:

_dmarc.meridianstack.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

With p=none, delivery doesn't change at all. The rua address receives aggregate reports that show who is sending mail as your domain. Watch them for a few weeks, fix any legitimate sender that fails alignment, then move to p=quarantine, and to p=reject once the reports are clean. That tightening is on the Month 1 list at the end of this playbook.

Step Six. Deploying Cloudflare Tunnel for Origin Protection

Steps Four and Five locked down the DNS layer with DNSSEC signing and SPF, DKIM, and DMARC email authentication. The domain is verified, the records are clean, and the security posture at the DNS layer is solid. Now the work moves to the origin server itself, and specifically to removing it from the public internet entirely.

Installing and Authenticating cloudflared on the Origin Server

Cloudflare Tunnel runs through a lightweight daemon called cloudflared. On Meridian Stack's Ubuntu origin server, installation starts with the official Cloudflare package repository rather than a direct binary download. This keeps the daemon in the system package manager and makes future updates a single apt upgrade away.

1# Add the Cloudflare GPG key and package repo
2curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null
3
4echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
5
6sudo apt update && sudo apt install cloudflared

Authentication happens next. Running cloudflared tunnel login opens a browser window and writes a certificate to ~/.cloudflared/cert.pem after you authorize the correct Cloudflare account. Once authenticated, create the named tunnel:

cloudflared tunnel create meridian-prod

This generates a tunnel UUID and drops a credentials JSON file into ~/.cloudflared/. That UUID is the identifier everything else references.

Configuring Ingress Rules for Multiple Services

The config.yml file lives at /etc/cloudflared/config.yml and tells the daemon where to route incoming traffic. Meridian Stack runs two services: a Node application on port 3000 and a REST API on port 8080.

1tunnel: meridian-prod
2credentials-file: /root/.cloudflared/<UUID>.json
3
4ingress:
5  - hostname: app.meridianstack.com
6    service: http://localhost:3000
7  - hostname: api.meridianstack.com
8    service: http://localhost:8080
9  - service: http_status:404

The final catch-all rule is required. Without it, cloudflared rejects the config at startup. With it, any request that doesn't match a defined hostname gets a clean 404 rather than an error.

DNS records get created automatically using the tunnel route command:

cloudflared tunnel route dns meridian-prod app.meridianstack.com
cloudflared tunnel route dns meridian-prod api.meridianstack.com

This writes CNAME records pointing each hostname to the tunnel UUID's .cfargotunnel.com address. No manual DNS editing required.

Removing Public Inbound Ports Entirely

This is the step most teams skip, and it's the one that matters most. A tunnel is only as secure as the firewall behind it. If port 443 is still open to the world on the origin, the tunnel is a convenience feature, not a security control.

Lock it down with ufw:

1# Drop all inbound 80 and 443 by default
2sudo ufw deny 80/tcp
3sudo ufw deny 443/tcp
4
5# Allow only Cloudflare IP ranges (IPv4 example — repeat for IPv6)
6for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
7  sudo ufw allow from $ip to any port 80,443 proto tcp
8done

Cloudflare publishes its IP ranges at cloudflare.com/ips and updates them infrequently, but they do change. Automate this refresh with a monthly cron job so the allowlist doesn't drift.

Finally, install cloudflared as a systemd service so it survives reboots:

1sudo cloudflared service install
2sudo systemctl enable cloudflared
3sudo systemctl start cloudflared

The origin server now has no publicly reachable ports on 80 or 443. Traffic arrives only through the tunnel, which means only after passing through Cloudflare's edge network, its WAF, its DDoS mitigation, and any Access policies applied in front of the hostnames.

Step Seven. Zero Trust Access Policies with Cloudflare Access

The tunnel protects the origin at the network layer. Access protects the application layer. These two controls work together, and neither one alone is sufficient for internal tools that handle sensitive operations.

Setting Up the Zero Trust Organization and Auth Provider

Zero Trust configuration lives in a separate section of the Cloudflare dashboard under the Zero Trust navigation item. The first step is establishing the team domain. For Meridian Stack, that's meridianstack.cloudflareaccess.com. This domain becomes the authentication portal users see when they try to reach a protected application.

Identity provider configuration comes next. Connecting Google Workspace takes about four minutes. Navigate to Settings, then Authentication, then add a new provider. Select Google, enter the OAuth client ID and secret from the Google Cloud Console, and save. Cloudflare handles the OAuth flow from there.

Protecting the Admin Panel and Internal Tools

Create an Access Application for admin.meridianstack.com through the Zero Trust dashboard. The application type is Self-hosted. The policy configuration is where the real work happens.

First policy: allow only email addresses ending in @meridianstack.com. This blocks personal Gmail accounts even if someone knows the URL. Second policy layer, scoped to the /deploy path: require membership in the Engineering Google Group. This means a contractor with a @meridianstack.com email can reach the admin panel but can't trigger deployments.

Session duration for the admin panel is set to eight hours with re-authentication required after 24 hours of inactivity. For the /deploy path specifically, drop that to two hours. Deployments are high-stakes actions and short session windows limit the blast radius of a compromised session.

Service Tokens for Machine-to-Machine Access

The CI/CD pipeline needs to hit the API without a browser. Browser-based OAuth doesn't work for automated systems. Service tokens solve this cleanly.

Create a service token in the Access dashboard under Service Auth. This generates a Client ID and Client Secret. The pipeline passes these as HTTP headers:

CF-Access-Client-Id: <client-id>
CF-Access-Client-Secret: <client-secret>

Cloudflare validates the token against the Access policy before the request reaches the origin. The pipeline never needs a user account, a session cookie, or a browser. Rotate service tokens quarterly as part of the maintenance cycle covered in the final section of this article.

Step Eight. WARP and Private Network Access for the Team

Access policies protect public-facing internal tools. WARP extends that protection to resources that should never be publicly reachable at all. The Postgres admin UI at 10.0.1.5 is a good example. It lives on a private subnet. It should stay there.

Enrolling Devices into the Meridian Stack Fleet

WARP installation is straightforward on macOS, Windows, and Linux. The configuration step that matters is the organization login. After installing the client, navigate to Preferences, then Account, then click "Login with Cloudflare for Teams" and enter meridianstack.cloudflareaccess.com. The device enrolls against the Zero Trust organization and becomes subject to device policies.

Device enrollment policies add a verification layer. Require either a managed device certificate issued by the company's MDM, or a minimum OS version (macOS 14 or later, Windows 11 or later). Unmanaged personal devices fail enrollment and stay off the private network.

Split Tunnel Configuration to Avoid Routing All Traffic

By default, WARP routes all traffic through Cloudflare's network. That's useful for threat filtering but adds latency for general internet browsing and creates unnecessary dependency on Cloudflare's infrastructure for everyday tasks.

Configure split tunneling to route only RFC 1918 ranges and internal hostnames through WARP:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• Internal hostnames like *.meridianstack.internal

Everything else goes directly to the internet. This keeps the VPN-like overhead minimal and avoids the performance complaints that kill adoption of internal network tools.

Accessing Private RFC 1918 Resources Over WARP

Add a private network route to the tunnel configuration so enrolled WARP clients can reach the Postgres admin UI:

warp-routing:
  enabled: true

Then add the private network in the Zero Trust dashboard under Networks, Private Networks, and enter 10.0.1.0/24. WARP clients resolve that subnet through the tunnel without any additional configuration on the client side.

Gateway DNS policies round out the device security picture. Create policies that block Malware and Phishing categories for all enrolled devices. These apply at the DNS resolution layer, which means the block happens before a connection is established.

Step Nine. Monitoring, Analytics, and Alerting

Configuration without visibility is just hope. Meridian Stack's security posture is only as strong as the team's ability to detect when something changes, degrades, or fails.

Cloudflare Analytics: What to Watch and What to Ignore

The Zone Analytics dashboard shows requests, bandwidth, cache hit ratio, and a threat map. Most teams glance at the request graph and move on. The metric that actually tells you something useful is cache hit ratio.

A healthy cache hit ratio for a typical web application sits above 80 percent. Below 60 percent means Cache Rules need attention. Common fixes include adding cache rules for static asset paths, setting appropriate Cache-Control headers on the origin, and ensuring query string parameters that don't affect content aren't busting the cache unnecessarily.

Setting Up Notifications for DDoS, Certificate Expiry, and Health Checks

Create a Health Check for the origin under Traffic, Health Checks. Set the interval to 60 seconds, the threshold to two consecutive failures, and the notification method to email. The check should target the origin IP directly, not the Cloudflare hostname, so it tests actual origin availability.

Notifications worth configuring: SSL certificate expiry at 30 days, DDoS attack detected (any threshold), and tunnel health degraded. All three live under Notifications in the account dashboard.

Using Logpush for Long-Term Retention (Pro and Above)

Logpush exports HTTP request logs, firewall event logs, and DNS logs to an external destination. Cloudflare R2 is the lowest-friction option since it's native to the platform. For teams with an existing SIEM, direct integration with Splunk, Datadog, or an S3-compatible bucket is fully supported.

Logpush configuration lives under Analytics, then Logs, then Logpush in the dashboard. Select the dataset (HTTP requests is the starting point), choose the destination, and define the log fields to export. Compliance-grade retention typically requires 90 days minimum. Plan the storage budget accordingly.

The Complete Meridian Stack Configuration Checklist

Twenty steps across nine configuration areas. Here's the full sequence, ordered by dependency, with time estimates and plan requirements annotated.

Free Account Maximum-Value Configuration

Everything below marked Free is achievable without a paid Cloudflare plan. The Pro annotations indicate where the ceiling appears.

What to Do First, Second, and Third: The Sequenced Roadmap

Day 1 must-haves: Domain active on Cloudflare nameservers, SSL on Full Strict, tunnel deployed, origin firewall locked. These four items eliminate the most common attack vectors before anything else.

Week 1 should-haves: DNSSEC signed, email authentication complete, Access policies protecting internal tools, WARP enrolled on all team devices. This layer closes the identity and DNS attack surfaces.

Month 1 nice-to-haves: Logpush configured, Cache Rules tuned, DMARC policy tightened from p=none to p=quarantine, service tokens rotated after initial setup, runbook written and reviewed by a second team member.

The most common mistake at the domain transfer stage is not updating TTLs before the transfer, which causes propagation delays. The most common tunnel mistake is forgetting the catch-all ingress rule. The most common Access mistake is creating policies without testing them from an incognito window and a non-allowlisted account before telling the team they're live.

What Meridian Stack Looks Like When You're Done

The twelve-person company you started with now has a domain it controls, a DNS table someone thought through, HTTPS enforced end to end, a signed zone, authenticated email, an origin with no open inbound ports, access policies in front of every internal tool, enrolled devices, and alerts that fire before customers notice anything. None of it required an enterprise contract or a security team. It required doing the work in the right order.

Infrastructure before policy before access, then monitor everything. That's the whole playbook in one line.

You've now seen the configuration done correctly, in order. Part 21, Cloudflare Mistakes Beginners Make (And How to Fix Them), flips the lens and goes through the errors that show up most often when it's done wrong, from Flexible SSL to broken MX records to exposed admin panels, and how to recover from each one.