Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types

Overview

Use this article as a working checklist before you change DNS, not just after something breaks. The goal is simple: reduce trial and error when connecting domains to web apps, APIs, email services, or self-hosted infrastructure through Cloudflare.

A useful way to think about Cloudflare DNS setup is to separate three concerns:

• Routing: Which record sends traffic or verification requests to the right destination?
• Proxying: Should Cloudflare sit in front of the origin, or should the record be DNS-only?
• Validation: How will you confirm the change actually works from both DNS and application perspectives?

For most teams, the recurring record types are straightforward:

• A record: Points a hostname to an IPv4 address.
• AAAA record: Points a hostname to an IPv6 address.
• CNAME record: Points one hostname to another hostname.
• TXT record: Used for verification, email authentication, and other text-based DNS metadata.
• MX record: Routes email for a domain to mail servers.

Before changing anything, capture the current state. Export or screenshot existing records, note the intended destination, and list which hostnames are in scope. This small habit saves time when you need to roll back or compare a failed configuration with the previous working state.

If you are troubleshooting propagation or trying to verify whether a change is visible from multiple resolvers, keep a separate validation workflow handy. Our DNS Propagation Checker Guide: How to Verify Record Changes and Troubleshoot Delays is a useful companion when you want to confirm whether the issue is DNS, cache, or the upstream service itself.

Checklist by scenario

This section groups the most common Cloudflare DNS tasks by outcome rather than by record type. That makes it easier to return to this guide when you are launching something under time pressure.

1. Point the root domain to a server or hosting platform

Use this when connecting example.com to a VM, VPS, dedicated host, or supported platform endpoint.

1. Identify the origin destination. If you have an IP address, you will usually use an A record. If the provider gives you a hostname, you may use a CNAME where appropriate.
2. Create or update the record for the root hostname, often shown as @ in DNS interfaces.
3. Choose the proxy setting intentionally. If the origin is a normal web app and you want Cloudflare in front, proxying may make sense. If the destination is not compatible with HTTP proxying or needs direct DNS resolution, use DNS-only.
4. Set a sensible TTL if you have the option. For planned changes, shorter TTLs can make later adjustments easier. For stable records, a standard automatic setting is often fine.
5. Verify that the origin server is prepared to answer for the domain. DNS can be correct while the web server still returns the wrong site or certificate.

Best reminder: DNS setup and origin configuration are separate tasks. A correct Cloudflare A record will not fix a server block, virtual host, or TLS mismatch at the origin.

2. Add a subdomain for an app, API, or preview environment

This is the most common cloudflare subdomain setup workflow. Typical examples include app.example.com, api.example.com, or staging.example.com.

1. Decide whether the subdomain points to an IP or another hostname.
2. Use an A record for an IP target, or a CNAME record for a hostname target.
3. Confirm whether the provider expects the subdomain to be proxied or DNS-only. Some managed platforms work best with one mode or the other.
4. If the service performs domain verification, add any required TXT or CNAME verification records before switching production traffic.
5. Test the subdomain directly after the DNS record resolves. Check application health, redirects, and TLS behavior.

If your team regularly provisions temporary environments, standardize a naming pattern and document whether those records should be manual, API-driven, or managed with infrastructure as code. That small process improvement turns ad hoc DNS work into something closer to dns automation.

3. Add a CNAME record in Cloudflare

For teams searching how to add cname record cloudflare, the practical question is usually not where to click but what the alias should represent.

1. Set the Name field to the hostname you want to create, such as www or docs.
2. Set the Target to the canonical hostname provided by your hosting or SaaS vendor.
3. Avoid pointing a CNAME to a full URL. DNS records use hostnames, not paths like /login or protocol prefixes like https://.
4. Check for conflicts. A hostname that already has an A, AAAA, or other incompatible record may need cleanup before the CNAME can work as expected.
5. Validate both DNS resolution and application behavior after the record is live.

Common use cases include pointing www to a platform hostname, linking a docs subdomain to a hosted documentation service, or routing a marketing subdomain to a site builder while leaving the root domain elsewhere.

4. Add an A record in Cloudflare

A cloudflare a record is usually the right choice when you control the server and have a stable IPv4 address.

1. Enter the hostname, such as @, app, or api.
2. Enter the destination IPv4 address carefully. One digit wrong is enough to produce a hard-to-diagnose failure.
3. Confirm the server is listening for the correct hostname and port combination.
4. Review proxy mode. If you are exposing a non-web service, proxying may not be appropriate.
5. Check whether a firewall or security group allows traffic from the expected path.

If your server IP changes often, an A record may be the wrong long-term fit. That is a sign to consider a stable ingress layer, a platform hostname behind a CNAME, or a more automated workflow using an API or Terraform-managed records.

5. Add a TXT record for verification or policy

A cloudflare txt record is often used for domain verification, ownership proofs, and email-related policies such as SPF, DKIM, and DMARC.

1. Copy the exact TXT value from the service asking for verification.
2. Enter the hostname exactly as required. Some services want the root domain, while others require a prefixed name such as _dmarc or a token-specific label.
3. Preserve punctuation. Quotation handling varies by interface, but the underlying string must remain intact.
4. If the service says verification failed, check for duplicate or conflicting TXT values at the same hostname.
5. Wait for propagation before rechecking. Repeated edits during propagation can make troubleshooting harder.

