Setting Up Cloudflare DNS, SSL and Email Records the Right Way

Why Cloudflare DNS, SSL and Email Records Must Work Together

Moving your domain’s DNS to Cloudflare is usually a smart decision: you gain fast Anycast DNS, a global CDN, DDoS protection and useful security tools. But if DNS, SSL and email records are not configured correctly, you can easily end up with a website that throws SSL warnings, emails that stop arriving, or random outages that are hard to debug. In our work at dchost.com, we often see the same pattern: someone enables the orange cloud icon, picks a random SSL mode, migrates MX records in a hurry, and then spends days chasing subtle issues.

This guide walks through a clean, production-ready setup for Cloudflare DNS and SSL with a special focus on three critical topics: which DNS records should be orange-cloud proxied, how to use Cloudflare’s Full (strict) mode correctly, and how to keep your email DNS records safe and reliable. We will use practical scenarios you are likely to encounter on shared hosting, VPS and dedicated servers, and show how to align Cloudflare with your hosting setup at dchost.com or any other standards‑based infrastructure.

How Cloudflare DNS Really Works: Orange Cloud vs DNS‑Only

Cloudflare as Your Authoritative DNS

When you add a domain to Cloudflare and change your nameservers at the registrar, Cloudflare becomes the authoritative DNS provider for that domain. Every DNS query (A, AAAA, MX, TXT, etc.) is answered by Cloudflare’s nameservers based on the records you configure in the dashboard.

If you are deciding whether Cloudflare should handle your DNS or your hosting provider should, it is worth reading our detailed comparison of Cloudflare DNS vs hosting DNS and how to choose the right nameserver strategy. In most cases, using Cloudflare as DNS while hosting your site on dchost.com works very well.

What the Orange Cloud Actually Does

In the DNS tab, each A or CNAME record for HTTP/HTTPS services can be either:

• Proxied (orange cloud) – Traffic flows through Cloudflare’s reverse proxy. Cloudflare shows its own IPs to visitors, caches content, applies WAF, and terminates HTTPS. Your origin IP is hidden.
• DNS only (grey cloud) – Cloudflare only answers DNS. Clients connect directly to your origin server IP, with no proxy, caching or WAF in between.

Important limitations:

• Only certain record types can be proxied (A/AAAA, CNAME, some SRV). MX, NS and most TXT records are always DNS‑only.
• Non‑HTTP protocols (SMTP, IMAP, POP3, FTP, SSH, etc.) must not go through the HTTP/HTTPS proxy. Their hostnames must be grey cloud, pointing directly to your server.

Which Records Should Be Orange and Which Should Not?

As a practical rule of thumb:

• Usually orange:
  • www.example.com (web traffic)
  • example.com (root domain if you want the apex to be proxied)
  • app.example.com, shop.example.com and other HTTP/HTTPS subdomains
• Always grey (DNS only):
  • MX records (mail routing) – cannot be proxied by design
  • Hostnames used for email: mail.example.com, smtp.example.com, imap.example.com, pop.example.com, autodiscover.example.com
  • Hostnames for FTP, SFTP/SSH, database access (if exposed), API ports, VPN, game servers, etc.

If you accidentally turn a mail hostname orange, Cloudflare will try to speak HTTP/HTTPS to that host instead of SMTP/IMAP/POP3, and email will start failing in confusing ways. Later in this article we will look specifically at safe email DNS patterns.

Pointing Your Domain to Cloudflare Without Breaking Anything

Step 1: Copy Existing DNS Records into Cloudflare

Before changing nameservers, make sure Cloudflare has all the records your domain currently uses:

1. Add your domain to Cloudflare. It will try to auto‑scan records, but do not trust the scan blindly.
2. Open your existing DNS panel (for example, dchost.com’s DNS manager or cPanel) and list all important records: A/AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), SRV, CAA, etc.
3. Carefully recreate them in Cloudflare with exactly the same values (hostnames, priorities, content).

While doing this, it helps to use a sane TTL strategy. If you are not sure which TTL values to choose, see our guide on DNS TTL best practices for A, MX, CNAME and TXT records. Shorter TTLs (300–600 seconds) are ideal while you are actively migrating.

Step 2: Decide Which Web Records Will Be Proxied

Now, choose which hostnames should use the orange cloud:

• Set www.example.com to Proxied (orange).
• Decide whether example.com (without www) should also be proxied. In many setups we recommend proxied apex with a redirect policy from one canonical hostname to the other.
• Keep mail.example.com, ftp.example.com, cpanel.example.com and similar service hostnames as DNS only (grey).

