Cloudflare DNS ve SSL Ayarlarını Doğru Yapmak

Cloudflare DNS ve SSL Ayarlarını Doğru Yapmak Neden Bu Kadar Önemli?

Bir alan adını Cloudflare’a taşıyıp birkaç tur orange cloud tıklaması, SSL modunu “Flexible” yapıp sayfanın yeşil kilit göstermesi çoğu zaman ilk etapta “her şey çalışıyor” hissi verir. Ancak sahada gördüğümüz vakaların önemli bir kısmı tam bu noktadan sonra ortaya çıkan sorunlarla ilgili: Siteleriniz rastgele 522 hatası vermeye başlar, e‑postalarınız spam klasörüne düşer ya da hiç ulaşmaz, bazı alt alan adları bir anda kaybolur. Tüm bunların ortak nedeni neredeyse her zaman yanlış Cloudflare DNS ve SSL konfigürasyonudur.

Bu rehberde DCHost ekibi olarak yıllardır sahada gördüğümüz tipik hataları ve bunların kalıcı çözümlerini adım adım anlatacağız. Orange cloud ne zaman açılmalı? Hangi DNS kayıtları asla proxy olmamalı? Full (Strict) SSL için sunucu tarafında ne hazırlamanız gerekiyor? MX, SPF, DKIM ve DMARC gibi e‑posta DNS kayıtlarını Cloudflare’da nasıl doğru yönetirsiniz? Tüm bu sorulara net, uygulanabilir ve örnekli cevaplar vereceğiz. Amacımız: Cloudflare’ı hem performans hem de güvenlik tarafında en verimli şekilde kullanmanızı, aynı zamanda web sitesi ve e‑posta altyapınızın kararlı ve öngörülebilir çalışmasını sağlamak.

Cloudflare DNS Mantığı: Proxy (Orange Cloud) ve DNS Only Farkı

Cloudflare’ın klasik DNS sağlayıcılardan en büyük farkı, DNS kayıtlarınızı ister yalnızca DNS sunucusu olarak kullanabilmeniz, ister aynı zamanda HTTP/HTTPS trafiğini proxy etmesini sağlayabilmenizdir. Bu iki davranışın ayrımını, arayüzdeki küçük ama kritik bir ikon belirler: turuncu bulut (proxy) ve gri bulut (yalnızca DNS).

Orange Cloud (Proxy) Tam Olarak Ne Yapar?

Bir A/AAAA veya CNAME kaydında turuncu bulut açıksa Cloudflare şu şekilde davranır:

• Ziyaretçi HTTP/HTTPS isteğini Cloudflare IP’lerine gönderir.
• Cloudflare, isteği kendi ağı üzerinde işler (WAF, cache, rate limit vb.).
• Arka tarafta (origin) sizin gerçek sunucunuza bağlanır.
• Cevabı önbelleğe alarak tekrar ziyaretçilere dağıtır.

Bu sayede:

• Gerçek sunucu IP’niz gizlenir (güvenlik açısından avantaj).
• CDN ve cache sayesinde performans artışı elde edersiniz.
• Cloudflare WAF ve DDoS koruması devreye girer.

Ancak bu proxy davranışı sadece HTTP ve HTTPS trafiği için geçerlidir. SMTP, IMAP, POP3, SFTP gibi diğer protokoller Cloudflare üzerinden geçemez. Bu nedenle her kaydı turuncu yapmak ciddi sorunlara yol açar.

Hangi Kayıtlar Orange Cloud Olmalı?

Genel kural basit: Tarayıcı ile açtığınız her şey turuncu olabilir. Örnekler:

• www.example.com (web sitesi)
• example.com kök alan adı (site kökten açılıyorsa)
• blog.example.com, shop.example.com, app.example.com gibi web uygulaması alt alan adları
• Statik içerik servis eden cdn.example.com gibi alt alanlar

Bu kayıtların arkasında DCHost üzerindeki paylaşımlı hosting, VPS, dedicated veya colocation sunucunuz olabilir. Önemli olan: o kayıt gerçekten sadece HTTP/HTTPS servis ediyorsa turuncu bulut güvenle açılabilir.

