En Sık Yapılan DNS Hataları: Web Sitesi ve E‑Postayı Uçurmadan Önce Kontrol Etmeniz Gereken 10 Kayıt

DNS Ayarlarında Küçük Hata, Büyük Kesinti: Nerede Takılıyoruz?

Web siteniz ve kurumsal e‑postanız çalışıyorsa, çoğu zaman DNS’i hiç düşünmeyiz. Ama alan adınızı yeni hostinge taşıyınca, e‑posta servisini değiştirince veya Cloudflare gibi bir CDN ekleyince, en ufak bir DNS hatası bile saatlerce süren erişim sorunlarına, “mail gelmiyor” şikayetlerine ve SEO tarafında istenmeyen sonuçlara yol açabiliyor. DCHost ekibi olarak yeni gelen projelerde en çok vakit harcadığımız yerlerden biri, bozuk veya dağınık DNS kayıtlarını toparlamak.

Bu yazıda “DNS nedir?” düzeyinde temel anlatımdan çok, gerçek dünyada en sık patlayan 10 DNS kaydı üzerine odaklanacağız. Hedefimiz basit: Alan adınızın DNS paneline girdiğinizde, web sitesi ve e‑postayı uçurmadan önce bakmanız gereken kritik noktaları net bir kontrol listesi haline getirmek. Teknik terimleri mümkün olduğunca sadeleştirerek ve sahadan örneklerle anlatacağım; böylece ister ajans olun, ister KOBİ, ister tek geliştirici, kendi alan adınızın DNS sağlığını güvenle kontrol edebileceksiniz.

Kontrol Listesi: Web Sitesi ve E‑Postayı Uçurmadan Önce Bakmanız Gereken 10 DNS Kaydı

Başlamadan önce, DNS kayıt türleriyle ilgili kapsamlı bir özet istiyorsanız, DNS kayıtları A’dan Z’ye rehberimize mutlaka göz atın. Burada ise doğrudan “en sık yapılan hatalar” perspektifinden ilerleyeceğiz.

1. NS Kayıtları: Yanlış Yetkili DNS Sunucuları

NS (Name Server) kayıtları, alan adınızın “DNS’ine kim bakıyor?” sorusunun cevabıdır. Yani tarayıcılar ve diğer DNS çözücüler, hangi DNS sunucularından A, MX, TXT gibi kayıtları alacağını NS kayıtları sayesinde bilir. En sık gördüğümüz sorun, alan adının NS kayıtlarının bir yere, gerçek kayıtların ise başka bir DNS paneline yazılı olması.

DCHost’a proje taşıyan bir ajans müşterisinde şu senaryoyu sık görüyoruz:

• Alan adı kayıt firmasında NS kayıtları hâlâ eski hosting firmasını gösteriyor.
• Ajans yeni A, MX, SPF kayıtlarını DCHost DNS paneline giriyor.
• Sonuç: Ziyaretçiler ve e‑posta trafiği eski DNS’e baktığı için, yapılan hiçbir değişiklik etkisini göstermiyor.

Kontrol etmeniz gerekenler:

• Alan adının registry tarafındaki NS kayıtları ile fiilen kullandığınız DNS panelinin NS adresleri birebir aynı mı?
• Aynı alan adı için iki farklı DNS sağlayıcıda paralel kayıt tutmuyor musunuz?
• Her nameserver çifti için NS kayıtları en az iki sunucu gösteriyor mu (ns1 / ns2 gibi)?

Özellikle hosting veya DNS sağlayıcısı değiştirirken NS kayıtlarını doğru taşımak için, DNS ve domain taşıma kontrol listemizi sürecin başında elinizin altında tutmanız çok faydalı olur.

2. A / AAAA Kayıtları: Yanlış IP Adresi veya Eski Sunucuya Bakan Site

A kaydı (IPv4) ve AAAA kaydı (IPv6), alan adınızı hangi IP adresine yönlendireceğinizi belirler. En kritik hatalardan biri, yanlış veya eski IP’ye bakan A/AAAA kayıtlarıdır. Bu genellikle şu durumlarda ortaya çıkar:

• Yeni hosting veya VPS’e geçilmiş, fakat DNS’te A kaydı hâlâ eski IP’yi gösteriyor.
• Geçici test sunucusu için açılan IP, yayına taşındıktan sonra temizlenmiyor ve yanlışlıkla live site o IP’ye çekiliyor.
• IPv6 (AAAA) ekleniyor ancak sunucu tarafında IPv6 konfigürasyonu hazır değil, site bazı kullanıcılar için açılmaz hale geliyor.

Öneriler:

• Alan adınız (ör. example.com) için A kaydının sadece tek bir IP’ye bakmasına özen gösterin (özel bir geo-DNS mimariniz yoksa).
• AAAA kaydı eklemeden önce, VPS veya sunucunuzda IPv6’nın gerçekten doğru yapılandırıldığından emin olun.
• Taşıma sonrası, eski IP’yi mutlaka not alın ama aktif DNS kayıtlarından temizleyin; karışıklığı azaltır.

IP değişimlerinde DNS yayılım süresinin neden bazen 24 saate kadar uzayabildiğini daha iyi anlamak için, DNS yayılımı ve hızlandırma rehberimizi inceleyebilirsiniz.

3. Kök Alan Adı (example.com) ve www Tutarsızlıkları

Birçok projede kök alan adı (example.com) ve www.example.com için farklı DNS stratejileri izleniyor. En sık gördüğümüz sorunlar:

• example.com için A kaydı var, ama www.example.com hiç tanımlı değil (www’li URL’ler açılmıyor).
• Hem kök alan adı hem de www alt alanı farklı IP’lere bakıyor; bazen staging, bazen prod, bazen farklı ülkedeki sunucu.
• CDN kullanırken köke A, www’ye CNAME veriliyor ama hedefler yanlış ayarlanmış; birinde CDN, diğerinde direkt origin çalışıyor.

İyi pratik yaklaşım:

• Genellikle www.example.com için bir CNAME kullanıp kök alan adına yönlendirmek daha düzenli bir mimari sağlar.
• Kök alan adı için A kaydı (ve gerekiyorsa AAAA) tanımlayın; www’nin CNAME ile bu kaydı işaret etmesi işleri sadeleştirir.
• Tüm SEO ve HTTPS stratejinizi (www mi, çıplak domain mi?) belirleyip, bu kararı DNS + 301 yönlendirme ile tutarlı hale getirin. Bu konuda ayrıntılı örnekler için www mi çıplak alan adı mı rehberimize göz atabilirsiniz.

4. MX Kayıtları: E‑Postanın Gittiği Yeri Karıştırmak

MX kayıtları, alan adınız için hangi sunucunun e‑posta kabul ettiğini belirler. E‑posta kesintilerinin önemli bir kısmı, yanlış veya eksik MX kayıtlarından kaynaklanıyor. Tipik hatalar:

• Yeni hosting’e geçerken web sitesi taşınıyor ama MX kayıtları unutuluyor; e‑postalar hâlâ eski sunucuya gitmeye çalışıyor.
• MX kaydı bir alan adını gösteriyor ama bu alan adı için A kaydı yok (veya yanlış IP’ye bakıyor); e‑posta geri dönüyor.
• Birden fazla MX tanımlanmış ama öncelik (priority) değerleri gelişigüzel verilmiş; backup MX asıl MX’ten daha yüksek öncelikte.

Nelere dikkat etmelisiniz?

• MX kayıtları mutlaka bir alan adına işaret etmeli, doğrudan IP’ye değil.
• MX’in işaret ettiği alan adları için mutlaka A (ve gerekiyorsa AAAA) kayıtları tanımlı olmalı.
• Tek bir ana mail sunucusu kullanıyorsanız, priority değeri örneğin 10 olabilir; varsa yedek MX’ler daha yüksek değer (20, 30) almalı.

Yeni bir e‑posta altyapısına geçerken sıfır kesinti hedefliyorsanız, MX ve diğer kayıtların nasıl planlanması gerektiğini e‑posta altyapısı taşırken kesinti yaşamama rehberimizde ayrıntılı anlattık.

5. SPF (TXT) Kayıtları: 10 DNS Lookup Limitine Çarpmak ve Yanlış İzinler