If you host several sites or applications under one domain, be consistent: all HTTP/HTTPS hostnames that benefit from Cloudflare’s cache and WAF should be orange; everything else should stay grey.

Step 3: Change Nameservers at the Registrar

Once DNS records in Cloudflare match your existing setup, update the domain’s nameservers at your registrar to the pair Cloudflare provides. DNS propagation usually takes minutes to a few hours. With short TTLs, the transition is typically smooth and invisible to end users.

If you are planning a larger migration (for example, moving from one hosting provider to dchost.com while also switching to Cloudflare DNS), it is worth reading our domain and DNS migration checklist for changing hosting providers so you can coordinate nameserver, A record and MX changes with minimal risk.

Cloudflare SSL Modes Explained: Why Full (Strict) Is the Only Real Option

What Cloudflare SSL Modes Actually Mean

Cloudflare offers several SSL/TLS modes under SSL/TLS > Overview:

• Off – No HTTPS between users and Cloudflare. Avoid this.
• Flexible – HTTPS between user and Cloudflare, but HTTP between Cloudflare and your origin. This is not end‑to‑end encryption and breaks many apps and security headers.
• Full – HTTPS from user to Cloudflare and from Cloudflare to origin, but Cloudflare does not verify the certificate on the origin. Any valid or self‑signed certificate is accepted.
• Full (strict) – HTTPS on both legs and Cloudflare validates the origin certificate against a trusted CA and hostname. This is the only mode that provides proper TLS security.

In 2024, there is no good reason to use Flexible mode on a site you care about. It causes redirect loops, mixed content problems and makes it impossible to rely on HSTS or many modern security practices. From our experience hosting thousands of domains, the correct choice is almost always Full (strict).

Ensuring Your Origin Has a Valid SSL certificate

Before switching Cloudflare to Full (strict), your origin server must already serve HTTPS correctly. You have two main options:

1. Use a regular certificate on the origin
   • On shared hosting or a managed server at dchost.com, you can typically enable Let’s Encrypt or another DV/OV/EV certificate directly in your control panel.
   • Test https://example.com and https://www.example.com by hitting the origin without Cloudflare (temporarily set the A record to DNS‑only and access via hosts file if needed).
2. Use a Cloudflare Origin Certificate
   • Cloudflare can issue an Origin CA certificate that is trusted by Cloudflare but not by browsers.
   • You install this certificate on your dchost.com VPS or dedicated server and configure your web server (Nginx, Apache, LiteSpeed) to use it.
   • Visitors still see a normal browser‑trusted certificate provided by Cloudflare’s edge.

If you want a deeper dive into what “real HTTPS behind a CDN” looks like, including certificate choices and origin security, we recommend reading our article on real HTTPS behind a CDN and Full (strict) SSL setup.

Switching to Full (Strict) Safely

Once the origin certificate is in place and tested:

1. In Cloudflare, go to SSL/TLS > Overview.
2. Set the mode to Full (strict).
3. Under Edge Certificates, enable Always Use HTTPS and, after thorough testing, consider enabling HSTS.

Make sure your application is not forcing HTTP in its configuration or .htaccess/nginx rules. If you have just completed a full HTTPS migration, our detailed guide on migrating a site from HTTP to HTTPS with 301 redirects and HSTS without losing SEO will help you align redirects, canonical URLs and search signals.

Putting It Together: Common Cloudflare + Hosting Scenarios

Scenario 1: Website and Email on the Same Hosting Server

This is very common for small businesses and personal sites hosted on a shared plan or a single VPS.

DNS pattern:

• A @ (example.com) → server IP – Proxied (orange) if you want the apex behind Cloudflare.
• CNAME www → @ – Proxied (orange). Cloudflare will CNAME‑flatten at the apex automatically.
• A mail → server IP – DNS only (grey).
• MX example.com → mail.example.com – DNS only (MX is always DNS‑only).
• TXT/SPF, DKIM, DMARC – DNS only.

SSL pattern:

• Install a valid certificate on the origin that covers example.com and www.example.com.
• Set Cloudflare SSL mode to Full (strict).
• Use HTTPS redirects at either your web server or Cloudflare (but avoid creating redirect loops).

Mail clients (Outlook, Apple Mail, mobile devices) should connect to mail.example.com over SMTP/IMAP/POP3 directly to your server’s IP (grey cloud). If you need help setting up clients, see our step‑by‑step guide to configuring cPanel email on Outlook, Apple Mail and mobile devices.