Hangi Kayıtlar Asla Proxy Olmamalı? (E‑Posta ve Diğer Protokoller)

Cloudflare’da en sık gördüğümüz kritik hata, e‑posta ile ilgili kayıtların turuncu yapılması. Aşağıdaki kayıtlar her zaman gri (DNS only) olmalıdır:

• MX kayıtları (zaten proxy edilemez, ama işaret ettiği A kayıtları önemlidir)
• mail.example.com (SMTP/IMAP/POP3 sunucusu)
• smtp.example.com, imap.example.com, pop.example.com
• SPF kaydında referans verdiğiniz ve mail gönderen sunucuya işaret eden A/CNAME kayıtları
• VoIP, SFTP, FTP, RDP vb. HTTP dışı servisler

Neden? Çünkü Cloudflare sadece HTTP/HTTPS trafiğini proxy eder. Örneğin, MX kaydınız mail.example.com’a işaret ediyor ve bu A kaydı turuncu ise, gelen SMTP bağlantıları Cloudflare IP’lerine gider. Cloudflare SMTP konuşmasını bilmediği için bağlantı reddedilir veya zaman aşımına uğrar. Sonuç: E‑posta alamazsınız.

Benzer şekilde SPF kaydınızda a veya mx mekanizmalarını kullanıyorsanız, bu hostların da doğru IP’yi döndürmesi gerekir. Turuncu kayıtlar Cloudflare IP’si verdiği için SPF kontrolü karşı tarafta hatalı IP’ye göre yapılır ve SPF fail ile spam sorunu yaşarsınız. SPF tarafında detaylı senaryolar için Gelişmiş SPF yönetimi ve 10 DNS lookup limitini aşmadan çoklu e‑posta servisi kullanma rehberimize mutlaka göz atın.

Cloudflare Üzerinde Doğru DNS Kurulumu: Adım Adım

DCHost üzerinde barınan bir sitenizi Cloudflare DNS’e taşırken temel senaryo şu şekilde ilerler:

1. Cloudflare hesabı açılır, alan adı eklenir.
2. Cloudflare mevcut DNS kayıtlarını tarayıcı üzerinden içeri aktarır.
3. Bu kayıtlar DCHost panelinizle karşılaştırılır, eksikler tamamlanır.
4. Nameserver’lar domain kayıt firmasından Cloudflare’ın verdiği NS’lere çevrilir.
5. TTL ve proxy (turuncu/gri) ayarları optimize edilir.

Bu süreçte DNS yayılımını ve TTL stratejilerini doğru anlamak çok kritik. “Değişiklik yaptım, neden hemen yansımadı?” sorusunun arka planını detaylıca anlattığımız DNS yayılım süresi ve nasıl hızlandırılacağına dair rehberimize mutlaka göz atmanızı öneririz.

www ve Kök Alan Adı (Root) İçin DNS Tasarımı

Tipik bir senaryoda:

• example.com – A kaydı ile DCHost web sunucunuza işaret eder.
• www.example.com – A veya CNAME ile example.com’a işaret eder.

Cloudflare tarafında pratik yaklaşım:

• Hem example.com hem www.example.com için turuncu bulut (proxy) açık olsun.
• Sunucu tarafında ya da Cloudflare Page Rules / Redirect Rules ile tek bir canonical alan adını tercih edin (www’li veya çıplak alan adı).

Hangi domaini canonical seçeceğiniz konusunda kararsızsanız, www mi çıplak alan adı mı, canonical domain ve 301 stratejileri rehberimiz net bir yol haritası sunuyor.

Alt Alan Adları: panel, api, cdn, static…

Alt alan adlarını tasarlarken, her birinin arkasında hangi servis/protokolün çalıştığını netleştirin:

