{"id":4365,"date":"2026-02-03T15:50:34","date_gmt":"2026-02-03T12:50:34","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/setting-up-cloudflare-dns-ssl-and-email-records-the-right-way\/"},"modified":"2026-02-03T15:50:34","modified_gmt":"2026-02-03T12:50:34","slug":"setting-up-cloudflare-dns-ssl-and-email-records-the-right-way","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/setting-up-cloudflare-dns-ssl-and-email-records-the-right-way\/","title":{"rendered":"Setting Up Cloudflare DNS, SSL and Email Records the Right Way"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Cloudflare_DNS_SSL_and_Email_Records_Must_Work_Together\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Cloudflare DNS, SSL and Email Records Must Work Together<\/a><\/li><li><a href=\"#How_Cloudflare_DNS_Really_Works_Orange_Cloud_vs_DNSOnly\"><span class=\"toc_number toc_depth_1\">2<\/span> How Cloudflare DNS Really Works: Orange Cloud vs DNS\u2011Only<\/a><ul><li><a href=\"#Cloudflare_as_Your_Authoritative_DNS\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Cloudflare as Your Authoritative DNS<\/a><\/li><li><a href=\"#What_the_Orange_Cloud_Actually_Does\"><span class=\"toc_number toc_depth_2\">2.2<\/span> What the Orange Cloud Actually Does<\/a><\/li><li><a href=\"#Which_Records_Should_Be_Orange_and_Which_Should_Not\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Which Records Should Be Orange and Which Should Not?<\/a><\/li><\/ul><\/li><li><a href=\"#Pointing_Your_Domain_to_Cloudflare_Without_Breaking_Anything\"><span class=\"toc_number toc_depth_1\">3<\/span> Pointing Your Domain to Cloudflare Without Breaking Anything<\/a><ul><li><a href=\"#Step_1_Copy_Existing_DNS_Records_into_Cloudflare\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Step 1: Copy Existing DNS Records into Cloudflare<\/a><\/li><li><a href=\"#Step_2_Decide_Which_Web_Records_Will_Be_Proxied\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Step 2: Decide Which Web Records Will Be Proxied<\/a><\/li><li><a href=\"#Step_3_Change_Nameservers_at_the_Registrar\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Step 3: Change Nameservers at the Registrar<\/a><\/li><\/ul><\/li><li><a href=\"#Cloudflare_SSL_Modes_Explained_Why_Full_Strict_Is_the_Only_Real_Option\"><span class=\"toc_number toc_depth_1\">4<\/span> Cloudflare SSL Modes Explained: Why Full (Strict) Is the Only Real Option<\/a><ul><li><a href=\"#What_Cloudflare_SSL_Modes_Actually_Mean\"><span class=\"toc_number toc_depth_2\">4.1<\/span> What Cloudflare SSL Modes Actually Mean<\/a><\/li><li><a href=\"#Ensuring_Your_Origin_Has_a_Valid_SSL_certificate\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Ensuring Your Origin Has a Valid SSL certificate<\/a><\/li><li><a href=\"#Switching_to_Full_Strict_Safely\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Switching to Full (Strict) Safely<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_Together_Common_Cloudflare_Hosting_Scenarios\"><span class=\"toc_number toc_depth_1\">5<\/span> Putting It Together: Common Cloudflare + Hosting Scenarios<\/a><ul><li><a href=\"#Scenario_1_Website_and_Email_on_the_Same_Hosting_Server\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Scenario 1: Website and Email on the Same Hosting Server<\/a><\/li><li><a href=\"#Scenario_2_Web_on_Hosting_Email_on_a_ThirdParty_Provider\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Scenario 2: Web on Hosting, Email on a Third\u2011Party Provider<\/a><\/li><li><a href=\"#Scenario_3_Multiple_Subdomains_and_Services\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Scenario 3: Multiple Subdomains and Services<\/a><\/li><\/ul><\/li><li><a href=\"#Email_DNS_on_Cloudflare_MX_SPF_DKIM_and_DMARC_Without_Surprises\"><span class=\"toc_number toc_depth_1\">6<\/span> Email DNS on Cloudflare: MX, SPF, DKIM and DMARC Without Surprises<\/a><ul><li><a href=\"#MX_Records_Who_Receives_Your_Mail\"><span class=\"toc_number toc_depth_2\">6.1<\/span> MX Records: Who Receives Your Mail?<\/a><\/li><li><a href=\"#SPF_Declaring_Where_Your_Emails_Are_Allowed_to_Come_From\"><span class=\"toc_number toc_depth_2\">6.2<\/span> SPF: Declaring Where Your Emails Are Allowed to Come From<\/a><\/li><li><a href=\"#DKIM_Cryptographic_Proof_Your_Mail_Is_Genuine\"><span class=\"toc_number toc_depth_2\">6.3<\/span> DKIM: Cryptographic Proof Your Mail Is Genuine<\/a><\/li><li><a href=\"#DMARC_Policy_and_Reporting_Layer_on_Top_of_SPFDKIM\"><span class=\"toc_number toc_depth_2\">6.4<\/span> DMARC: Policy and Reporting Layer on Top of SPF\/DKIM<\/a><\/li><\/ul><\/li><li><a href=\"#Common_Cloudflare_DNS_SSL_Mistakes_and_How_to_Avoid_Them\"><span class=\"toc_number toc_depth_1\">7<\/span> Common Cloudflare DNS &amp; SSL Mistakes (and How to Avoid Them)<\/a><ul><li><a href=\"#1_Using_Flexible_SSL_Instead_of_Full_Strict\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Using Flexible SSL Instead of Full (Strict)<\/a><\/li><li><a href=\"#2_OrangeClouding_Mail_and_Other_NonHTTP_Services\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Orange\u2011Clouding Mail and Other Non\u2011HTTP Services<\/a><\/li><li><a href=\"#3_Forgetting_to_Move_All_DNS_Records\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Forgetting to Move All DNS Records<\/a><\/li><li><a href=\"#4_High_TTLs_During_Migration\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. High TTLs During Migration<\/a><\/li><li><a href=\"#5_Dangling_DNS_and_Subdomain_Takeover_Risk\"><span class=\"toc_number toc_depth_2\">7.5<\/span> 5. Dangling DNS and Subdomain Takeover Risk<\/a><\/li><\/ul><\/li><li><a href=\"#Advanced_Tips_Canonical_Domain_CNAME_Flattening_and_Performance\"><span class=\"toc_number toc_depth_1\">8<\/span> Advanced Tips: Canonical Domain, CNAME Flattening and Performance<\/a><ul><li><a href=\"#Pick_a_Canonical_Hostname_and_Stick_to_It\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Pick a Canonical Hostname and Stick to It<\/a><\/li><li><a href=\"#CNAME_Flattening_at_the_Apex\"><span class=\"toc_number toc_depth_2\">8.2<\/span> CNAME Flattening at the Apex<\/a><\/li><li><a href=\"#Align_Cloudflare_with_Your_Hosting_Performance_Tuning\"><span class=\"toc_number toc_depth_2\">8.3<\/span> Align Cloudflare with Your Hosting Performance Tuning<\/a><\/li><\/ul><\/li><li><a href=\"#Summary_A_Clean_Reliable_Cloudflare_Setup_for_RealWorld_Sites\"><span class=\"toc_number toc_depth_1\">9<\/span> Summary: A Clean, Reliable Cloudflare Setup for Real\u2011World Sites<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Cloudflare_DNS_SSL_and_Email_Records_Must_Work_Together\">Why Cloudflare DNS, SSL and Email Records Must Work Together<\/span><\/h2>\n<p>Moving your domain\u2019s 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.<\/p>\n<p>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\u2019s <strong>Full (strict)<\/strong> mode correctly, and how to keep your <strong>email DNS records<\/strong> safe and reliable. We will use practical scenarios you are likely to encounter on shared hosting, VPS and <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, and show how to align Cloudflare with your hosting setup at dchost.com or any other standards\u2011based infrastructure.<\/p>\n<h2><span id=\"How_Cloudflare_DNS_Really_Works_Orange_Cloud_vs_DNSOnly\">How Cloudflare DNS Really Works: Orange Cloud vs DNS\u2011Only<\/span><\/h2>\n<h3><span id=\"Cloudflare_as_Your_Authoritative_DNS\">Cloudflare as Your Authoritative DNS<\/span><\/h3>\n<p>When you add a domain to Cloudflare and change your nameservers at the registrar, Cloudflare becomes the <strong>authoritative DNS provider<\/strong> for that domain. Every DNS query (A, AAAA, MX, TXT, etc.) is answered by Cloudflare\u2019s nameservers based on the records you configure in the dashboard.<\/p>\n<p>If you are deciding whether Cloudflare should handle your DNS or your hosting provider should, it is worth reading our detailed comparison of <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-dns-mi-hosting-dnsi-mi-en-dogru-nameserver-stratejisi\/\">Cloudflare DNS vs hosting DNS and how to choose the right nameserver strategy<\/a>. In most cases, using Cloudflare as DNS while hosting your site on dchost.com works very well.<\/p>\n<h3><span id=\"What_the_Orange_Cloud_Actually_Does\">What the Orange Cloud Actually Does<\/span><\/h3>\n<p>In the DNS tab, each A or CNAME record for HTTP\/HTTPS services can be either:<\/p>\n<ul>\n<li><strong>Proxied (orange cloud)<\/strong> \u2013 Traffic flows through Cloudflare\u2019s reverse proxy. Cloudflare shows its own IPs to visitors, caches content, applies WAF, and terminates HTTPS. Your origin IP is hidden.<\/li>\n<li><strong>DNS only (grey cloud)<\/strong> \u2013 Cloudflare only answers DNS. Clients connect directly to your origin server IP, with no proxy, caching or WAF in between.<\/li>\n<\/ul>\n<p>Important limitations:<\/p>\n<ul>\n<li>Only certain record types can be proxied (A\/AAAA, CNAME, some SRV). <strong>MX, NS and most TXT records are always DNS\u2011only<\/strong>.<\/li>\n<li><strong>Non\u2011HTTP protocols (SMTP, IMAP, POP3, FTP, SSH, etc.) must not go through the HTTP\/HTTPS proxy<\/strong>. Their hostnames must be grey cloud, pointing directly to your server.<\/li>\n<\/ul>\n<h3><span id=\"Which_Records_Should_Be_Orange_and_Which_Should_Not\">Which Records Should Be Orange and Which Should Not?<\/span><\/h3>\n<p>As a practical rule of thumb:<\/p>\n<ul>\n<li><strong>Usually orange<\/strong>:\n<ul>\n<li><strong>www.example.com<\/strong> (web traffic)<\/li>\n<li><strong>example.com<\/strong> (root domain if you want the apex to be proxied)<\/li>\n<li><strong>app.example.com<\/strong>, <strong>shop.example.com<\/strong> and other HTTP\/HTTPS subdomains<\/li>\n<\/ul>\n<\/li>\n<li><strong>Always grey (DNS only)<\/strong>:\n<ul>\n<li><strong>MX records<\/strong> (mail routing) \u2013 cannot be proxied by design<\/li>\n<li>Hostnames used for email: <strong>mail.example.com, smtp.example.com, imap.example.com, pop.example.com, autodiscover.example.com<\/strong><\/li>\n<li>Hostnames for <strong>FTP, SFTP\/SSH, database access (if exposed), API ports, VPN, game servers, etc.<\/strong><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Pointing_Your_Domain_to_Cloudflare_Without_Breaking_Anything\">Pointing Your Domain to Cloudflare Without Breaking Anything<\/span><\/h2>\n<h3><span id=\"Step_1_Copy_Existing_DNS_Records_into_Cloudflare\">Step 1: Copy Existing DNS Records into Cloudflare<\/span><\/h3>\n<p>Before changing nameservers, make sure Cloudflare has all the records your domain currently uses:<\/p>\n<ol>\n<li>Add your domain to Cloudflare. It will try to auto\u2011scan records, but <strong>do not trust the scan blindly<\/strong>.<\/li>\n<li>Open your existing DNS panel (for example, dchost.com\u2019s DNS manager or cPanel) and list all important records: A\/AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), SRV, CAA, etc.<\/li>\n<li>Carefully recreate them in Cloudflare with <strong>exactly the same values<\/strong> (hostnames, priorities, content).<\/li>\n<\/ol>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-ttl-degerlerini-dogru-ayarlamak-a-mx-cname-ve-txt-kayitlari-icin-stratejik-rehber\/\">DNS TTL best practices for A, MX, CNAME and TXT records<\/a>. Shorter TTLs (300\u2013600 seconds) are ideal while you are actively migrating.<\/p>\n<h3><span id=\"Step_2_Decide_Which_Web_Records_Will_Be_Proxied\">Step 2: Decide Which Web Records Will Be Proxied<\/span><\/h3>\n<p>Now, choose which hostnames should use the orange cloud:<\/p>\n<ul>\n<li>Set <strong>www.example.com<\/strong> to <strong>Proxied (orange)<\/strong>.<\/li>\n<li>Decide whether <strong>example.com<\/strong> (without www) should also be proxied. In many setups we recommend proxied apex with a redirect policy from one canonical hostname to the other.<\/li>\n<li>Keep <strong>mail.example.com<\/strong>, <strong>ftp.example.com<\/strong>, <strong>cpanel.example.com<\/strong> and similar service hostnames as <strong>DNS only (grey)<\/strong>.<\/li>\n<\/ul>\n<p>If you host several sites or applications under one domain, be consistent: all HTTP\/HTTPS hostnames that benefit from Cloudflare\u2019s cache and WAF should be orange; everything else should stay grey.<\/p>\n<h3><span id=\"Step_3_Change_Nameservers_at_the_Registrar\">Step 3: Change Nameservers at the Registrar<\/span><\/h3>\n<p>Once DNS records in Cloudflare match your existing setup, update the domain\u2019s 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.<\/p>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-firmasi-degistirirken-dns-ve-domain-tasima-kontrol-listesi\/\">domain and DNS migration checklist for changing hosting providers<\/a> so you can coordinate nameserver, A record and MX changes with minimal risk.<\/p>\n<h2><span id=\"Cloudflare_SSL_Modes_Explained_Why_Full_Strict_Is_the_Only_Real_Option\">Cloudflare SSL Modes Explained: Why Full (Strict) Is the Only Real Option<\/span><\/h2>\n<h3><span id=\"What_Cloudflare_SSL_Modes_Actually_Mean\">What Cloudflare SSL Modes Actually Mean<\/span><\/h3>\n<p>Cloudflare offers several SSL\/TLS modes under <strong>SSL\/TLS &gt; Overview<\/strong>:<\/p>\n<ul>\n<li><strong>Off<\/strong> \u2013 No HTTPS between users and Cloudflare. Avoid this.<\/li>\n<li><strong>Flexible<\/strong> \u2013 HTTPS between user and Cloudflare, but HTTP between Cloudflare and your origin. This is <strong>not end\u2011to\u2011end encryption<\/strong> and breaks many apps and security headers.<\/li>\n<li><strong>Full<\/strong> \u2013 HTTPS from user to Cloudflare and from Cloudflare to origin, but Cloudflare does <strong>not verify the certificate<\/strong> on the origin. Any valid or self\u2011signed certificate is accepted.<\/li>\n<li><strong>Full (strict)<\/strong> \u2013 HTTPS on both legs and Cloudflare <strong>validates the origin certificate<\/strong> against a trusted CA and hostname. This is the only mode that provides proper TLS security.<\/li>\n<\/ul>\n<p>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 <strong>Full (strict)<\/strong>.<\/p>\n<h3><span id=\"Ensuring_Your_Origin_Has_a_Valid_SSL_certificate\">Ensuring Your Origin Has a Valid <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a><\/span><\/h3>\n<p>Before switching Cloudflare to Full (strict), your origin server must already serve HTTPS correctly. You have two main options:<\/p>\n<ol>\n<li><strong>Use a regular certificate on the origin<\/strong>\n<ul>\n<li>On shared hosting or a managed server at dchost.com, you can typically enable <strong>Let\u2019s Encrypt<\/strong> or another DV\/OV\/EV certificate directly in your control panel.<\/li>\n<li>Test <strong>https:\/\/example.com<\/strong> and <strong>https:\/\/www.example.com<\/strong> by hitting the origin <em>without<\/em> Cloudflare (temporarily set the A record to DNS\u2011only and access via hosts file if needed).<\/li>\n<\/ul>\n<\/li>\n<li><strong>Use a Cloudflare Origin Certificate<\/strong>\n<ul>\n<li>Cloudflare can issue an <strong>Origin CA<\/strong> certificate that is trusted by Cloudflare but not by browsers.<\/li>\n<li>You install this certificate on your dchost.com VPS or dedicated server and configure your web server (Nginx, Apache, LiteSpeed) to use it.<\/li>\n<li>Visitors still see a normal browser\u2011trusted certificate provided by Cloudflare\u2019s edge.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>If you want a deeper dive into what \u201creal HTTPS behind a CDN\u201d looks like, including certificate choices and origin security, we recommend reading <a href=\"https:\/\/www.dchost.com\/blog\/en\/cdn-arkasinda-gercek-https-ve-full-strict-ssl-kurulumu\/\">our article on real HTTPS behind a CDN and Full (strict) SSL setup<\/a>.<\/p>\n<h3><span id=\"Switching_to_Full_Strict_Safely\">Switching to Full (Strict) Safely<\/span><\/h3>\n<p>Once the origin certificate is in place and tested:<\/p>\n<ol>\n<li>In Cloudflare, go to <strong>SSL\/TLS &gt; Overview<\/strong>.<\/li>\n<li>Set the mode to <strong>Full (strict)<\/strong>.<\/li>\n<li>Under <strong>Edge Certificates<\/strong>, enable <strong>Always Use HTTPS<\/strong> and, after thorough testing, consider enabling <strong>HSTS<\/strong>.<\/li>\n<\/ol>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/\">migrating a site from HTTP to HTTPS with 301 redirects and HSTS without losing SEO<\/a> will help you align redirects, canonical URLs and search signals.<\/p>\n<h2><span id=\"Putting_It_Together_Common_Cloudflare_Hosting_Scenarios\">Putting It Together: Common Cloudflare + Hosting Scenarios<\/span><\/h2>\n<h3><span id=\"Scenario_1_Website_and_Email_on_the_Same_Hosting_Server\">Scenario 1: Website and Email on the Same Hosting Server<\/span><\/h3>\n<p>This is very common for small businesses and personal sites hosted on a shared plan or a single VPS.<\/p>\n<p><strong>DNS pattern:<\/strong><\/p>\n<ul>\n<li><strong>A @ (example.com) \u2192 server IP<\/strong> \u2013 Proxied (orange) if you want the apex behind Cloudflare.<\/li>\n<li><strong>CNAME www \u2192 @<\/strong> \u2013 Proxied (orange). Cloudflare will CNAME\u2011flatten at the apex automatically.<\/li>\n<li><strong>A mail \u2192 server IP<\/strong> \u2013 DNS only (grey).<\/li>\n<li><strong>MX example.com \u2192 mail.example.com<\/strong> \u2013 DNS only (MX is always DNS\u2011only).<\/li>\n<li><strong>TXT\/SPF, DKIM, DMARC<\/strong> \u2013 DNS only.<\/li>\n<\/ul>\n<p><strong>SSL pattern:<\/strong><\/p>\n<ul>\n<li>Install a valid certificate on the origin that covers <strong>example.com<\/strong> and <strong>www.example.com<\/strong>.<\/li>\n<li>Set Cloudflare SSL mode to <strong>Full (strict)<\/strong>.<\/li>\n<li>Use HTTPS redirects at either your web server or Cloudflare (but avoid creating redirect loops).<\/li>\n<\/ul>\n<p>Mail clients (Outlook, Apple Mail, mobile devices) should connect to <strong>mail.example.com<\/strong> over SMTP\/IMAP\/POP3 directly to your server\u2019s IP (grey cloud). If you need help setting up clients, see our step\u2011by\u2011step guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-e-postayi-outlook-apple-mail-ve-mobil-cihazlarda-kurmak\/\">configuring cPanel email on Outlook, Apple Mail and mobile devices<\/a>.<\/p>\n<h3><span id=\"Scenario_2_Web_on_Hosting_Email_on_a_ThirdParty_Provider\">Scenario 2: Web on Hosting, Email on a Third\u2011Party Provider<\/span><\/h3>\n<p>Here your website is on a dchost.com shared hosting or VPS, but email is elsewhere.<\/p>\n<p><strong>DNS pattern:<\/strong><\/p>\n<ul>\n<li><strong>A @ and CNAME www<\/strong> \u2192 your hosting server IP\/hostname \u2013 usually proxied (orange).<\/li>\n<li><strong>MX example.com<\/strong> \u2192 hostnames provided by your email provider \u2013 DNS only.<\/li>\n<li><strong>TXT SPF<\/strong> \u2013 Include your email provider and <a href=\"https:\/\/www.dchost.com\/web-hosting\">web hosting<\/a> (if you send from the server) in a single, well\u2011designed SPF record.<\/li>\n<li><strong>CNAME\/TXT DKIM, TXT DMARC<\/strong> \u2013 as provided by the email provider.<\/li>\n<\/ul>\n<p>Be especially careful not to proxy any hostname your email provider uses for MX or SMTP submission. If they instruct you to create <strong>mx1.provider.example<\/strong> or <strong>smtp.provider.example<\/strong> CNAMEs, these must remain grey.<\/p>\n<h3><span id=\"Scenario_3_Multiple_Subdomains_and_Services\">Scenario 3: Multiple Subdomains and Services<\/span><\/h3>\n<p>If you have an API, admin panel, staging site or other subdomains:<\/p>\n<ul>\n<li><strong>Public web apps<\/strong> (api.example.com, shop.example.com) \u2013 usually proxied (orange) with Full (strict) SSL.<\/li>\n<li><strong>Internal tools, admin or database panels<\/strong> \u2013 often best left <strong>DNS only (grey)<\/strong> and restricted via IP, VPN or a dedicated firewall, or exposed over Cloudflare Zero Trust with careful configuration.<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/subdomain-takeover-ve-bosta-kalan-dns-kayitlari-cloudflare-ve-cpanel-icin-uygulamali-rehber\/\">preventing subdomain takeover and dangling DNS on Cloudflare and cPanel<\/a>.<\/p>\n<h2><span id=\"Email_DNS_on_Cloudflare_MX_SPF_DKIM_and_DMARC_Without_Surprises\">Email DNS on Cloudflare: MX, SPF, DKIM and DMARC Without Surprises<\/span><\/h2>\n<h3><span id=\"MX_Records_Who_Receives_Your_Mail\">MX Records: Who Receives Your Mail?<\/span><\/h3>\n<p><strong>MX (Mail Exchanger) records<\/strong> tell the world which server handles incoming email for your domain. Key rules:<\/p>\n<ul>\n<li>MX records always point to <strong>hostnames, not IPs<\/strong>.<\/li>\n<li>Those hostnames (e.g. <strong>mail.example.com<\/strong>) must be <strong>DNS only (grey)<\/strong> A\/AAAA records.<\/li>\n<li>Never proxy MX hostnames. If you see an orange cloud next to a mail hostname referenced by MX, turn it grey immediately.<\/li>\n<\/ul>\n<p>In a typical cPanel setup on dchost.com, you will have:<\/p>\n<ul>\n<li><strong>A mail \u2192 server IP<\/strong> (grey)<\/li>\n<li><strong>MX example.com \u2192 mail.example.com<\/strong> (DNS only)<\/li>\n<\/ul>\n<h3><span id=\"SPF_Declaring_Where_Your_Emails_Are_Allowed_to_Come_From\">SPF: Declaring Where Your Emails Are Allowed to Come From<\/span><\/h3>\n<p><strong>SPF (Sender Policy Framework)<\/strong> 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:<\/p>\n<p><code>v=spf1 a mx ~all<\/code><\/p>\n<p>When you add other services (transactional email, newsletters, office suites), the record grows. SPF has a <strong>10\u2011DNS\u2011lookup limit<\/strong>, so you must design it carefully to avoid failures. We have a full article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/gelismis-spf-yonetimi-10-dns-lookup-limitine-takilmadan-coklu-e-posta-servisi-kullanmak\/\">advanced SPF management for multiple email providers without hitting the 10\u2011lookup wall<\/a> that is worth reading before you add more includes.<\/p>\n<p>Important points on Cloudflare:<\/p>\n<ul>\n<li>SPF is a <strong>TXT record<\/strong> at the root (<strong>@<\/strong>) or specific subdomain (e.g. <strong>mail.example.com<\/strong>).<\/li>\n<li>It is always DNS\u2011only; the orange cloud does not apply to TXT records.<\/li>\n<li>Double SPF records (two different TXT records starting with <code>v=spf1<\/code> at the same hostname) are a common and harmful mistake.<\/li>\n<\/ul>\n<h3><span id=\"DKIM_Cryptographic_Proof_Your_Mail_Is_Genuine\">DKIM: Cryptographic Proof Your Mail Is Genuine<\/span><\/h3>\n<p><strong>DKIM<\/strong> 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:<\/p>\n<p><code>selector1._domainkey.example.com<\/code><\/p>\n<p>where <code>selector1<\/code> is given to you by your mail software or provider. Cloudflare happily hosts these TXT records; again, they are <strong>not proxied<\/strong>.<\/p>\n<h3><span id=\"DMARC_Policy_and_Reporting_Layer_on_Top_of_SPFDKIM\">DMARC: Policy and Reporting Layer on Top of SPF\/DKIM<\/span><\/h3>\n<p><strong>DMARC<\/strong> tells receiving servers how strictly to treat your mail and where to send aggregate and forensic reports. A minimal DMARC record might look like:<\/p>\n<p><code>v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com<\/code><\/p>\n<p>Over time, you can tighten this to <code>p=quarantine<\/code> or <code>p=reject<\/code> 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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/dmarc-raporlari-aggregate-ve-forensic-analiz-ile-pnonedan-prejecte-gecis\/\">\u201cDMARC in context: why the reports matter more than the record\u201d<\/a>.<\/p>\n<p>Summary of email DNS rules with Cloudflare:<\/p>\n<ul>\n<li>MX hostnames: <strong>never proxied<\/strong>.<\/li>\n<li>Mail service hostnames (mail, smtp, imap, pop, autodiscover): <strong>DNS only<\/strong>.<\/li>\n<li>TXT SPF, DKIM, DMARC: <strong>TXT records only, no proxy flag<\/strong>.<\/li>\n<li>Don\u2019t forget reverse DNS (PTR) on the sending IP; that is usually set in your hosting or VPS panel, not in Cloudflare.<\/li>\n<\/ul>\n<h2><span id=\"Common_Cloudflare_DNS_SSL_Mistakes_and_How_to_Avoid_Them\">Common Cloudflare DNS &amp; SSL Mistakes (and How to Avoid Them)<\/span><\/h2>\n<h3><span id=\"1_Using_Flexible_SSL_Instead_of_Full_Strict\">1. Using Flexible SSL Instead of Full (Strict)<\/span><\/h3>\n<p>Symptoms:<\/p>\n<ul>\n<li>Random redirect loops between HTTP and HTTPS.<\/li>\n<li>\u201cMixed content\u201d warnings that are hard to fix.<\/li>\n<li>Security scans complain that your origin is not encrypted.<\/li>\n<\/ul>\n<p>Fix: install a valid certificate on the origin and switch Cloudflare to <strong>Full (strict)<\/strong>, as described earlier. If you see mixed content after the switch, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sonrasi-mixed-content-ve-guvensiz-icerik-hatalarini-duzeltmek\/\">fixing mixed content and insecure HTTP requests after enabling SSL<\/a> will help you clean up hard\u2011coded HTTP URLs.<\/p>\n<h3><span id=\"2_OrangeClouding_Mail_and_Other_NonHTTP_Services\">2. Orange\u2011Clouding Mail and Other Non\u2011HTTP Services<\/span><\/h3>\n<p>Symptoms:<\/p>\n<ul>\n<li>Mail clients can no longer connect to SMTP\/IMAP\/POP3.<\/li>\n<li>SSL errors when connecting to mail.example.com.<\/li>\n<li>Online port tests show HTTP responses instead of mail protocol banners.<\/li>\n<\/ul>\n<p>Fix: turn the orange cloud <strong>off<\/strong> (grey\/DNS only) for any hostname used by MX or email clients. Only keep web (HTTP\/HTTPS) services proxied.<\/p>\n<h3><span id=\"3_Forgetting_to_Move_All_DNS_Records\">3. Forgetting to Move All DNS Records<\/span><\/h3>\n<p>Symptoms:<\/p>\n<ul>\n<li>Some subdomains or services stop working right after you switch nameservers to Cloudflare.<\/li>\n<li>Old TXT records (for SPF\/DKIM\/verification) disappear, causing email or third\u2011party services to fail.<\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">DNS records explained from A to CAA and the small mistakes that hurt<\/a> is a good checklist.<\/p>\n<h3><span id=\"4_High_TTLs_During_Migration\">4. High TTLs During Migration<\/span><\/h3>\n<p>Symptoms:<\/p>\n<ul>\n<li>Changes to A, MX or CNAME records seem to take \u201cforever\u201d to propagate.<\/li>\n<li>You see different behaviour between locations or networks for many hours.<\/li>\n<\/ul>\n<p>Fix: lower TTLs on critical records (A, AAAA, MX, CNAME) to 300\u2013600 seconds before big changes. Once everything is stable, you can raise them back to 1\u20134 hours for efficiency. Again, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-ttl-degerlerini-dogru-ayarlamak-a-mx-cname-ve-txt-kayitlari-icin-stratejik-rehber\/\">TTL best practices guide<\/a> provides concrete recommendations by record type.<\/p>\n<h3><span id=\"5_Dangling_DNS_and_Subdomain_Takeover_Risk\">5. Dangling DNS and Subdomain Takeover Risk<\/span><\/h3>\n<p>Symptoms:<\/p>\n<ul>\n<li>Old CNAMEs pointing to services you no longer control.<\/li>\n<li>Subdomains that technically exist in DNS but no longer have a live origin.<\/li>\n<\/ul>\n<p>Fix: regularly audit Cloudflare DNS for unused CNAMEs and A\/AAAA records, especially those pointing to third\u2011party platforms. Remove what you no longer use. Our earlier linked article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/subdomain-takeover-ve-bosta-kalan-dns-kayitlari-cloudflare-ve-cpanel-icin-uygulamali-rehber\/\">preventing subdomain takeover<\/a> shows real\u2011world examples and a systematic way to clean things up.<\/p>\n<h2><span id=\"Advanced_Tips_Canonical_Domain_CNAME_Flattening_and_Performance\">Advanced Tips: Canonical Domain, CNAME Flattening and Performance<\/span><\/h2>\n<h3><span id=\"Pick_a_Canonical_Hostname_and_Stick_to_It\">Pick a Canonical Hostname and Stick to It<\/span><\/h3>\n<p>Should you use <strong>www.example.com<\/strong> or just <strong>example.com<\/strong>? 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.<\/p>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/www-mi-ciplak-alan-adi-mi-canonical-domain-301-ve-hsts-icin-dogru-ayarlar\/\">www vs non\u2011www canonical domains, 301 redirects and HSTS<\/a>.<\/p>\n<h3><span id=\"CNAME_Flattening_at_the_Apex\">CNAME Flattening at the Apex<\/span><\/h3>\n<p>Traditionally, the DNS root (apex) cannot be a CNAME, but many modern setups want <strong>example.com<\/strong> to point to another hostname. Cloudflare solves this with <strong>CNAME flattening<\/strong>: you can create a CNAME or proxied A\u2011like record at the apex, and Cloudflare resolves it for you while still returning A\/AAAA records to resolvers.<\/p>\n<p>If you\u2019re curious about CNAMEs at the root, ALIAS\/ANAME records and how Cloudflare\u2019s flattening compares to other approaches, we have a friendly deep dive in <a href=\"https:\/\/www.dchost.com\/blog\/en\/bir-domain-bir-kahve-ve-kokte-cname-dilegi\/\">\u201cCNAME at the apex? The friendly guide to ALIAS\/ANAME and Cloudflare CNAME flattening\u201d<\/a>.<\/p>\n<h3><span id=\"Align_Cloudflare_with_Your_Hosting_Performance_Tuning\">Align Cloudflare with Your Hosting Performance Tuning<\/span><\/h3>\n<p>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\u2011FPM, OPcache and MySQL\/PostgreSQL are configured well. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-sunucu-tarafi-optimizasyon-php-fpm-opcache-redis-ve-mysql-ile-neyi-ne-zaman-nasil-ayarlamalisin\/\">server\u2011side optimizations for WordPress with PHP\u2011FPM, OPcache, Redis and MySQL tuning<\/a> is a good next step if you want to get the most from Cloudflare\u2019s edge caching.<\/p>\n<h2><span id=\"Summary_A_Clean_Reliable_Cloudflare_Setup_for_RealWorld_Sites\">Summary: A Clean, Reliable Cloudflare Setup for Real\u2011World Sites<\/span><\/h2>\n<p>A correct Cloudflare DNS and SSL configuration is not about ticking random options; it is about aligning three layers: <strong>DNS records<\/strong>, <strong>TLS between user\u2013Cloudflare\u2013origin<\/strong>, and <strong>email DNS<\/strong>. When those layers are in sync, you get a fast, secure website with rock\u2011solid email delivery. When they are not, you get intermittent SSL errors, mails stuck in limbo, and support tickets from confused users.<\/p>\n<p>The foundation is simple: let Cloudflare be your authoritative DNS, proxy only HTTP\/HTTPS hostnames with the orange cloud, keep all email\u2011related records DNS\u2011only, and always use <strong>Full (strict)<\/strong> 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.<\/p>\n<p>At dchost.com, we design our shared hosting, VPS, dedicated and colocation offerings with Cloudflare\u2011friendly defaults: modern TLS, Let\u2019s 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\u2011by\u2011step to align your DNS, SSL and email records so they simply keep working.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 Why Cloudflare DNS, SSL and Email Records Must Work Together2 How Cloudflare DNS Really Works: Orange Cloud vs DNS\u2011Only2.1 Cloudflare as Your Authoritative DNS2.2 What the Orange Cloud Actually Does2.3 Which Records Should Be Orange and Which Should Not?3 Pointing Your Domain to Cloudflare Without Breaking Anything3.1 Step 1: Copy Existing DNS Records into [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4366,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4365"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4365\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4366"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}