Cloudflare DNS Setup Guide: Records, Nameservers, Email, SSL, and Troubleshooting

Overview

DNS connects a domain name to services such as a website, mail provider, verification system, or application server. Cloudflare can manage the authoritative DNS for your domain and can optionally proxy supported web traffic through its network. These are separate functions: DNS answers where a hostname should go, while proxying changes how web traffic is routed and protected.

Before changing anything, record the DNS configuration at your current provider. Export it if the provider supports exports, or copy each record into a simple table containing the hostname, record type, value, time to live, and purpose. Include less obvious records such as verification entries, subdomains used by applications, and mail-related records. A missing TXT or CNAME record can interrupt a service even when the main website still loads.

A typical Cloudflare DNS setup has these stages:

1. Add the domain to Cloudflare and review the records it detects.
2. Compare the detected records with your source inventory.
3. Change the domain's nameservers at the registrar to the Cloudflare nameservers assigned to the zone.
4. Configure website, application, email, and verification records.
5. Review proxy status, SSL settings, DNSSEC, and email authentication.
6. Test from more than one network and keep a record of the final configuration.

Cloudflare's dashboard labels and available options may change over time, so use the current interface together with the principles below. For background on pointing a domain to a server, see How to Point a Domain to a VPS.

Checklist by scenario

Moving DNS management to Cloudflare

• Inventory first: List the root domain, www, application subdomains, mail records, verification records, and any services that depend on DNS.
• Add the domain: Create the zone in Cloudflare using the exact domain name. Do not assume that automatic scanning found every record.
• Compare records: Check Cloudflare against the old DNS provider line by line. Pay special attention to MX, TXT, DKIM, and records for subdomains.
• Change nameservers: At the domain registrar, replace the existing authoritative nameservers with the pair assigned by Cloudflare. Do not change nameservers at the hosting provider unless that provider is also your registrar or DNS host.
• Confirm delegation: Use a DNS propagation check or a command-line lookup to confirm that different resolvers are beginning to return Cloudflare's nameservers.
• Keep the old zone available: Avoid deleting the previous DNS configuration until the new zone has been tested and the transition is complete.

Pointing a website or VPS to Cloudflare

For a server with a public IPv4 address, create an A record for the root domain and, if needed, another for a subdomain such as www. An AAAA record is used for an IPv6 address. Add it only when the server and network are correctly configured for IPv6; an incomplete IPv6 setup can send some visitors to a broken address.

A CNAME record points one hostname to another hostname. It is commonly used for www or hosted services that provide a destination hostname instead of a fixed IP address. Follow the destination service's exact hostname and verification instructions rather than substituting an IP address.

• Use the root hostname, often shown as @, for the apex domain record.
• Use only the hostname portion in the Name field when the dashboard asks for a relative name, such as www rather than www.example.com.
• Check whether the record is proxied or DNS-only. Proxying is generally relevant to supported web traffic, not mail delivery or every arbitrary protocol.
• Make sure the web server accepts the domain in its virtual host configuration and that its TLS certificate covers every hostname visitors will use.

If the application runs in Docker on a VPS, DNS is only one part of the launch process. The container, reverse proxy, firewall, and HTTPS configuration must also be correct. The guide How to Deploy an Open-Source App on an Ubuntu VPS with Docker and HTTPS covers that wider deployment sequence.

Setting up email records

Mail delivery depends primarily on the records supplied by your email provider. Add each provider's MX record exactly as documented, including priority where required. Do not proxy MX records or mail hostnames through Cloudflare; they should resolve directly to the mail service.

Most providers also require authentication records:

• SPF: A TXT record that identifies which systems are allowed to send mail for the domain. Keep one coherent SPF policy rather than publishing several separate SPF records.
• DKIM: Usually a TXT or CNAME record at a selector-specific hostname. Copy the selector and value exactly, including long keys or provider-specific formatting.
• DMARC: A TXT record at _dmarc that tells receiving systems how to handle messages that do not align with the domain's authentication policy. Start with a policy appropriate to your level of monitoring and change it deliberately.

Use the detailed SPF, DKIM, and DMARC Setup Guide when you need to validate an email configuration. Test both sending and receiving after a DNS change, including messages sent from contact forms and transactional applications.

Adding verification and service records