• panel.example.com – cPanel/DirectAdmin/Plesk gibi bir web arayüzü ise turuncu olabilir.
• api.example.com – REST/GraphQL servisi ise turuncu olabilir (WAF ve rate limit için de avantajlı).
• cdn.example.com – Statik dosyalar için turuncu yapmak mantıklıdır.
• sftp.example.com – SFTP için kullanılıyorsa mutlaka gri olmalıdır.
• db.example.com – Veritabanı bağlantıları için asla turuncu yapılmamalıdır.

API ve mikroservis trafiğini Cloudflare üzerinden geçirirken, Cloudflare ile rate limiting stratejileri kurarak istek fırtınalarına karşı da kendinizi koruyabilirsiniz.

E‑Posta İçin MX ve İlgili Kayıtlar

E‑posta tarafında ideal Cloudflare DNS şablonu şu şekildedir:

• MX: example.com → mail.example.com (priority 10)
• A: mail.example.com → 1.2.3.4 (DCHost mail sunucunuz) – gri (DNS only)
• TXT (SPF): v=spf1 a mx include:...
• TXT (DKIM): default._domainkey.example.com → uzun-public-key
• TXT (DMARC): _dmarc.example.com → v=DMARC1; p=quarantine; rua=...

Burada kritik noktalar:

• mail.example.com A kaydı gri olmalı.
• SPF kaydınızda a veya mx mekanizması kullanıyorsanız, bu hostların IP’leri gerçek mail sunucunuza ait olmalı.
• DKIM ve DMARC kayıtları TXT olarak girilir, bunlar için proxy seçeneği zaten yoktur.

SPF, DKIM ve DMARC kavramlarını temelden oturtmak için SPF, DKIM ve DMARC’ı sıfırdan kurma rehberimizi okumanız büyük avantaj sağlar. E‑posta teslim edilebilirliği tarafında daha kapsamlı bir bakış istiyorsanız da e‑postalar neden spam klasörüne düşüyor kontrol listemiz çok işinize yarayacaktır.

Cloudflare SSL Modları: Off, Flexible, Full ve Full (Strict)

Cloudflare ayarlarında en kritik kararlardan biri, SSL/TLS modudur. Dört temel seçenek var:

• Off – Cloudflare ziyaretçi ile HTTP üzerinden konuşur, HTTPS yoktur (modern dünyada tercih edilmemeli).
• Flexible – Ziyaretçi → Cloudflare arası HTTPS, Cloudflare → sunucu arası HTTP. Arka tarafta şifreleme yok.
• Full – Her iki tarafta da HTTPS var, ancak sunucu sertifikasının doğruluğu sıkı kontrol edilmez.
• Full (Strict) – Hem ziyaretçi → Cloudflare hem Cloudflare → sunucu trafiği HTTPS ve sertifika zinciri tam doğrulamalı.

DCHost olarak her zaman Full (Strict) kullanmanızı öneriyoruz. Flexible mod kısa yoldan “HTTPS çalışsın” hissi verse de:

• Sunucu tarafında HTTP ile çalışan uygulamalarda mixed content ve yönlendirme döngüsü sorunlarına yol açabilir.
• Gerçekten uçtan uca şifreleme sağlamaz, özellikle hassas veriler için risklidir.

Full (Strict) modun arka planını ve CDN arkasında gerçek HTTPS kurulumunu daha derinlemesine ele aldığımız CDN arkasında Full (Strict) SSL kurulum rehberimizi okumanızı tavsiye ederiz.

Full (Strict) İçin Sunucuda Neler Gerekli?

Full (Strict) modun çalışması için origin (DCHost sunucunuz) üzerinde:

• Geçerli bir SSL sertifikası olmalı (Let’s Encrypt, ticari DV/OV/EV veya Cloudflare Origin Certificate).
• Sertifika doğru alan adına (CN/SAN) tanımlı olmalı.
• Sertifika ve ara sertifikalar eksiksiz zincir oluşturmalı.

DCHost paylaşımlı hosting ve birçok VPS çözümümüzde Let’s Encrypt AutoSSL ile sertifikalar otomatik üretilip yenilenebiliyor. Cloudflare tarafında Full (Strict) seçtiğinizde, Cloudflare origin’e bağlanırken bu sertifikayı kontrol ediyor ve zincir tam ise trafiği güvenli kabul ediyor.