SPF kaydı, alan adınız adına hangi sunucuların e‑posta göndermeye yetkili olduğunu tanımlar. Hata türü çok, ama en sık gördüklerimiz şunlar:

• Birden fazla SPF kaydı: Örneğin hem hosting paneli hem de üçüncü parti bir servis SPF ekliyor; sonuçta iki SPF TXT kaydı oluşuyor ve bu geçersiz.
• Gereğinden fazla include: ile 10 DNS lookup limitine çarpıp, SPF’in fiilen boşa düşmesi.
• “Test için” eklenen +all gibi aşırı geniş izinlerin unutulması; spam gönderen herkes bu alan adı adına mail atabiliyor.

İyi pratikler:

• Her alan adı için sadece 1 adet SPF TXT kaydı olmalı.
• SPF kaydını düzenlerken hangi sistemlerin gerçekten e‑posta gönderdiğini netleştirin: Hosting sunucusu, transactional servis, pazarlama aracı vb.
• “10 lookup” limitine yaklaştıysanız, gelişmiş SPF yönetimi ve lookup limitini aşmadan çoklu servis kullanma rehberimize mutlaka bakın.

6. DKIM Kayıtları: Eksik Anahtar, Yanlış Selector, Yanlış TXT Formatı

DKIM, e‑postanın gövdesine kriptografik bir imza ekleyerek, mesajın iletim sırasında değiştirilmediğini ve gerçekten sizin altyapınızdan çıktığını ispatlar. DNS tarafında ise DKIM, genellikle selector._domainkey.example.com şeklinde bir TXT kaydı olarak tutulur.

Sahada gördüğümüz yaygın hatalar:

• DKIM public key’i uzun olduğu için TXT kaydı yanlış bölünmüş; bazı DNS panelleri satır kırma ister, bazıları istemez.
• Yanlış selector: Mail sunucusu mail2024 selector’üyle imza atıyor, DNS’te ise default._domainkey tanımlı.
• E‑posta servisi değiştirilirken eski DKIM kayıtları silinmiyor, yenisi eklenmiyor; DMARC raporlarında sürekli “dkim=fail” görünüyor.

Kontrol listesi:

• Kullandığınız her e‑posta kaynağı (hosting, transactional servis vb.) için ilgili DKIM TXT kaydı gerçekten DNS’te tanımlı mı?
• Selector adları e‑posta servisi panelindekiyle birebir aynı mı?
• TXT değeri panelin desteklediği biçimde (tek satır veya doğru bölünmüş çok satır) kaydedildi mi?

7. DMARC Kayıtları: Yanlış Politika, Yanlış Rapor Adresi, Eksik Kurulum

DMARC, SPF ve DKIM sonuçlarına bakarak, geçersiz e‑postalar için alıcı sunucuların ne yapacağını (kabul, karantina, reddet) belirlemenizi sağlar. Ayrıca DMARC raporları, alan adınız adına kimlerin mail göndermeye çalıştığını görmeniz için çok kıymetlidir.

En sık yapılan hatalar:

• Hiç DMARC kaydı olmaması: Özellikle marka değeri olan alan adlarında ciddi bir açık kapı.
• Bir anda p=reject ile başlamak ve yanlış yapılandırılmış SPF/DKIM yüzünden kendi maillerinizi bile reddettirmek.
• Rapor e‑posta adreslerini (rua, ruf) yanlış yazmak ya da geçersiz mailbox’lara yönlendirmek; değerli raporlar boşa gidiyor.

Nasıl ilerlemelisiniz?

• Önce p=none ile başlayıp, DMARC raporlarını bir süre izleyin.
• SPF ve DKIM başarısızlıklarını düzelttikçe, politikayı yavaş yavaş quarantine ve reject tarafına çekin.
• Bu kademeli geçişi nasıl yorumlayacağınızı ve raporları nasıl okuyacağınızı p=none’dan p=reject’e geçiş rehberimizde adım adım anlattık.

8. PTR (Reverse DNS) Kayıtları: İmzasız Gönderen IP