Search consoles, SaaS platforms, certificate systems, and developer tools may ask for a TXT, CNAME, or occasionally an MX record to verify ownership. Add the record at the exact hostname specified by the service. Preserve punctuation, underscores, capitalization where relevant, and any trailing period conventions shown by the provider. Once verification succeeds, do not remove the record unless the service explicitly says it is no longer needed.

What to double-check

Proxy status and record type

Review the cloud icon or equivalent proxy control for every record. A web hostname may be suitable for proxying, while an email hostname, verification record, database endpoint, or non-HTTP service may need to remain DNS-only. If an application requires the visitor's original IP address or uses a protocol not supported by the chosen routing mode, confirm its requirements before enabling proxying.

SSL mode and origin encryption

Cloudflare's edge SSL setting and the certificate installed on the origin server are related but not interchangeable. Choose a mode that matches whether the origin has a valid certificate and whether encrypted traffic is required between Cloudflare and the server. Avoid treating an edge certificate as proof that the origin is correctly configured. Test the domain over HTTPS, check redirects, and confirm that the application generates secure links and does not create redirect loops.

DNSSEC and registrar access

DNSSEC adds validation to DNS responses, but it must be configured consistently between Cloudflare and the registrar. Follow Cloudflare's current instructions for creating or copying the required DS information, then verify the status from both sides. Do not enable DNSSEC at one layer while leaving stale delegation data at another. If DNSSEC is being transferred from an existing provider, plan the change rather than removing keys without understanding the current chain of trust.

Propagation and authoritative answers

DNS changes do not appear everywhere at the same moment. Cached answers can remain available until their time to live expires, and different networks may use different recursive resolvers. A DNS propagation check is useful, but it is not a single final verdict. Query the authoritative nameservers directly, then compare results through more than one public or local resolver.

Useful checks include:

• Confirming the domain's delegated nameservers.
• Querying the A, AAAA, CNAME, MX, and TXT records separately.
• Testing the website from a separate network, such as mobile data.
• Sending a test email to an address at a different mail provider and checking the message headers.
• Checking the origin server logs if the domain resolves but the application returns an error.

Common mistakes

• Changing the wrong nameservers: Editing DNS records at Cloudflare has no effect if the registrar still delegates the domain to another DNS provider.
• Assuming scanning is complete: Automated import can miss records that are rarely queried or managed by a separate service.
• Creating duplicate SPF records: Combine authorized senders into the provider-supported SPF policy instead of publishing multiple policies.
• Proxying mail records: MX targets and mail-related hostnames normally need direct DNS resolution.
• Adding an incorrect AAAA record: A partially configured IPv6 address can cause inconsistent failures that affect only some visitors.
• Using the wrong hostname: A verification record for _dmarc, a DKIM selector, or an application subdomain must be placed at its precise name.
• Changing several variables at once: If you change nameservers, origin IPs, SSL mode, and application configuration together, isolate each layer before troubleshooting.
• Deleting the old DNS zone immediately: Keep a dated copy until websites, email, verification, and subdomains have all been tested.

When to revisit

Review this checklist whenever you migrate hosting, add a new email sender, launch a subdomain, change an application server, renew or replace an origin certificate, or move a domain between registrars. It is also worth reviewing before seasonal planning cycles when campaign landing pages, transactional email, or temporary services may be introduced.

Keep a small DNS change log with the date, record changed, reason, previous value, new value, and person responsible. Recheck the zone when a team member changes, a SaaS provider changes its setup instructions, or your deployment workflow changes. Tools and dashboard workflows can evolve, so confirm current provider documentation before enabling DNSSEC, modifying SSL behavior, or publishing email authentication policies.

For a practical final pass, work through this sequence:

1. Export or copy the current DNS records.
2. Verify nameserver delegation at the registrar.
3. Test the root domain, www, application subdomains, and IPv6 if used.
4. Check MX, SPF, DKIM, and DMARC records and send test messages.
5. Review proxy status, HTTPS behavior, origin certificates, and redirects.
6. Check DNSSEC status if enabled.
7. Record the confirmed configuration and keep the backup until the change is stable.

When a problem remains, identify the failing layer first: delegation, DNS record, proxy route, TLS connection, origin server, or application. That distinction turns a vague DNS outage into a finite troubleshooting task.