TXT Kaydı Kullanımı: Domain Doğrulama, SPF, DKIM ve DMARC

TXT kaydı, DNS tarafında en çok karıştırılan ama en sık kullanılan kayıt türlerinden biridir. Site açılışını doğrudan yöneten bir A kaydı kadar görünür değildir; buna rağmen alan adı doğrulama, e-posta güvenliği ve üçüncü taraf servis entegrasyonlarında kritik rol oynar. Özellikle bir domain yeni kurulduğunda veya mevcut altyapı başka servise taşındığında, eksik ya da hatalı TXT kayıtları birçok doğrulama sürecini durdurabilir.

Pratikte TXT kaydı iki ana amaçla öne çıkar: birincisi alan adının size ait olduğunu kanıtlamak, ikincisi e-posta gönderiminde güven ilişkisi kurmak. Bu nedenle TXT kaydını yalnızca “küçük bir doğrulama metni” gibi görmek doğru olmaz. Aslında bu kayıt, domain yönetimi ile e-posta güvenliği arasındaki en önemli köprülerden biridir. Temel kayıt mantığını önce genel çerçevede görmek isterseniz DNS kayıt türleri yazısı iyi bir başlangıç sağlar.

TXT Kaydı Hangi İşlerde Kullanılır?

TXT kaydı, bir alan adına düz metin tabanlı bilgi eklemek için kullanılır. Ancak bu düz metin rastgele bir açıklama olmak zorunda değildir. Çoğu zaman servis sağlayıcıları, belirli formatta anahtar-değer bilgisi ister ve bu metin DNS üzerinden okunarak doğrulama yapılır.

En yaygın kullanım alanları şunlardır: Google Search Console gibi servislerde domain sahipliği doğrulama, Microsoft 365 veya benzeri platformlarda alan adı onayı, SPF kaydı ile yetkili gönderici tanımlama, DKIM anahtar yayınlama ve DMARC politikası oluşturma. Yani tek bir kayıt türü, birbirinden farklı ama birbiriyle ilişkili pek çok işlemi taşır.

Domain Doğrulama Kayıtları Nasıl Çalışır?

Domain doğrulama mantığı basittir: servis sağlayıcı size benzersiz bir TXT değeri verir, siz bu değeri DNS'e eklersiniz, servis de sorgu yaparak gerçekten alan adını yönetebildiğinizi doğrular. Buradaki mantık, DNS paneline kayıt ekleyebilen kişinin alan adının yönetim yetkisine sahip olduğunu kabul etmektir.

Google Search Console tarafında bu kayıt çoğu zaman aşağıdaki biçimde görünür:

google-site-verification=AbCdEf1234567890_ornek_dogrulama_degeri

Google, Search Console yardım sayfasında DNS doğrulama kaydı olarak tipik biçimde google-site-verification=... değerini gösterir ve doğrulamanın sürdürülebilmesi için kaydın silinmemesi gerektiğini belirtir. Bu nedenle doğrulama tamamlandıktan sonra kaydı hemen kaldırmak iyi bir alışkanlık değildir.

Microsoft 365 tarafında ise doğrulama kaydı genellikle MS=msXXXXXXXX biçimindedir. Microsoft Learn, bu TXT kaydının yalnızca alan adı sahipliğini doğrulamak için kullanıldığını ve istenirse daha sonra silinebileceğini belirtir. Yine de ekiplerin çoğu, ileride yeniden kontrol ihtimali doğabileceği için bu kayıtları düzenli şekilde bırakmayı tercih eder.

SPF, DKIM ve DMARC Aynı Şey Değildir

TXT kaydı denince çoğu kullanıcı yalnızca “bir doğrulama kodu” düşünür. Oysa e-posta güvenliği tarafında TXT kaydı çok daha geniş bir rol üstlenir. SPF, DKIM ve DMARC çoğu panelde TXT olarak eklenir; fakat işlevleri birbirinden farklıdır.

SPF, hangi sunucuların sizin alan adınız üzerinden e-posta göndermeye yetkili olduğunu tanımlar. DKIM, giden e-postalara kriptografik imza mantığı ekler. DMARC ise SPF ve DKIM sonuçlarına göre alıcı sunucuların nasıl davranacağını belirler. Bu nedenle bu kayıtların hepsi TXT tabanlı olabilir, ama aynı görevi yapmaz.

@                TXT   "v=spf1 include:_spf.google.com ~all"
default._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."
_dmarc           TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

SPF tarafında en kritik kurallardan biri şudur: bir domain için birden fazla SPF kaydı bırakılmamalıdır. Microsoft Learn, birden çok SPF TXT kaydı bulunduğunda teslimat ve spam sınıflandırma sorunları çıkabileceğini açıkça belirtir. Yani farklı servislerin istediği SPF değerleri ayrı ayrı eklenmez; tek kayıt içinde birleştirilir.

E-posta yönlendirme tarafının tamamını birlikte okumak için MX kaydı ayarları yazısı da yararlıdır. Çünkü TXT tarafındaki SPF, DKIM ve DMARC mantığı genellikle MX kaydı planı ile beraber değerlendirilmelidir.

Host, Ad ve Değer Alanlarında Neden Karışıklık Yaşanır?

