DNS, satıcıların en çok küçümsediği ve en pahalıya ödediği konudur. Çoğu kişi şöyle düşünür: "Alan adını aldım, hostinge bağladım, gerisi detay." Sonra ilk hafta garip şeyler olur. Site bazı cihazlarda açılır bazılarında açılmaz. Ödeme sağlayıcısı geri dönüş adresini doğrulayamaz. Sipariş mailleri müşterinin spam klasörüne düşer. Bunların hiçbiri e-pin scripti hatası değildir; hepsi yanlış veya yarım kalmış DNS yapılandırmasıdır.
İşin ilginç yanı, DNS aslında sadece birkaç kayıt satırından oluşur. Karmaşık olan şey kayıtların kendisi değil, hangi kaydın neyi kontrol ettiğini bilmemektir. Bu yazıda alan adı seçiminden başlayıp kanonik adres kararına, TTL yönetiminden Cloudflare arkasına geçmeye ve mail doğrulama kayıtlarına kadar bütün zinciri sırayla açacağız. Sonunda, yayına çıkmadan önce kontrol etmen gereken kayıtların tam listesi elinde olacak.
Domain seçimi neden teknik değil ticari bir karar?
Alan adı, müşterinin ödeme ekranında gördüğü tek güven işaretidir. Kart bilgisini gireceği anda adres çubuğuna bakar ve orada okuduğu şey ona güven verir ya da vermez. Bu yüzden seçimde üç şeye bakmanı öneririm: okunduğu gibi yazılabilmesi, kısa olması ve uzantının hedef kitleye uygun olması. Türkiye pazarına satış yapıyorsan .com ilk tercih, .com.tr kurumsal algıyı güçlendirir ama şirket belgesi gerektirir.
Kaçınman gereken şeyler de var: tire içeren adresler sözlü anlatımda kaybolur, sayı içerenler yazımda karışır, Türkçe karakterli adresler bazı mail istemcilerinde ve API doğrulamalarında sorun çıkarır. Ayrıca oyun ve marka adlarını doğrudan alan adına koymak, marka hakkı açısından ileride sıkıntı yaratabilir. Bir e-pin satış scripti üzerine kuracağın işin ömrü yıllarla ölçülür; alan adını da o ömre göre seç, kampanyaya göre değil.
A kaydı, CNAME, nameserver: hangi kayıt neyi yapar?
Bu üçünü karıştırmak en yaygın hatadır. Nameserver (NS), alan adının DNS kayıtlarının nerede yönetildiğini söyler; yani "bu domainin adres defteri şu sunucuda" der. A kaydı, bir adı doğrudan bir IP adresine bağlar. CNAME ise bir adı başka bir ada takma ad olarak bağlar. Hosting sağlayıcının nameserver'larını kullanıyorsan kayıtları onun panelinden yönetirsin; Cloudflare gibi bir servis kullanıyorsan kayıtlar orada durur.
Pratik kural şudur: kök alan adı (ornek.com) için A kaydı kullan, alt alan adları (www, panel, api) için CNAME veya A kaydı kullan. İkisini aynı ad için birlikte tanımlamaya çalışmak çakışma üretir. Bir başka sık hata, nameserver'ları Cloudflare'a verdikten sonra kayıtları eski hosting panelinde düzenlemeye devam etmektir; o panel artık dinlenmez ve saatlerce "neden değişmiyor" diye beklenir. Kayıt düzenlemeden önce hangi panelin yetkili olduğunu doğrula.
| Kayıt tipi | Ne yapar | Örnek kullanım | Önerilen TTL |
|---|---|---|---|
| A | Adı IPv4 adresine bağlar | ornek.com → sunucu IP | 300-3600 sn |
| AAAA | Adı IPv6 adresine bağlar | IPv6 destekli sunucu | 300-3600 sn |
| CNAME | Adı başka bir ada yönlendirir | www → ornek.com | 3600 sn |
| MX | Mail sunucusunu belirtir | Kurumsal e-posta | 3600 sn |
| TXT (SPF) | Gönderim yetkisi tanımlar | SMTP sunucusunu yetkilendirme | 3600 sn |
| TXT (DKIM) | Mail imzasını doğrular | Teslimat maillerinin imzası | 3600 sn |
| TXT (DMARC) | Uyumsuz maile ne yapılacağını söyler | Marka koruması | 3600 sn |
| NS | Yetkili DNS sunucusunu gösterir | Hosting veya CDN nameserver | Sağlayıcı varsayılanı |
www mi kök alan adı mı? Kanonik tercih neden önemli?
Sitenin hem ornek.com hem www.ornek.com üzerinden açılıyor olması iyi bir şey değil; bir tanesi asıl adres olmalı, diğeri ona yönlenmeli. Buna kanonik adres denir. Hangisini seçtiğin önemli değil, tutarlı olman önemli. Aynı içerik iki farklı adresten servis edilirse arama motoru tarafında bölünme, oturum ve sepet tarafında ise beklenmeyen çıkışlar yaşarsın. Müşteri www'lu adreste sepet doldurup www'suz adrese düştüğünde sepeti boş görebilir.
Yönlendirmeyi DNS ile değil sunucu tarafında kalıcı yönlendirme (301) ile yapmak en doğrusudur. Aynı anda HTTPS zorlamasını da ekle: hem http'den https'e hem seçmediğin varyanttan kanonik adrese tek adımda gitsin. Zincirleme yönlendirme (http → https → www → kök) hız kaybettirir. Dijital ürün satış yazılımı kurulumunda site adresi ayarını da kanonik adresle birebir aynı yazmalısın; ödeme geri dönüş URL'leri bu ayardan üretilir ve tek harf farkı doğrulamayı bozar.
Kurulum sonrası DNS kaynaklı arızaların dağılımı
- Mail kayıtları eksik, teslimat maili spam 35%
- Kanonik adres / www karmaşası 30%
- Yanlış panelde kayıt düzenleme 23%
- SSL ve proxy modu çakışması 12%
TTL ve propagasyon: taşınma gününde neden panik olur?
TTL, bir DNS kaydının ara sunucularda ne kadar süre önbellekte tutulacağını söyler. Değeri 86400 saniye ise, kaydı değiştirsen bile bazı kullanıcılar bir gün boyunca eski adresi görmeye devam eder. Bu yüzden sunucu değiştirmeyi planlıyorsan, taşınmadan en az bir gün önce ilgili kayıtların TTL değerini 300 saniyeye düşür. Taşınma tamamlanıp her şey stabil olduktan sonra tekrar yükseltirsin.
Propagasyon sırasında yaşanan en sinir bozucu durum, sitenin senin bilgisayarında yeni sunucudan, müşterinin bilgisayarında eski sunucudan açılmasıdır. Bu dönemde iki sunucuda da site ayakta kalsın; eskisini kapatırsan bir kısım müşteri hata görür. Sipariş kaybını engellemek için taşınma penceresinde eski sunucuda bakım modu değil, çalışan ama yeni siparişe kapalı bir durum tercih et. Böylece ziyaretçi boş sayfa görmez, sen de iki veritabanına bölünmüş sipariş derdi yaşamazsın.
Cuma akşamı taşınma yapma. Propagasyon 24 saati bulabilir ve hafta sonu hem hosting hem ödeme sağlayıcısı desteği yavaşlar. En güvenli pencere hafta içi sabah, siparişin en düşük olduğu saattir.
Cloudflare arkasına almak: kazanç ve tuzaklar
Alan adını bir CDN ve güvenlik katmanı arkasına almak dijital ürün satışında gerçek fayda sağlar: bot trafiği filtrelenir, statik içerik hızlanır, saldırı anında kaynak sunucu görünmez. Ama üç tuzağı var. Birincisi, kayıtların artık o panelden yönetildiğini unutmaktır. İkincisi, mail için kullanılan kayıtları yanlışlıkla proxy'li (turuncu bulut) bırakmaktır; mail trafiği proxy'den geçmez, o kayıtlar doğrudan olmalıdır. Üçüncüsü SSL modudur.
SSL modunu "esnek" bırakırsan, ziyaretçi ile CDN arası şifreli, CDN ile sunucun arası şifresiz olur. Bu durum ödeme akışlarında sonsuz yönlendirme döngüsü ve karışık içerik uyarıları üretir. Doğru ayar, kaynak sunucuda geçerli sertifika kurup tam (strict) modu seçmektir. Ayrıca e-pin yazılımı tarafında ziyaretçinin gerçek IP adresini loglamak istiyorsan, proxy başlıklarını okuyacak şekilde yapılandırma yapmalısın; aksi halde tüm siparişler aynı IP'den gelmiş gibi görünür ve dolandırıcılık kontrolü işe yaramaz.
Mail kayıtlarını (SPF/DKIM/DMARC) atlarsan ne olur?
Dijital ürün satışında teslimat bir e-postadır. O mail spam'e düşerse ürün teslim edilmemiş sayılır, müşteri destek talebi açar, açmadıysa doğrudan iade ister. Bu yüzden mail doğrulama kayıtları isteğe bağlı değildir. SPF kaydı, hangi sunucuların senin adına mail gönderebileceğini söyler. DKIM, gönderilen mailin yolda değiştirilmediğini kriptografik imzayla kanıtlar. DMARC ise bu ikisine uymayan maile ne yapılacağını belirler.
Kurulumda sık yapılan hata, birden fazla SPF kaydı tanımlamaktır; standart tek kayda izin verir, ikincisini eklersen ikisi de geçersiz sayılabilir. Tüm gönderici kaynaklarını (hosting SMTP'si, kurumsal mail servisi, varsa pazarlama aracı) tek SPF satırında birleştir. DMARC'ı ise kademeli kur: ilk hafta yalnızca rapor topla, veriler temizse katı politikaya geç. Kurulum öncesi hazırlık kalemlerinin tamamını görmek istersen özellikler ve fiyat bölümleri iyi bir başlangıç noktası.
| Yayın öncesi kontrol | Nasıl doğrularsın | Beklenen sonuç | Öncelik |
|---|---|---|---|
| Kök alan adı açılıyor | Tarayıcıda https://ornek.com | Site yükleniyor, sertifika geçerli | Kritik |
| www varyantı yönleniyor | www'lu adresi dene | Kanonik adrese 301 | Kritik |
| HTTPS zorlaması aktif | http:// ile gir | Tek adımda https'e geçiş | Kritik |
| Site adresi ayarı doğru | Panel yapılandırmasını aç | Kanonik adresle birebir aynı | Kritik |
| MX kaydı doğru ve proxy'siz | DNS panelinde kontrol | Doğrudan, gri bulut | Kritik |
| Tek SPF kaydı var | TXT kayıtlarını listele | Tüm göndericiler tek satırda | Kritik |
| DKIM imzası yayında | Test maili başlıklarını incele | İmza doğrulandı | Yüksek |
| DMARC raporlama açık | TXT kaydını doğrula | Rapor adresi tanımlı | Orta |
| TTL taşınma için düşürüldü | A kaydı TTL değeri | 300 saniye | Taşınma öncesi |
| Gerçek ziyaretçi IP loglanıyor | Sipariş kaydındaki IP'ye bak | Farklı ziyaretçi, farklı IP | Yüksek |
DNS zincirini bir kez doğru kur, yıllarca uğraşma
Pinova'nın kurulum dokümanı alan adı, SSL, kanonik adres ve mail kayıtları için hazır yapılandırma şablonlarıyla gelir.
Nameserver değişikliği ne kadar sürede tamamlanır?
Genelde 4-8 saat içinde büyük ölçüde tamamlanır, tam yayılma 24-48 saati bulabilir. Bu süre boyunca bazı ziyaretçiler eski, bazıları yeni sunucuyu görür; iki tarafı da ayakta tutmak en güvenli yaklaşımdır.
www mu kök alan adı mı kullanmalıyım?
Teknik olarak ikisi de doğru çalışır. Önemli olan birini kanonik seçip diğerini kalıcı yönlendirmeyle ona bağlamaktır. Yazılım tarafındaki site adresi ayarı da seçtiğin varyantla birebir aynı yazılmalıdır.
Cloudflare kullanırsam mail ayarlarım bozulur mu?
MX kaydını ve mail alt alan adlarını proxy'siz bırakırsan bozulmaz. Mail trafiği proxy üzerinden geçmez; o kayıtları doğrudan modda tutman gerekir. SSL modunu da tam olarak ayarlamayı unutma.
Sipariş mailleri spam'e düşüyor, DNS tarafında ne yapmalıyım?
Önce tek bir SPF kaydı olduğunu ve tüm gönderici sunucuları içerdiğini doğrula. Ardından DKIM imzasını etkinleştir ve test maili başlıklarında doğrulandığını gör. Son adım olarak DMARC kaydını rapor modunda ekle.
DNS, bir kez doğru kurulduğunda yıllarca kendi başına çalışan ama yarım bırakıldığında her gün küçük kayıplar üreten bir katmandır. Yukarıdaki kontrol tablosunu yayına çıkmadan önce tek tek işaretle; panel tarafında hangi ayarın hangi kayda karşılık geldiğini görmek istersen canlı demo üzerinden yapılandırma ekranlarını gez. Alan adın doğru bağlandığında geri kalan her şey çok daha basit hale gelir.