DNS kayıtları, alan adınızın hangi sunucuya, hangi posta servisine ve hangi doğrulama bilgilerine sahip olduğunu internete anlatan talimat satırlarıdır: A kaydı siteyi bir IP adresine, MX kaydı e-postayı bir posta sunucusuna, CNAME bir adı başka bir ada, TXT ise alan adınızı doğrulama ve e-posta güvenliği bilgilerine bağlar. Alan adı paneline ilk kez girdiğinizde karşınıza çıkan bu kısaltmalar karmaşık görünür, ancak her birinin tek ve net bir görevi vardır. Bu rehberde her kayıt tipinin ne işe yaradığını, nerede hata yapıldığını ve değişikliği nasıl doğrulayacağınızı pratik örneklerle anlatıyoruz.
Tarayıcıya bir alan adı yazdığınızda bilgisayarınız o adın hangi IP adresine karşılık geldiğini bilmez. Bunu öğrenmek için bir çözümleyiciye (resolver) sorar; çözümleyici de sırasıyla kök sunuculara, uzantı sunucularına ve son olarak alan adınızın yetkili isim sunucusuna (nameserver) giderek cevabı bulur.
DNS kayıtlarınızın tutulduğu yer bu yetkili isim sunucusudur. Bu yüzden alan adı panelinizde ilk belirlemeniz gereken şey kayıtlar değil, nameserver'lardır. Nameserver'lar hostinginize işaret etmiyorsa, panelinizde ne yazarsanız yazın hiçbir kayıt devreye girmez — çünkü internet kayıtlarınızı başka bir yerde arıyordur. DNS sorunlarının belki üçte biri tam olarak bu tek yanlıştan doğar.
A kaydı, bir alan adını IPv4 adresine bağlar. En temel kayıttır; sitenizin görünmesini sağlayan şey budur.
Türkiye (Türkçe)
Worldwide (English)
@ → 203.0.113.10 — alan adının kendisi (kök/apex)www → 203.0.113.10 — www alt alan adıtest → 203.0.113.25 — farklı bir sunucuya işaret eden alt alan adıAAAA kaydı aynı işi IPv6 adresleri için yapar. IPv6 desteği olan bir sunucudaysanız A ve AAAA kayıtlarını birlikte tanımlamak doğru yaklaşımdır; desteklemeyen bir altyapıda AAAA kaydı tanımlamak ise bazı ziyaretçilerde bağlantı hatasına yol açar.
Alt alan adı mantığı basittir: panelde blog yazarsanız bu blog.alanadiniz.com anlamına gelir. Bazı paneller tam adı yazmanızı ister, bazıları yalnızca ön eki. Yanlış girilen bir alt alan adı çoğu zaman blog.alanadiniz.com.alanadiniz.com gibi çift uzantılı bir kayıt üretir.
CNAME kaydı bir adı başka bir ada yönlendirir. Örneğin www → alanadiniz.com tanımlarsanız, ana alan adının IP'si değiştiğinde www kaydını ayrıca güncellemeniz gerekmez.
Burada bilinmesi gereken kritik bir kural var: alan adının kökünde (apex) CNAME kullanılamaz. RFC 1034'ün kuralı nettir — bir isimde CNAME varsa o isimde başka hiçbir veri bulunamaz. Ancak alan adının kökünde SOA, NS ve genellikle MX kayıtları zorunlu olarak bulunur. Bu yüzden alanadiniz.com için CNAME tanımlamak bölgeyi bozar ve alan adınız çözümlenemez hale gelir.
Bir CDN veya platform size kökte CNAME tanımlamanızı söylüyorsa çözüm, DNS sağlayıcınızın ALIAS veya ANAME kaydını desteklemesidir. Bu kayıtlar standart değildir; istemciye CNAME döndürmek yerine sunucu tarafında hedefi çözüp yerine A/AAAA kaydı üretirler. Sağlayıcınız desteklemiyorsa tek pratik yol, hedefin IP adresini alıp normal bir A kaydı tanımlamaktır — ancak hedef IP değişirse siteniz düşeceği için bu yöntem risk taşır.
MX kaydı, alan adınıza gelen e-postanın hangi sunucuya teslim edileceğini söyler. Sitenizin A kaydıyla hiçbir ilgisi yoktur; site bir yerde, e-posta bambaşka bir yerde barındırılabilir.
MX kayıtlarının bir öncelik (priority) değeri vardır ve burada küçük sayı daha yüksek öncelik demektir. Öncelik 10 olan sunucu, öncelik 20 olandan önce denenir; ilki yanıt vermezse ikincisi devreye girer.
@ MX 10 mail.alanadiniz.com@ MX 20 mail2.alanadiniz.comEn sık yapılan hatalar: harici bir posta servisine (Google Workspace, Microsoft 365 gibi) geçerken eski hosting MX kaydını silmemek — bu durumda e-postaların bir kısmı eski sunucuya düşer ve kaybolur; ve MX kaydını bir IP adresine yönlendirmek — MX kaydı IP değil, ad gösterir. IP'yi önce bir A kaydına bağlayın, MX kaydını o ada yöneltin.
TXT kayıtları serbest metin tutar ve iki amaçla kullanılır: alan adı sahipliğini doğrulamak ve e-posta kimlik doğrulaması yapmak. İkincisi 2024'ten bu yana isteğe bağlı olmaktan çıkmıştır.
Google Search Console, Microsoft 365 veya bir ödeme sağlayıcısı size bir metin verip DNS'e eklemenizi ister. Bu, alan adının gerçekten sizin olduğunu kanıtlar. Doğrulama tamamlandıktan sonra bile bu kayıtları genellikle silmemeniz gerekir; servis periyodik olarak yeniden kontrol eder.
Alan adınız adına hangi sunucuların e-posta gönderebileceğini listeler. Tek bir TXT kaydı olarak tanımlanır:
v=spf1 include:_spf.saglayici.com ~all
Bir alan adında yalnızca tek bir SPF kaydı bulunabilir. İki ayrı SPF kaydı tanımlamak doğrulamayı tamamen geçersiz kılar — hem hostinginizin hem de pazarlama e-postası servisinizin sunucularını yetkilendirmek istiyorsanız ikisini de aynı satırda include: ile birleştirin.
Giden e-postalarınızı kriptografik olarak imzalar. Posta sağlayıcınız size bir seçici (selector) ve bir açık anahtar verir; bunu secici._domainkey.alanadiniz.com biçiminde bir TXT kaydı olarak eklersiniz. Alıcı sunucu, imzayı bu anahtarla doğrulayarak mesajın yolda değiştirilmediğini kontrol eder.
SPF ve DKIM başarısız olduğunda ne yapılacağını söyler ve raporlama sağlar:
_dmarc TXT v=DMARC1; p=none; rua=mailto:[email protected]
p değeri politika seviyesidir: none yalnızca izler, quarantine şüpheli mesajı spam klasörüne düşürür, reject ise tamamen reddeder. Doğru yaklaşım p=none ile başlayıp raporları birkaç hafta okumak, meşru gönderim kaynaklarınızın tamamını yetkilendirdikten sonra kademeli olarak sıkılaştırmaktır.
Şubat 2024'ten itibaren Google, Gmail hesaplarına e-posta gönderen tüm göndericilerden en az SPF veya DKIM, geçerli ileri/geri DNS (PTR) kaydı, TLS bağlantısı ve %0,3'ün altında spam oranı talep etmeye başladı. Günde 5.000'den fazla mesaj gönderenlerde ise SPF, DKIM ve DMARC'ın üçü birden, From alanının SPF veya DKIM alan adıyla hizalanması ve pazarlama mesajlarında tek tıkla abonelikten çıkma zorunludur.
Microsoft da Outlook.com, Hotmail ve Live adreslerine toplu gönderim yapanlar için benzer kuralları Mayıs 2025'te devreye aldı. 2026 itibarıyla her üç büyük sağlayıcı da uyumsuz gönderimleri geçici olarak değil, kalıcı olarak reddediyor. Yani kurumsal e-posta kullanan her işletme için bu kayıtlar artık teknik bir tercih değil, teslim edilebilirliğin ön koşuludur.
Alan adının yetkili isim sunucularını belirtir. Alt alan adı yetkisini başka bir sağlayıcıya devretmek dışında elle düzenlemeniz gereken bir kayıt değildir.
Belirli bir servisin hangi sunucuda ve hangi portta çalıştığını bildirir. En yaygın kullanımı oyun ve ses sunucularıdır: bir SRV kaydıyla oyuncularınız port numarası yazmadan yalnızca alan adıyla bağlanabilir.
Alan adınız için hangi sertifika otoritelerinin SSL sertifikası üretebileceğini sınırlar. CAA kaydı yoksa varsayılan davranış, alan adı kontrolünü doğrulayan her genel sertifika otoritesinin sertifika üretebilmesidir. Tek bir satır bu riski daraltır:
@ CAA 0 issue "letsencrypt.org"
IP adresinden alan adına doğru çalışan ters kayıttır. Alan adı panelinizden değil, IP'nin sahibi olan sunucu sağlayıcısından tanımlanır. Kendi sunucunuzdan e-posta gönderiyorsanız PTR kaydının doğru olması teslim edilebilirlik için kritiktir.
TTL (Time To Live), bir kaydın çözümleyiciler tarafından kaç saniye önbellekte tutulacağını belirtir. 3600 (1 saat) yaygın bir değerdir. TTL yüksekse değişiklikleriniz yavaş yayılır, düşükse DNS sunucularınıza daha çok sorgu gelir.
Pratik yöntem: sunucu taşıma gibi planlı bir değişiklikten en az bir gün önce TTL'i 300 saniyeye düşürün, taşımayı yapın, her şey oturduktan sonra tekrar yükseltin. Böylece geri dönüş gerekirse dakikalar içinde etkili olur.
Değişikliği doğrulamak için tarayıcıya bakmayın — tarayıcı ve işletim sistemi kendi önbelleğini tutar. Doğrudan sorgulayın:
dig alanadiniz.com A +short — A kaydını gösterirdig alanadiniz.com MX +short — MX kayıtlarını listelerdig _dmarc.alanadiniz.com TXT +short — DMARC kaydını okurdig alanadiniz.com NS +short — yetkili isim sunucularını gösterirnslookup -type=MX alanadiniz.comFarklı ülkelerden yayılımı görmek isterseniz çevrimiçi DNS kontrol araçları birden fazla noktadan sorgu yapar. "Bende eski hâli görünüyor" sorununun cevabı genellikle önbellektir, hata değil.
include: ile birleştirin.Nubitro'dan aldığınız alan adlarının DNS kayıtlarını müşteri panelinizden yönetebilir; A, AAAA, CNAME, MX, TXT, SRV ve CAA kayıtlarını buradan tanımlayabilirsiniz. Alan adı ve hosting aynı panelde olduğu için hosting siparişinizde A ve MX kayıtları otomatik yapılandırılır — çoğu kullanıcı için elle kayıt girmeye hiç gerek kalmaz.
Tüm alan adı kayıtlarında ücretsiz WHOIS koruması sağlanır, hosting paketlerinde ise ücretsiz SSL sertifikası bulunur. Yeni bir alan adı almak veya müsaitlik sorgulamak için alan adı sorgulama sayfasını, mevcut alan adınızı taşımak için alan adı transferi sayfasını kullanabilirsiniz.
Henüz alan adı seçmediyseniz alan adı nasıl seçilir yazımız uzantı ve isim kararında yol gösterir. Alan adını bağlayacağınız barındırma için profesyonel SSD hosting paketlerine bakabilir, siteyi yayına aldıktan sonra WordPress sitenizi hızlandırma rehberimizle performans ayarlarını tamamlayabilirsiniz.
Kaydın TTL değeri kadar. TTL 3600 ise en geç bir saat içinde çözümleyicilerin çoğu yeni değeri görür. Nameserver değişiklikleri ise uzantı seviyesinde işlendiği için 24 saate kadar sürebilir.
Site A kaydıyla, e-posta MX kaydıyla çalışır; biri doğruyken diğeri yanlış olabilir. Önce dig alanadiniz.com MX +short ile MX kaydının doğru sunucuyu gösterdiğini doğrulayın, sonra eski bir MX kaydının kalıp kalmadığına bakın.
Evet, çünkü bunlar ayrı kayıtlardır. Genellikle biri A kaydı, diğeri o ada işaret eden CNAME olarak tanımlanır. İkisinin de tanımlı olduğundan emin olun; yalnızca birini tanımlamak ziyaretçilerin bir kısmını hata sayfasına düşürür.
Teknik olarak gönderirsiniz, ancak mesajlarınız büyük olasılıkla spam klasörüne düşer veya doğrudan reddedilir. Büyük sağlayıcılar 2024'ten bu yana bu kayıtları zorunlu tutuyor ve uyumsuz gönderimleri kalıcı olarak reddediyor.
Olur ama gereksizdir. Düşük TTL, DNS sunucularına gelen sorgu sayısını artırır ve her ziyaretçi için ek çözümleme gecikmesi doğurabilir. Doğru yaklaşım, yalnızca planlı değişiklik öncesi geçici olarak düşürmektir.
Nameserver'larınız değişmiyorsa kayıtlar olduğu yerde kalır ve transfer sitenizi etkilemez. Nameserver da değişecekse transfer öncesi mevcut tüm kayıtların bir listesini alın ve yeni sağlayıcıda birebir yeniden oluşturun.
dig veya nslookup ile yapın.