Scenario 2: Web on Hosting, Email on a Third‑Party Provider

Here your website is on a dchost.com shared hosting or VPS, but email is elsewhere.

DNS pattern:

• A @ and CNAME www → your hosting server IP/hostname – usually proxied (orange).
• MX example.com → hostnames provided by your email provider – DNS only.
• TXT SPF – Include your email provider and web hosting (if you send from the server) in a single, well‑designed SPF record.
• CNAME/TXT DKIM, TXT DMARC – as provided by the email provider.

Be especially careful not to proxy any hostname your email provider uses for MX or SMTP submission. If they instruct you to create mx1.provider.example or smtp.provider.example CNAMEs, these must remain grey.

Scenario 3: Multiple Subdomains and Services

If you have an API, admin panel, staging site or other subdomains:

• Public web apps (api.example.com, shop.example.com) – usually proxied (orange) with Full (strict) SSL.
• Internal tools, admin or database panels – often best left DNS only (grey) and restricted via IP, VPN or a dedicated firewall, or exposed over Cloudflare Zero Trust with careful configuration.

Do not forget to clean up unused entries. Dangling DNS records can cause security issues such as subdomain takeover. For more on this, see our guide on preventing subdomain takeover and dangling DNS on Cloudflare and cPanel.

Email DNS on Cloudflare: MX, SPF, DKIM and DMARC Without Surprises

MX Records: Who Receives Your Mail?

MX (Mail Exchanger) records tell the world which server handles incoming email for your domain. Key rules:

• MX records always point to hostnames, not IPs.
• Those hostnames (e.g. mail.example.com) must be DNS only (grey) A/AAAA records.
• Never proxy MX hostnames. If you see an orange cloud next to a mail hostname referenced by MX, turn it grey immediately.

In a typical cPanel setup on dchost.com, you will have:

• A mail → server IP (grey)
• MX example.com → mail.example.com (DNS only)

SPF: Declaring Where Your Emails Are Allowed to Come From

SPF (Sender Policy Framework) is a TXT record that lists which servers are allowed to send email for your domain. A simple example for a site that sends mail only from its hosting server might be:

v=spf1 a mx ~all

When you add other services (transactional email, newsletters, office suites), the record grows. SPF has a 10‑DNS‑lookup limit, so you must design it carefully to avoid failures. We have a full article on advanced SPF management for multiple email providers without hitting the 10‑lookup wall that is worth reading before you add more includes.

Important points on Cloudflare:

• SPF is a TXT record at the root (@) or specific subdomain (e.g. mail.example.com).
• It is always DNS‑only; the orange cloud does not apply to TXT records.
• Double SPF records (two different TXT records starting with v=spf1 at the same hostname) are a common and harmful mistake.

DKIM: Cryptographic Proof Your Mail Is Genuine

DKIM uses asymmetric cryptography to sign outgoing email, proving that the message has not been altered and that it really came from the domain. Technically, you publish a TXT record at a selector like:

selector1._domainkey.example.com

where selector1 is given to you by your mail software or provider. Cloudflare happily hosts these TXT records; again, they are not proxied.

DMARC: Policy and Reporting Layer on Top of SPF/DKIM

DMARC tells receiving servers how strictly to treat your mail and where to send aggregate and forensic reports. A minimal DMARC record might look like:

v=DMARC1; p=none; rua=mailto:[email protected]

Over time, you can tighten this to p=quarantine or p=reject once SPF and DKIM are correctly aligned. For a deeper treatment of DMARC strategy, including how to read and act on reports, see our article “DMARC in context: why the reports matter more than the record”.

Summary of email DNS rules with Cloudflare:

• MX hostnames: never proxied.
• Mail service hostnames (mail, smtp, imap, pop, autodiscover): DNS only.
• TXT SPF, DKIM, DMARC: TXT records only, no proxy flag.
• Don’t forget reverse DNS (PTR) on the sending IP; that is usually set in your hosting or VPS panel, not in Cloudflare.

Common Cloudflare DNS & SSL Mistakes (and How to Avoid Them)

1. Using Flexible SSL Instead of Full (Strict)

Symptoms:

• Random redirect loops between HTTP and HTTPS.
• “Mixed content” warnings that are hard to fix.
• Security scans complain that your origin is not encrypted.

Fix: install a valid certificate on the origin and switch Cloudflare to Full (strict), as described earlier. If you see mixed content after the switch, our guide on fixing mixed content and insecure HTTP requests after enabling SSL will help you clean up hard‑coded HTTP URLs.

2. Orange‑Clouding Mail and Other Non‑HTTP Services