Özellikle kendi VPS’inizden veya dedicated sunucunuzdan e‑posta gönderiyorsanız, PTR (reverse DNS) kritik bir DNS kaydıdır. Alıcı mail sunucuları genellikle gönderen IP’nin ters DNS kaydına bakar ve bu kaydın, mail başlığındaki alan adıyla tutarlı olmasını bekler.

En sık karşılaştığımız problemler:

• PTR hiç tanımlı değil: IP, generic bir ISP host adıyla görünüyor; spam skorunu yükseltiyor.
• PTR, alan adınızla ilgisiz bir hostname’e işaret ediyor; SPF/DKIM düzgün olsa bile teslim edilebilirliği düşürüyor.
• IP değiştirildiğinde reverse DNS güncellenmiyor; yeni IP’den giden mailler bir anda spam klasörlerine düşmeye başlıyor.

Öneriler:

• PTR, mümkünse mail.example.com gibi e‑posta için kullandığınız host adına işaret etsin.
• Bu host için A kaydının da aynı IP’yi göstermesi gerekir; böylece forward-reverse DNS tutarlı olur.
• PTR ayarı genellikle IP sağlayıcınız tarafında yapılır; DCHost VPS veya dedicated sunucu kullanıyorsanız, destek talebiyle PTR’ı sizin adınıza doğru şekilde tanımlayabiliriz. Ayrıntılar için PTR ve e‑posta teslimi rehberimize bakabilirsiniz.

9. CNAME’i Yanlış Yerde Kullanmak: Kökte CNAME, MX’e CNAME, Zincirli Yönlendirmeler

CNAME, bir alan adını başka bir alan adına yönlendirmek için harika bir kayıttır; ancak yanlış kullanıldığında ciddi sorunlara yol açar. Özellikle şu hataları sık görüyoruz:

• Kök alan adında CNAME: Birçok DNS standardına ve kayıt firmasına göre kök alan adında CNAME kullanmak sorunludur; SOA, NS gibi kayıtlarla çakışır.
• MX’in CNAME’i işaret etmesi: MX kayıtları doğrudan A (ve gerekirse AAAA) kaydı bulunan bir hostname’e işaret etmelidir, CNAME zincirleri kabul edilmez.
• Çok katmanlı CNAME zincirleri: Örneğin www başka bir alan adına, o alan adı bir üçüncüsüne CNAME; her ek halka, hem gecikme hem de hata ihtimalini artırır.

Doğru yaklaşım:

• Kök alan adı için A/AAAA kullanın; gerekiyorsa alt alanlarda (www, cdn, statik vb.) CNAME’den faydalanın.
• MX daima bir hostname’e gitmeli; o hostname’in A/AAAA kaydı doğrudan IP’yi göstermeli.
• CNAME zincirlerini mümkün olduğunca tek halkaya indirgeyin; hata ayıklamayı da ciddi biçimde kolaylaştırır.

10. TTL ve SOA Değerleri: Yanlış Ön Bellek Süreleri, Bitmeyen Yayılım Problemleri

TTL (Time To Live), bir DNS kaydının DNS önbelleklerinde ne kadar süre saklanacağını belirler. Yanlış TTL değerleri yüzünden, aslında düzelttiğiniz bir hata ziyaretçiler için saatlerce devam ediyormuş gibi görünebilir. SOA kaydındaki varsayılan TTL ve diğer zaman parametreleri de bu davranışı etkiler.

En sık yaşanan TTL kaynaklı problemler:

• Taşıma öncesinde TTL değerleri çok yüksek (ör. 86400 sn / 24 saat) bırakılıyor; IP değişince yayılım çok yavaş görünüyor.
• Sürekli değişmeyecek kayıtlar (ör. MX, SPF) için gereksiz düşük TTL veriliyor; tüm dünyada gereksiz DNS trafiği oluşuyor.
• Cloudflare gibi CDN’ler kullanılırken, DNS TTL ve CDN cache TTL kavramları birbirine karıştırılıyor.

Stratejik ayar önerileri:

• Taşıma veya büyük değişikliklerin 24–48 saat öncesinde kritik kayıtların TTL’ini düşürün (ör. 300 sn).
• Stabil kayıtlar için orta seviye TTL (ör. 3600–14400 sn) genellikle yeterlidir.
• TTL planlamasını detaylı ele aldığımız DNS TTL stratejisi rehberimizi ve taşıma sırasında yayılımı hızlandırmak için zero‑downtime TTL oyun planını mutlaka inceleyin.

Özellikle Cloudflare gibi bir proxy/CDN araya girdiğinde, DNS ve SSL tarafında ek katmanlar devreye giriyor. Bu noktada, Cloudflare DNS ve SSL ayarlarını doğru yapmak yazımız, pratik senaryolarla sık yapılan hataları düzeltmenize yardımcı olacaktır.

Gerçek Sorunları Teşhis Etmek: Sorun DNS mi, Sunucu mu?

DCHost’ta en sık aldığımız destek taleplerinden biri “Site açılmıyor, sorun sunucuda olmalı.” cümlesiyle başlıyor; ancak teşhise geçtiğimizde problemin büyük kısmının DNS katmanında olduğunu görüyoruz. Yanlış NS, boşta kalmış alt alanlar, eksik A kaydı, hatalı CNAME… Liste uzayıp gidiyor.

Özellikle DNS_PROBE_FINISHED_NXDOMAIN gibi hatalar alıyorsanız, NXDOMAIN teşhis rehberimizde adım adım anlattığımız teşhis sürecini takip ederek, sorunun gerçekten DNS’ten mi, sunucudan mı kaynaklandığını çok hızlı şekilde netleştirebilirsiniz.

DNS tarafı temizlendikten sonra hâlâ performans veya kaynak sıkıntısı yaşıyorsanız, o noktada iş CPU, RAM, disk I/O ve network analizine; yani hosting mimarisine kayıyor. Bu tarafı da DCHost’ta paylaşımlı hosting, VPS, dedicated sunucu veya colocation seçenekleriyle birlikte planlıyoruz; ama her şeyden önce DNS temelinin sağlam olması şart.

Özet ve Yol Haritası: DNS’i Bir Defa Düzeltin, Uzun Süre Rahat Edin

DNS çoğu zaman “bir kere kur, unut” gözüyle bakılan ama yanlış kurgulandığında aylarca görünmez sorunlar çıkaran bir katman. Bu yazıda özetlediğimiz 10 kayıt, DCHost ekibi olarak günlük işimizde en sık karşımıza çıkan, gerçek projeleri etkileyen hataların neredeyse tamamını kapsıyor:

• Yanlış NS ve karışık DNS panelleri
• Eski IP’lere bakan A/AAAA kayıtları
• Kök domain ve www tutarsızlıkları
• Eksik veya hatalı MX
• Çakışan SPF ve lookup limit problemleri
• Eksik/yanlış DKIM ve agresif DMARC politikaları
• Tanımsız veya alakasız PTR
• Yanlış yerde kullanılan CNAME’ler
• Kötü planlanmış TTL ve uzayan yayılım sorunları

Pratik yol haritası şöyle olabilir: Önce alan adınızın DNS panelini açın, bu 10 maddeyi tek tek kontrol edin ve not alın. Gerekiyorsa staging bir alan adı veya alt alan üzerinde test değişiklikleri yapıp, dig, nslookup gibi araçlarla çıktıları doğrulayın. Özellikle e‑posta tarafında SPF, DKIM, DMARC ve PTR kombinasyonunu doğru kurduğunuzda, spam klasörü şikayetlerinin ne kadar hızlı azaldığını bizzat göreceksiniz.

Eğer DNS tarafında nereden başlayacağınızı kestiremiyorsanız veya çok alan adlı, çok bölgeli bir mimari yönetiyorsanız, DCHost tarafında alan adı, DNS ve hosting mimarinizi birlikte ele alarak, hem web sitesi hem e‑posta altyapınız için uzun vadeli, sürdürülebilir bir tasarım oluşturmanıza yardımcı olabiliriz. Yeni projeye başlamadan veya büyük bir taşıma planlamadan önce, bu 10 DNS kaydını check‑list’inizin başına yazın; sonradan çıkacak sürprizleri ciddi oranda azaltırsınız.