Email authentication deserves extra care. SPF, DKIM, and DMARC setups often fail because teams mix records from old providers with new ones. If email is part of your domain rollout, treat DNS and mail configuration as one coordinated change set rather than separate tasks.

6. Set up MX records for email

When you move email providers or add custom domain mail, DNS mistakes can interrupt delivery quickly.

1. Remove or archive obsolete MX values before adding new ones, unless your migration plan explicitly requires overlap.
2. Enter all MX records required by the mail provider, including the correct priorities.
3. Verify accompanying TXT records such as SPF and any provider verification values.
4. Test both inbound and outbound mail after propagation.
5. Keep a rollback note with the previous MX settings until the new configuration is stable.

Cloudflare DNS can host these records cleanly, but it will not validate whether your mail provider setup is complete. Treat mail as a separate production service with its own checklist.

7. Connect Cloudflare DNS to a reverse proxy or self-hosted stack

This is common for teams using Nginx, Caddy, Traefik, or a container-based edge on a Linux server.

1. Create the DNS record for the intended hostname.
2. Ensure the reverse proxy has a matching server name or host rule.
3. Confirm the upstream app is reachable from the proxy layer.
4. Check TLS issuance and renewal if certificates are managed at the proxy.
5. Test both the hostname and any redirect logic from root to subdomain or from HTTP to HTTPS.

If you are combining DNS setup with server provisioning, keep DNS changes late in the sequence. Finish server readiness first, then cut traffic. That reduces the time users can resolve a hostname to a not-yet-working service.

What to double-check

Most failed Cloudflare DNS changes come down to a few repeatable issues. Before you save or immediately after you save, review these items.

• Right hostname: Are you editing @, www, or a specific subdomain? Root and subdomain mistakes are common.
• Right destination type: IP address means A or AAAA; hostname means CNAME in most cases.
• No protocol or path in the target: DNS records should not contain http://, https://, or URL paths.
• Proxy mode is intentional: Orange-cloud versus DNS-only is not a cosmetic choice. It changes request flow and troubleshooting paths.
• TTL expectations are realistic: Even with low TTLs, intermediate caches and application-level assumptions can create delay.
• Origin is configured: Your server, hosting platform, or reverse proxy must already know how to serve the hostname.
• Verification records are exact: TXT and token-style records fail when spacing, prefixes, or labels are slightly wrong.
• No duplicate intent: Avoid leaving old records that point the same hostname somewhere else unless you explicitly need them.

For higher-change environments, consider keeping a simple runbook with three columns: hostname, intended destination, and validation command. That small operational habit improves developer productivity more than adding another dashboard. If you eventually move to API-based changes, the same runbook becomes the blueprint for automation.

Common mistakes

This section is here for the problems that feel subtle when you are in the middle of a rollout but look obvious in hindsight.

Mixing proxy assumptions with DNS-only services

Not every service should sit behind Cloudflare proxying. If the endpoint is not standard web traffic, or if a vendor specifically expects direct resolution, forcing the proxied setting can create confusing failures.

Using the right record with the wrong hostname

Teams often mean to update www but edit the root domain, or they add a record for app when the service expects api. Be exact about the public hostname users and integrations will call.

Leaving stale records in place

Old TXT records, previous MX values, and duplicate verification tokens can all create ambiguity. Clean DNS is easier to troubleshoot than DNS that reflects every historical experiment.

Assuming propagation is the only problem

When a hostname does not work right away, the instinct is often to blame DNS caches. Sometimes that is true, but many issues are actually at the origin: missing virtual host config, invalid certificate coverage, redirect loops, or a platform that has not finished domain verification. DNS is only one layer of the path.

Changing too many variables at once

If you update DNS, move hosting, change TLS, and switch email providers in the same window, you create too many unknowns. Stage the work where possible. Validate one layer before moving to the next.

Skipping written validation steps

A successful DNS change should be testable. At minimum, define how you will check resolution, HTTP response, and service-specific health. Teams that write these checks down once can reuse them across every new launch.

When to revisit

Cloudflare DNS setup should be reviewed whenever the surrounding infrastructure changes, not just when something breaks. The most practical times to revisit this checklist are:

• Before a launch: New site, app, API, customer environment, or migration.
• Before seasonal planning cycles: Review what domains, subdomains, and mail records are still in active use.
• When workflows or tools change: New hosting provider, new reverse proxy, new email platform, or a shift toward Terraform or API-driven DNS.
• After an incident: Capture the exact record state and turn the fix into a permanent checklist item.
• During cleanup: Remove stale preview environments, outdated verification records, and unused hostnames.

A good maintenance routine is lightweight:

1. List every production hostname and its owner.
2. Confirm the destination for each record is still correct.
3. Check whether proxy settings still match the service type.
4. Review TXT, MX, SPF, DKIM, and DMARC entries for obsolete values.
5. Document a validation path for each critical hostname.
6. If you make frequent changes, decide whether manual edits should become API or Terraform workflows.

The real productivity gain is not memorizing every record type. It is building a repeatable method for adding, reviewing, and validating DNS changes so the next launch is quieter than the last one. Keep this checklist close to your deployment notes, and revisit it any time your hosting, email, or domain strategy changes.