Kurumsal veya e‑ticaret sitelerinde hangi SSL türünü seçeceğiniz konusunda kararsızsanız, DV, OV ve EV SSL sertifikaları arasındaki farkları anlattığımız rehber doğru sertifika tipini seçmenize yardımcı olacaktır.

HTTP’den HTTPS’e Geçiş, 301 Yönlendirme ve HSTS

Sadece Cloudflare’da SSL modunu açmak yetmez; tüm trafiği HTTPS’e zorlamak gerekir. Dikkat edilmesi gerekenler:

• Sunucuda veya Cloudflare Redirect Rules ile HTTP → HTTPS 301 yönlendirmesi kurun.
• Tek bir canonical alan adı (www veya kök) seçip diğerini 301 ile ona yönlendirin.
• HTTPS geçişi tamamlandıktan ve kararlı olduğundan emin olduktan sonra HSTS başlığı eklemeyi düşünün.

HTTP → HTTPS geçişinde SEO kaybı yaşamamak için, HTTP’den HTTPS’e geçiş rehberimizde hem 301 hem HSTS hem de arama motoru tarafındaki etkileri adım adım ele aldık.

E‑Posta DNS Kayıtları ve Cloudflare: MX, SPF, DKIM, DMARC

Cloudflare kullanırken en sık yaşanan kriz alanı e‑posta altyapısı. “Site açılıyor ama e‑postalar gitmiyor” cümlesini ne yazık ki çok sık duyuyoruz. Çoğunlukla sorun, MX ve ilişkili kayıtların yanlış proxy edilmesinden veya SPF/DKIM/DMARC kayıtlarının eksik/yanlış olmasından kaynaklanıyor.

MX Kayıtları: Gidiş ve Geliş Trafiğinin Ana Kapısı

MX (Mail Exchanger) kayıtları, alan adınıza gelen e‑postaların hangi sunucuya teslim edileceğini belirtir. Önemli noktalar:

• MX kaydının kendisi proxy edilemez, ancak işaret ettiği host (ör. mail.example.com) edilebilir; işte burada hata yapılır.
• MX’in işaret ettiği A kaydı her zaman gri (DNS only) olmalıdır.
• MX üzerinde kullandığınız host adının mutlaka bir A/AAAA kaydı olmalı, CNAME olmamalıdır.

DCHost üzerinde sadece e‑posta için hosting tasarlıyorsanız, web sitesi olmadan kurumsal mail kurma rehberimiz ile Cloudflare DNS tarafını da birlikte düşünerek sağlam bir mimari kurabilirsiniz.

SPF: Hangi Sunucular Adıma Mail Gönderebilir?

SPF, alan adınız adına hangi IP’lerin veya hostların e‑posta göndermeye yetkili olduğunu tarif eder. Cloudflare ile ilişkili kritik noktalar:

• SPF kaydı bir TXT kaydıdır, Cloudflare’da proxy seçeneği yoktur; sorun burada değil.
• Sorun, SPF içeriğinde kullandığınız a, mx veya mekanizmalarının işaret ettiği hostların yanlış proxy edilmesidir.
• Mail gönderen sunucunuzun IP’si ile SPF’in çözümlediği IP birebir uyuşmalıdır.

Örneğin, v=spf1 a mx ~all kullanıyorsanız, example.com ve MX’in işaret ettiği hostların A kayıtları, gerçek mail sunucusu IP’nizi vermelidir. Turuncu bulut açıksa SPF, Cloudflare IP’lerini görecek ve alıcı sunucu SPF kontrolünde sizi yetkisiz kabul edecektir.

DKIM: İçerik Bütünlüğü ve Sahtecilik Karşıtı İmza

DKIM, gönderdiğiniz e‑postaların header’ına kriptografik bir imza ekler ve alıcı bu imzayı DNS’teki public key ile doğrular. Cloudflare tarafında yapmanız gerekenler:

• Mail sunucunuzun ürettiği DKIM public key’ini TXT kayıt olarak ekleyin.
• Genellikle ad formatı selector._domainkey.example.com şeklindedir.
• Bu TXT kaydında proxy seçeneği yoktur; tek yapmanız gereken kaydı eksiksiz ve tam girmek.

DKIM’in düzgün çalışması, DMARC politikalarınız için de temel bir gereklilik olduğundan, e‑posta servisinizde DKIM’i mutlaka aktif hale getirin.

DMARC: SPF ve DKIM Sonuçlarına Göre Politika Uygulamak

DMARC, SPF ve DKIM sonuçlarına bakarak, alıcı sunuculara “eğer her ikisi de başarısızsa bu maille ne yapmalısın?” sorusuna cevap veren bir politika katmanıdır. Cloudflare tarafında:

• _dmarc.example.com adında bir TXT kaydı oluşturmanız gerekir.
• Örnek kayıt: v=DMARC1; p=quarantine; rua=mailto:[email protected]
• Bu kayıt da proxy edilmez; doğru format ve kademeli strateji önemlidir.

DMARC raporlarını nasıl okuyacağınızı ve politikayı p=none’dan p=reject seviyesine nasıl kademeli taşıyacağınızı adım adım anlattığımız DMARC raporları ve p=reject’e geçiş rehberimiz ile Cloudflare DNS tarafındaki kayıtlarınızı çok daha bilinçli yönetebilirsiniz.

Cloudflare Üzerinde Örnek E‑Posta DNS Yapılandırması

Örnek bir Cloudflare DNS tablosu şöyle görünebilir:

• A – example.com → 203.0.113.10 – turuncu
• A – www → 203.0.113.10 – turuncu
• A – mail → 203.0.113.20 – gri (DNS only)
• MX – example.com → mail.example.com (priority 10)
• TXT – example.com → v=spf1 a mx -all
• TXT – default._domainkey → uzun-dkim-key
• TXT – _dmarc → v=DMARC1; p=quarantine; rua=mailto:[email protected]

Bu yapılandırmada web trafiği Cloudflare üzerinden güvenli ve hızlı gelirken, e‑posta trafiği doğrudan DCHost mail sunucunuza gider; böylece iki dünyayı temiz şekilde ayırmış olursunuz.

Cloudflare + DCHost Altyapısında Önerilen En İyi Uygulamalar

DCHost altyapısında Cloudflare ile birlikte çalışan yüzlerce site gördüğümüz için, pratikte iyi çalışan birkaç kalıp yaklaşımı özetleyelim.

Paylaşımlı Hosting veya Reseller Kullananlar İçin

• Cloudflare’ı sadece DNS ve HTTP proxy katmanı olarak düşünün; e‑posta, FTP, cPanel gibi servisler doğrudan DCHost sunucularına bağlansın.
• mail.example.com, cpanel.example.com, ftp.example.com gibi kayıtları gri (DNS only) bırakın.
• Web siteniz için Full (Strict) modda çalışın, AutoSSL (Let’s Encrypt) ile sertifikaları güncel tutun.
• DNS kayıtlarınızın temel mantığını tazelemek isterseniz, A, AAAA, CNAME, MX, TXT ve SRV kayıtları rehberimize göz atın.

VPS, Dedicated veya Colocation Kullananlar İçin

• Cloudflare’ı hem güvenlik (WAF, DDoS koruma) hem de performans için aktif kullanın.
• Nginx/Apache üzerinde TLS 1.3, modern şifre kümeleri ve OCSP stapling gibi ayarlarla origin tarafını sertleştirin; bu konuyu TLS 1.3 ve modern şifreler rehberimizde detaylandırdık.
• Cloudflare üzerinde orange cloud’u sadece HTTP/HTTPS servis eden alt alanlarda açın.
• E‑posta için ayrı bir gönderim alanı veya alt alan kullanma senaryosunu düşünüyorsanız, ayrı gönderim alan adı ve DNS stratejisi rehberimiz size yol gösterebilir.