Symptoms:

• Mail clients can no longer connect to SMTP/IMAP/POP3.
• SSL errors when connecting to mail.example.com.
• Online port tests show HTTP responses instead of mail protocol banners.

Fix: turn the orange cloud off (grey/DNS only) for any hostname used by MX or email clients. Only keep web (HTTP/HTTPS) services proxied.

3. Forgetting to Move All DNS Records

Symptoms:

• Some subdomains or services stop working right after you switch nameservers to Cloudflare.
• Old TXT records (for SPF/DKIM/verification) disappear, causing email or third‑party services to fail.

Fix: before touching nameservers, export or screenshot the full DNS zone from your previous provider, then recreate everything in Cloudflare. If you manage many domains or a complex portfolio, our article on DNS records explained from A to CAA and the small mistakes that hurt is a good checklist.

4. High TTLs During Migration

Symptoms:

• Changes to A, MX or CNAME records seem to take “forever” to propagate.
• You see different behaviour between locations or networks for many hours.

Fix: lower TTLs on critical records (A, AAAA, MX, CNAME) to 300–600 seconds before big changes. Once everything is stable, you can raise them back to 1–4 hours for efficiency. Again, our TTL best practices guide provides concrete recommendations by record type.

5. Dangling DNS and Subdomain Takeover Risk

Symptoms:

• Old CNAMEs pointing to services you no longer control.
• Subdomains that technically exist in DNS but no longer have a live origin.

Fix: regularly audit Cloudflare DNS for unused CNAMEs and A/AAAA records, especially those pointing to third‑party platforms. Remove what you no longer use. Our earlier linked article on preventing subdomain takeover shows real‑world examples and a systematic way to clean things up.

Advanced Tips: Canonical Domain, CNAME Flattening and Performance

Pick a Canonical Hostname and Stick to It

Should you use www.example.com or just example.com? From a DNS and Cloudflare perspective, both can be proxied, but you should choose one canonical host and redirect the other to it with a permanent (301) redirect.

For a detailed discussion of pros and cons (HSTS, cookies, CDNs, SEO) and how to configure redirects correctly on your server and CDN, see our guide on www vs non‑www canonical domains, 301 redirects and HSTS.

CNAME Flattening at the Apex

Traditionally, the DNS root (apex) cannot be a CNAME, but many modern setups want example.com to point to another hostname. Cloudflare solves this with CNAME flattening: you can create a CNAME or proxied A‑like record at the apex, and Cloudflare resolves it for you while still returning A/AAAA records to resolvers.

If you’re curious about CNAMEs at the root, ALIAS/ANAME records and how Cloudflare’s flattening compares to other approaches, we have a friendly deep dive in “CNAME at the apex? The friendly guide to ALIAS/ANAME and Cloudflare CNAME flattening”.

Align Cloudflare with Your Hosting Performance Tuning

Cloudflare is not a magic fix for an overloaded server. It helps a lot with static assets, but your origin still needs to be properly sized and tuned. If you are running WordPress, WooCommerce, Laravel or custom PHP, ensure your hosting plan (shared, VPS, or dedicated at dchost.com) has enough CPU, RAM and fast disk, and that PHP‑FPM, OPcache and MySQL/PostgreSQL are configured well. Our article on server‑side optimizations for WordPress with PHP‑FPM, OPcache, Redis and MySQL tuning is a good next step if you want to get the most from Cloudflare’s edge caching.

Summary: A Clean, Reliable Cloudflare Setup for Real‑World Sites

A correct Cloudflare DNS and SSL configuration is not about ticking random options; it is about aligning three layers: DNS records, TLS between user–Cloudflare–origin, and email DNS. When those layers are in sync, you get a fast, secure website with rock‑solid email delivery. When they are not, you get intermittent SSL errors, mails stuck in limbo, and support tickets from confused users.

The foundation is simple: let Cloudflare be your authoritative DNS, proxy only HTTP/HTTPS hostnames with the orange cloud, keep all email‑related records DNS‑only, and always use Full (strict) with a valid certificate on the origin. From there, you can refine TTLs, canonical domains, HSTS, and WAF rules knowing that the basics are solid.

At dchost.com, we design our shared hosting, VPS, dedicated and colocation offerings with Cloudflare‑friendly defaults: modern TLS, Let’s Encrypt support, correct PTR records for mail and sane DNS templates. If you would like help reviewing your current setup or planning a migration to Cloudflare without downtime, our team can work with you step‑by‑step to align your DNS, SSL and email records so they simply keep working.