TXT kaydı eklerken en yaygın sorunlardan biri, panelin istediği alan adlarının birbirinden farklı olmasıdır. Bir panel Host alanı isterken başka biri Name, bir diğeri Record Name veya Subdomain ifadesi kullanabilir. Aynı şekilde kök domain için kimi paneller @ bekler, kimileri boş bırakılmasını ister.

Bu fark yüzünden doğru değeri yanlış yere yazmak çok sık görülür. Örneğin _dmarc alt alanı oluşturulması gerekirken tüm tam domain adı yazılabilir ya da bunun tersi olabilir. Bu nedenle kayıt eklerken yalnızca değere değil, panelin alan mantığına da dikkat etmek gerekir.

Bir başka karışıklık da tırnak işaretleridir. Bazı sağlayıcılar TXT değerini otomatik olarak tırnak içinde saklar, bazıları ise kullanıcının doğrudan düz metin girmesini ister. Bu nedenle panel örnekleri ile gerçek DNS çıktısının birebir aynı görünmemesi her zaman hata anlamına gelmez.

TXT Kaydı Ekledikten Sonra Nasıl Kontrol Edilir?

Kayıt eklendikten sonra en sık yaşanan durum, panelde “kaydedildi” görünmesine rağmen doğrulamanın henüz tamamlanmamasıdır. Bunun nedeni çoğu zaman DNS yayılım sürecidir. TTL değerine, sağlayıcının önbellek yapısına ve sorgulayan servisin kontrol aralığına bağlı olarak TXT kaydı birkaç dakikadan birkaç saate kadar gecikmeli görünebilir.

Bu noktada kaydın gerçekten dışarıdan görünür olup olmadığını kontrol etmek gerekir. TXT sonucunu hızlı görmek için DNS lookup aracı ile ilgili alan adının TXT yanıtlarını kontrol etmek pratik bir adımdır. Amaç burada yalnızca “kayıt var mı” demek değil, doğru host altında ve doğru değerle görünüp görünmediğini karşılaştırmaktır.

Özellikle aynı alan adı altında birden fazla TXT kaydı bulunduğunda, yanlış kaydın geldiğini sanmak kolaydır. Bu yüzden kontrol sırasında yalnızca kayıt tipine değil, birebir değer eşleşmesine bakılmalıdır.

Google ve Microsoft Doğrulamalarında Pratik Farklar

Google Search Console doğrulamasında TXT kaydı çoğu zaman kalıcı olarak tutulur; çünkü erişimin devam etmesi için doğrulama kaydının DNS üzerinde kalması beklenebilir. Bu yüzden doğrulama tamamlanınca kaydı silmek yerine düzenli kayıt yapısının bir parçası olarak bırakmak daha güvenli olur.

Microsoft 365 tarafında ise doğrulama TXT kaydı yalnızca alan adı sahipliğini kanıtlamak için kullanılır ve Microsoft'un bazı resmi kurulum yönergelerinde daha sonra silinebileceği belirtilir. Buna rağmen ekip içi kayıt düzeni açısından bu tür doğrulama kayıtlarını açıklamalı şekilde saklamak çoğu zaman daha pratiktir.

Buradaki temel çıkarım şudur: tüm TXT kayıtları aynı kalıcılık mantığıyla değerlendirilmez. Bir kayıt sadece ilk doğrulama için gerekli olabilirken, başka bir kayıt düzenli teslimat veya politika kontrolü için sürekli gerekli olabilir.

Yaygın TXT Kaydı Hataları

İlk yaygın hata, aynı amaç için birden fazla kayıt eklemektir. Özellikle SPF tarafında farklı servislerin önerdiği değerleri ayrı TXT kayıtları olarak bırakmak sık görülür. Oysa bu yapı çoğu zaman teslimat sorununa neden olur.

İkinci hata, host alanını yanlış kullanmaktır. Kök domain için @ yerine tam alan adı yazmak ya da tam tersi uygulamak kaydın yanlış yerde oluşmasına neden olabilir. Bu durumda panelde kayıt görünür ama sorgu yapan servis onu doğru konumda bulamaz.

Üçüncü hata, doğrulama tamamlanmadan kaydı silmektir. Özellikle Search Console tarafında kayıt kaldırıldığında doğrulama durumunun ileride bozulması mümkündür. Bu nedenle hangi kaydın geçici, hangisinin kalıcı etkili olduğunu ayırmak gerekir.

Dördüncü hata ise TXT kaydını ekledikten hemen sonra panik yapmaktır. TTL süresi dolmadan ve yayılım tamamlanmadan kesin sonuca varmak doğru değildir. Bu tür durumlarda önce kaydı dışarıdan doğrulamak, ardından gerekiyorsa beklemek daha sağlıklı yaklaşım olur.

TXT Kayıtlarını Düzenli Yönetmek İçin Kısa Plan

TXT kayıtları küçük görünür ama dağınık bırakıldığında DNS yönetimini gereksiz ölçüde zorlaştırır. Düzenli isimlendirme, kısa açıklama notları ve hangi kaydın ne işe yaradığını bilen bir ekip düzeni, ileride çıkabilecek doğrulama ve teslimat sorunlarını ciddi ölçüde azaltır.

TXT kayıtları küçük görünse de dağınık bırakıldığında doğrulama ve teslimat sorunlarının başlıca kaynağına dönüşür. Hangi kaydın ne amaçla eklendiğini bilmek, mükerrer kayıtları temizlemek ve sonucu dışarıdan doğrulamak uzun vadede en güvenli yönetim biçimidir.