Cloudflare DNS mi, Hosting DNS’i mi?

Her projede mutlaka Cloudflare DNS kullanılmak zorunda değil. Bazı mimarilerde DCHost DNS altyapısını kullanmak daha pratik olabilir. Bu karar; çok bölgeli mimari, SLA beklentiniz, anycast gereksinimi, yönetim kolaylığı gibi kriterlere göre verilmeli. Bu konuyu artıları ve eksileriyle tarttığımız Cloudflare DNS mi, hosting DNS’i mi? En doğru nameserver stratejisi yazımızı mutlaka okumanızı tavsiye ederiz.

En Sık Yapılan Hatalar ve Hızlı Kontrol Listesi

Cloudflare – DNS – SSL – e‑posta üçgeninde sahada en sık rastladığımız hataları kısa bir liste halinde toparlayalım:

• mail.example.com A kaydının turuncu yapılması → E‑postalar gelmez/gidemez.
• MX’in var olup işaret ettiği A kaydının olmaması → Mail sunucusuna ulaşılamaz.
• Flexible SSL kullanıp sunucuyu HTTP bekleyecek şekilde ayarlamamak → Yönlendirme döngüsü, 525/526 hataları.
• Hem Cloudflare hem sunucu tarafında agresif yönlendirme kuralı → Sonsuz 301 döngüleri.
• SPF kaydında turuncu hostlara a/mx ile referans vermek → SPF fail, spam sorunları.
• DKIM veya DMARC eklememek → Güvenilirlik düşük, sahtecilik riski yüksek.
• www ve çıplak alan için farklı içerik sunmak → SEO karmaşası, canonical hataları.

DNS kayıtlarınızı baştan sona gözden geçirmek isterseniz, A’dan Z’ye DNS kayıtları ve sizi yakan küçük hatalar rehberimiz ile bu listeyi daha da detaylandırabilirsiniz.

Sonuç: Cloudflare DNS ve SSL Ayarlarını Stratejiyle Yönetmek

Cloudflare, doğru kullanıldığında hem güvenlik hem performans hem de esneklik açısından inanılmaz güçlü bir katman sunuyor. Ancak küçük bir turuncu bulut tıklaması veya yanlış seçilmiş bir SSL modu; web sitesinin kapanmasına, e‑postaların kaybolmasına ve SEO tarafında ciddi sorunlara yol açabiliyor. Bu yüzden Cloudflare’ı “sihirli kutu” değil, DNS, SSL/TLS ve e‑posta altyapınızın bir parçası olarak ele almak gerekiyor.

DCHost olarak amacımız, altyapınızın her katmanının birbirini tamamlamasını sağlamak. İster paylaşımlı hosting, ister yönetilen VPS, ister dedicated sunucu veya colocation kullanın; Cloudflare yapılandırmanızı doğru yaptığınızda hem sunucu kaynaklarını daha verimli kullanır, hem de son kullanıcılara çok daha tutarlı bir deneyim sunarsınız. DNS kayıtlarınızı ve SSL modunuzu bu rehberde anlattığımız prensiplere göre gözden geçirerek başlayabilir, ardından ihtiyaç duyarsanız DCHost destek ekibinden Cloudflare – DNS – SSL – e‑posta mimarinizi birlikte kontrol etmesini isteyebilirsiniz.

Sonraki adım olarak özellikle şu yazılarımıza göz atmanızı öneririz:

• CDN arkasında gerçek HTTPS ve Full (Strict) SSL kurulumu
• SPF, DKIM ve DMARC ile e‑posta doğrulamasını sıfırdan kurma rehberi
• Cloudflare DNS mi, hosting DNS’i mi? En doğru nameserver stratejisi

Böylece Cloudflare katmanını da DCHost altyapınızın tutarlı bir parçası haline getirip, hem web siteniz hem de e‑posta altyapınız için sağlam, güvenli ve ölçeklenebilir bir temel kurabilirsiniz.