TXT Kaydı Nedir ve Kullanım Alanları

DNS dünyasında çoğu kayıt türünün tek ve net bir görevi vardır. A kaydı bir IP adresini işaret eder, MX kaydı e-postanın hangi sunucuya teslim edileceğini söyler, CNAME bir adı başka bir ada bağlar. TXT kaydı ise bu tablonun içinde biraz farklı durur. Onun görevi belirli bir hizmete adres göstermek değil, alan adınıza serbest biçimli metin bilgisi iliştirmektir. Bu sayede TXT kaydı yıllar içinde adeta DNS'in "not defteri" hâline gelmiş; e-posta güvenliğinden alan adı sahipliği doğrulamasına, hizmet entegrasyonlarından basit meta verilere kadar pek çok amaç için kullanılır olmuştur.

Bu esneklik hem TXT kaydının en büyük gücü hem de yeni başlayanlar için en kafa karıştırıcı yanıdır. Aynı alan adı altında bir SPF politikası, bir Google doğrulama dizesi ve bir DMARC kuralı yan yana durabilir; hepsi TXT kaydıdır ama içerikleri tamamen farklıdır. Bu rehberde TXT kaydının ne olduğunu, söz dizimi ve uzunluk kurallarını, birden fazla kaydın nasıl bir arada bulunabildiğini ve en sık karşılaşılan kullanım senaryolarını uygulamalı örneklerle ele alacağız. Amacımız, panelde "TXT kaydı ekle" dediğinizde ne yaptığınızı tam olarak bilmenizi sağlamak.

TXT Kaydı Nedir ve Ne İşe Yarar#

TXT (text) kaydı, bir alan adına ya da alt alan adına serbest metin verisi eklemenizi sağlayan bir DNS kayıt türüdür. İlk günlerde gerçekten de sadece insan tarafından okunabilecek açıklama notları için tasarlanmıştı. Zamanla makinelerin okuyup yorumlayabildiği yapılandırılmış diziler için standart bir taşıyıcıya dönüştü. Bugün bir TXT kaydının içeriği çoğunlukla belirli bir kurala göre biçimlendirilmiş metindir ve o metni okuyan sistem (bir e-posta sunucusu, bir doğrulama servisi, bir güvenlik aracı) neyi arayacağını önceden bilir.

TXT kaydının çalışma mantığını anlamak için şunu hatırlamak yeterli: DNS sadece bir sorgu-cevap sistemidir. Bir servis, alan adınızın TXT kayıtlarını sorgular, dönen metinler arasında kendisiyle ilgili olanı arar ve bulduğu değere göre karar verir. Örneğin bir e-posta alıcısı sunucu, gönderen alan adının SPF politikasını okumak için TXT kayıtlarına bakar; içinde v=spf1 ile başlayan diziyi bulur ve o politikaya göre mesajın meşru olup olmadığını değerlendirir. Kaydın kendisi hiçbir işlem yapmaz; sadece orada durur ve sorulduğunda okunur.

Bu pasif yapı, TXT kaydını neden bu kadar yaygın kıldığını da açıklar. Yeni bir doğrulama veya politika mekanizması icat etmek isteyen bir sağlayıcının, DNS'e yeni bir kayıt türü eklettirmesi gerekmez; mevcut TXT altyapısını kullanıp kendi biçimini tanımlaması yeterlidir. DNS'in nasıl çalıştığını daha temelden merak ediyorsanız DNS nedir yazısı iyi bir başlangıç noktası olacaktır.

TXT Kaydının Söz Dizimi ve Uzunluk Kuralları#

TXT kaydı bölge dosyasında (zone file) tipik olarak şu biçimde görünür:

; ad          TTL   sınıf  tür   değer
@             3600  IN     TXT   "v=spf1 include:_spf.clou.tr ~all"
google._domainkey  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Burada @ alan adının kökünü (örneğin ornek.com) temsil eder. Değer her zaman çift tırnak içine alınır. Tırnaklar TXT kaydının kritik bir parçasıdır çünkü metnin nerede başlayıp nerede bittiğini belirler ve içinde boşluk bulunan dizelerin tek bir parça olarak okunmasını sağlar. Çoğu kontrol panelinde tırnakları elle yazmanız gerekmez; arayüz alanına sadece metni girersiniz ve panel tırnakları arka planda ekler. Ama komut satırıyla ya da doğrudan bölge dosyasıyla çalışıyorsanız tırnakları kendiniz koymalısınız.

En çok gözden kaçan kural uzunlukla ilgilidir. DNS protokolü gereği tek bir TXT dizesi (string) en fazla 255 karakter olabilir. 255 karakteri aşan bir değer girmeniz gerektiğinde, değeri birden fazla tırnaklı parçaya bölersiniz; alıcı sistem bu parçaları birleştirerek tek metin gibi okur. Uzun DKIM anahtarlarında bu duruma sıkça rastlanır:

mail._domainkey  IN  TXT  ( "v=DKIM1; k=rsa; "
                            "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7..."
                            "...uzun anahtarın devamı..." )

Parantez ve satır bölme sadece bölge dosyası biçimidir; tel üzerinde bunlar birleştirilir. Panel arayüzü kullanıyorsanız çoğu panel 255 karakter sınırını otomatik olarak yönetir, siz uzun anahtarı tek satırda yapıştırırsınız. Bir başka nokta ise toplam boyut. Tek bir TXT kaydı içindeki tüm parçaların toplamı ve bir alan adındaki TXT kayıtlarının tümü, DNS cevabının UDP paket boyutuna sığması gerektiği için pratik bir üst sınıra tabidir. Aşırı sayıda ve aşırı uzun TXT kaydı, DNS cevaplarının TCP'ye düşmesine ve bazı istemcilerde çözümleme sorunlarına yol açabilir; bu yüzden gereksiz kayıtları biriktirmemek iyi bir alışkanlıktır.

Aynı Alan Adında Birden Fazla TXT Kaydı#

TXT kaydıyla ilgili en sık sorulan sorulardan biri şudur: "Zaten bir TXT kaydım var, yenisini eklersem eskisi silinir mi?" Cevap hayır. TXT, aynı ad altında birden fazla kaydın bir arada bulunabildiği kayıt türlerindendir. Yani ornek.com kökünde aynı anda hem bir SPF kaydı, hem bir Google doğrulama dizesi, hem de başka bir servisin doğrulama kaydı yan yana durabilir:

@  IN  TXT  "v=spf1 include:_spf.clou.tr ~all"
@  IN  TXT  "google-site-verification=aB3xYz9..."
@  IN  TXT  "MS=ms12345678"

Bir servis TXT kayıtlarını sorguladığında hepsini birden alır ve içinden kendi tanıdığı öneke sahip olanı seçer. SPF doğrulaması yapan sunucu v=spf1 ile başlayanı, Google ise google-site-verification= ile başlayanı okur. Bu yüzden farklı amaçlı TXT kayıtları birbirini etkilemez; her biri kendi tüketicisi tarafından ayrı ayrı yorumlanır.

Bu kuralın kritik bir istisnası vardır: SPF. Bir alan adında yalnızca bir tane SPF TXT kaydı bulunabilir. İki ayrı v=spf1 kaydı görürseniz e-posta alıcıları çoğu zaman politikayı geçersiz sayar (permerror) ve teslim edilebilirliğiniz düşer. İki farklı sağlayıcıdan e-posta gönderiyorsanız, iki ayrı SPF kaydı oluşturmak yerine bunları tek bir kayıtta include: ifadeleriyle birleştirmelisiniz. Aynı mantık, kök alan adı seviyesinde tek bir DMARC kaydının (_dmarc alt alanında) bulunması için de geçerlidir. SPF, DKIM ve DMARC'ın birlikte nasıl kurgulandığını ayrıntılı görmek için SPF, DKIM ve DMARC ile e-posta güvenliği yazısına göz atabilirsiniz.

En Yaygın TXT Kaydı Kullanım Alanları#

TXT kaydının bu kadar merkezî olmasının nedeni, kendini kanıtlayan bir avuç kullanım senaryosudur. Bunları tanıdığınızda panelinizde gördüğünüz gizemli metin dizeleri anlam kazanır.

SPF (Sender Policy Framework). Alan adınız adına hangi sunucuların e-posta göndermeye yetkili olduğunu belirten politikadır. Alıcı sunucu, gelen mesajın gerçekten sizin izin verdiğiniz bir kaynaktan gelip gelmediğini bu kayıttan kontrol eder ve sahte gönderenleri (spoofing) elemeye çalışır.

DKIM (DomainKeys Identified Mail). Giden e-postalarınıza dijital imza ekler; imzayı doğrulamak için gereken açık anahtar, bir alt alan adında (seçici._domainkey) TXT kaydı olarak yayımlanır. Alıcı bu anahtarla imzayı doğrular ve mesajın yolda değiştirilmediğinden emin olur.

DMARC. SPF ve DKIM sonuçlarına göre ne yapılacağını (izin ver, karantinaya al, reddet) ve raporların nereye gönderileceğini belirler; _dmarc.ornek.com altında TXT kaydı olarak durur.

Alan adı sahipliği doğrulaması. Google Search Console, Microsoft 365, Meta, Zoom, Atlassian gibi pek çok servis, alan adının gerçekten size ait olduğunu kanıtlamanız için size bir doğrulama dizesi verir. Bu dizeyi TXT kaydı olarak eklediğinizde servis DNS'i sorgular, dizeyi bulur ve sahipliği onaylar.

Aşağıdaki tablo bu senaryoların tipik biçimlerini özetler:

Kurumsal bir e-posta altyapısı işletiyorsanız bu kayıtların tümü birlikte çalışır; sadece birini kurmak yeterli koruma sağlamaz. Kendi e-posta çözümünüzü profesyonel e-posta hizmeti üzerinden ya da bir hosting paketiyle birlikte yönetiyorsanız, sağlayıcının verdiği hazır TXT değerlerini eklemeniz çoğu işi halleder.

TXT Kaydı Nasıl Oluşturulur#

TXT kaydı eklemek, kullandığınız DNS yönetim aracına göre biraz değişse de temel mantık her yerde aynıdır. Aşağıda cPanel Zone Editor üzerinden tipik bir akış anlatılıyor; benzer adımlar Clou.TR panelindeki DNS yöneticisi için de geçerlidir.

1. DNS bölgesine erişin. Hosting panelinizde ya da alan adı yönetim ekranınızda ilgili alan adının DNS/Zone Editor bölümünü açın.
2. Kayıt türü olarak TXT seçin. Yeni kayıt ekle diyerek tür listesinden TXT'yi işaretleyin.
3. Adı (host) girin. Kaydı kök alan adına eklemek istiyorsanız @ yazarsınız (veya alanı boş bırakırsınız, panele göre değişir). Alt alan adı için ise _dmarc ya da mail._domainkey gibi eki girersiniz.
4. Değeri yapıştırın. Servisin size verdiği metni tırnaksız olarak (panel tırnakları kendisi ekler) alana yapıştırın.
5. TTL belirleyin. Yaygın bir varsayılan 3600 saniyedir (1 saat). Sık değişecek bir kayıt kuruyorsanız test aşamasında 300 saniye gibi düşük bir değer, doğrulama sonrası ise daha yüksek bir değer mantıklıdır.
6. Kaydedin ve yayılmayı bekleyin. Değişiklik DNS boyunca yayılana kadar TTL süresi kadar (bazen biraz daha uzun) beklemeniz gerekebilir.

Komut satırından hızlı bir doğrulama yapmak isterseniz dig çok işinize yarar:

# Kök alan adının tüm TXT kayıtlarını listele
dig +short TXT ornek.com

# DMARC kaydını sorgula
dig +short TXT _dmarc.ornek.com

# Belirli bir DKIM seçicisini sorgula
dig +short TXT google._domainkey.ornek.com

Windows kullanıyorsanız aynı işi nslookup ile yapabilirsiniz:

nslookup -type=TXT ornek.com

Otomasyon ya da toplu yönetim tarafında, bir bölge dosyasını doğrudan düzenlerken TXT satırının biçimi şöyledir. Örneğin BIND için:

$TTL 3600
@   IN  TXT  "v=spf1 include:_spf.clou.tr -all"
_dmarc  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

Kendi sunucunuzu ve DNS'inizi yönetiyorsanız, kayıtları elle düzenlerken sözdizimi hatalarına karşı named-checkzone gibi araçlarla doğrulama yapmak, bölgenin canlıya çıkmadan tutarlı olduğundan emin olmanızı sağlar. Sunucu tarafı bakım ve yapılandırma yükünü devretmek isteyenler için sunucu yönetimi hizmeti bu tür işleri sizin adınıza üstlenir.

TXT Kaydını Doğrulama ve Sorun Giderme#

TXT kaydı ekledikten sonra en sık yaşanan sıkıntı, servisin "doğrulama başarısız" demeye devam etmesidir. Bunun neredeyse her zaman birkaç tipik nedeni vardır ve sırayla elemek çözüme götürür.

Yayılmayı beklemediniz. DNS değişiklikleri anında görünmez. Eski TTL süresi boyunca çözümleyiciler önbelleğe alınmış eski cevabı verebilir. Kaydı ekledikten sonra dig ile gerçekten yayıldığını gördüğünüzden emin olmadan doğrulama düğmesine defalarca basmak işe yaramaz.

Yanlış host adına eklediniz. DMARC _dmarc altında, DKIM seçici._domainkey altında olmalıdır; bunları köke (@) eklerseniz servis bulamaz. Tersine, kök seviyesindeki bir doğrulama dizesini yanlışlıkla www altına koymak da klasik bir hatadır.

Fazladan boşluk veya tırnak soktunuz. Değeri kopyalarken başına/sonuna görünmez boşluk gelmesi ya da panelin zaten eklediği tırnakların üzerine bir de sizin tırnak yazmanız, kaydı geçersiz kılar. Değer ""v=spf1..."" gibi çift tırnaklı görünüyorsa fazlalık var demektir.

Birden fazla SPF kaydı var. Yukarıda değindiğimiz gibi ikinci bir v=spf1 kaydı politikanızı bozar. Elinizdeki tüm gönderici sağlayıcıları tek bir SPF satırında toplayın.

Doğrulama için sadece dig yeterli olmadığında, kaydın farklı çözümleyicilerde nasıl göründüğünü kontrol etmek isteyebilirsiniz. Aşağıdaki tablo, tipik hata belirtileri ve olası nedenlerini eşleştirir:

Bir noktadan sonra kaydı hem dig +short TXT hem de bağımsız bir çözümleyici (örneğin dig @1.1.1.1 TXT ornek.com) üzerinden aynı görüyorsanız, sorun büyük olasılıkla artık DNS'te değil, servisin kendi tarafındadır ve o servisin destek yönergelerini izlemek gerekir.

TXT Kayıtlarında İyi Uygulamalar#

TXT kayıtlarını düzenli tutmak, ileride yaşayacağınız e-posta ve doğrulama sorunlarının çoğunu baştan önler. Birkaç pratik kural bu düzeni kurmanıza yardımcı olur.

Öncelikle artık kullanılmayan kayıtları temizleyin. Bir servisle ilişkinizi kestiğinizde ya da doğrulama tamamlanıp o dizeye ihtiyaç kalmadığında, bazı servisler dizeyi silmenize izin verir. Yıllar içinde birikmiş onlarca ölü doğrulama dizesi hem karmaşa yaratır hem de DNS cevaplarını gereksiz büyütür. İkincisi, SPF'te tek kayıt disiplinine sadık kalın ve include zincirini olabildiğince kısa tutun; SPF'in 10 DNS sorgusu sınırı, çok sayıda sağlayıcı eklendiğinde sessizce aşılır ve politikanız çalışmayı bırakır.

Üçüncüsü, kritik kayıtlarda değişiklik yapmadan önce mevcut değeri yedekleyin. Özellikle DKIM ve DMARC kayıtlarında yanlış bir düzenleme, e-posta teslimatını doğrudan etkiler; eski değeri bir yere not etmek geri dönüşü kolaylaştırır. Dördüncüsü, TTL'i amaca göre ayarlayın. Sık test edeceğiniz bir kayıt için düşük TTL, oturmuş bir yapılandırma için ise daha yüksek TTL uygundur; sürekli düşük TTL, çözümleyicilerin sürekli yeniden sorgu yapmasına neden olur. Son olarak, alan adı ve DNS altyapınızı tek bir yerden yönetmek bu disiplini kolaylaştırır; alan adı yönetimi ile hosting hizmetlerinizi aynı panelde toplamak, TXT kayıtlarını takip etmeyi çok daha pratik hâle getirir.

Sıkça Sorulan Sorular#

TXT kaydı ile SPF kaydı arasındaki fark nedir?#

Aslında ortada iki ayrı kayıt türü yoktur. SPF, TXT kaydının içine yazılan özel biçimli bir metindir. Yani teknik olarak bir SPF kaydı da bir TXT kaydıdır; sadece değeri v=spf1 ile başlar ve e-posta gönderim politikasını tanımlar. Eskiden ayrı bir SPF kayıt türü tanımlanmıştı ancak yaygın olarak benimsenmedi ve kullanımdan kaldırıldı; bugün SPF her zaman TXT kaydı olarak yayımlanır.

Aynı alan adında kaç tane TXT kaydı olabilir?#

Pratik olarak birden fazla TXT kaydını rahatça bir arada tutabilirsiniz ve bu normaldir. SPF, DKIM, DMARC ve çeşitli doğrulama dizeleri aynı alan adı altında yan yana yaşayabilir çünkü her servis yalnızca kendi tanıdığı öneke sahip kaydı okur. Tek istisna SPF'tir; kök alan adında yalnızca bir tane v=spf1 kaydı bulunmalıdır. Toplam TXT verisi DNS cevabının makul boyutunu aşmadığı sürece sayı konusunda katı bir sınırla karşılaşmazsınız.

TXT kaydı ekledikten sonra neden hemen görünmüyor?#

DNS değişiklikleri, önbellek nedeniyle anında yayılmaz. Kaydın eski TTL süresi boyunca çözümleyiciler önceki cevabı bellekten sunmaya devam edebilir; bu yüzden yeni kayıt bazen birkaç dakika, bazen bir saate kadar süren bir gecikmeyle görünür. Yayılmayı beklemek yerine dig +short TXT alanadiniz.com komutuyla kaydın gerçekten yayına çıkıp çıkmadığını kontrol edebilir, ancak ondan sonra servisin doğrulama adımını tekrar deneyebilirsiniz.

TXT kaydında tırnak işaretlerini kendim yazmalı mıyım?#

Bu tamamen nerede çalıştığınıza bağlıdır. Çoğu kontrol panelinin DNS arayüzünde değeri tırnaksız girersiniz ve panel çift tırnakları arka planda kendisi ekler; siz de tırnak koyarsanız çift tırnaklı bozuk bir kayıt oluşur. Buna karşılık doğrudan bir bölge dosyası düzenliyorsanız ya da komut satırı araçlarıyla kayıt oluşturuyorsanız, metni çift tırnak içine almak gerekir çünkü değerin sınırlarını tırnaklar belirler.

255 karakterden uzun bir TXT değeri nasıl eklenir?#

Tek bir TXT dizesi en fazla 255 karakter olabilir, ancak bu değeri tek bir kayıt içinde birden fazla tırnaklı parçaya bölerek 255 sınırını aşan içerikleri yayımlayabilirsiniz. Alıcı sistem bu parçaları birleştirip tek metin olarak okur. Uzun DKIM açık anahtarlarında bu duruma sık rastlanır. İyi haber şu ki modern kontrol panellerinin çoğu bu bölmeyi otomatik yapar; siz uzun değeri tek satırda yapıştırırsınız, panel arka planda parçalara ayırır.

TXT kaydını yanlış girmek e-postalarımı etkiler mi?#

Evet, özellikle e-posta güvenliğiyle ilgili TXT kayıtlarında hatalı bir düzenleme doğrudan teslimatı etkileyebilir. Bozuk bir SPF kaydı, meşru e-postalarınızın spam'e düşmesine ya da reddedilmesine yol açabilir; hatalı bir DKIM anahtarı imza doğrulamasını başarısız kılar; yanlış bir DMARC politikası ise mesajların karantinaya alınmasına neden olabilir. Bu yüzden e-posta ile ilgili TXT kayıtlarında değişiklik yapmadan önce mevcut değeri yedeklemek ve değişiklik sonrası bir test e-postası göndererek sonucu kontrol etmek önemlidir.

Kapanış#

TXT kaydı, DNS'in en esnek ve en çok yükü taşıyan kayıt türlerinden biridir. Serbest metin tutabilme yeteneği sayesinde SPF, DKIM ve DMARC gibi e-posta güvenliği mekanizmalarının, sayısız alan adı doğrulama akışının ve pek çok servis entegrasyonunun temelini oluşturur. Söz dizimi, tırnak kuralları, 255 karakter sınırı ve aynı alan adında birden çok kaydın bir arada bulunabilmesi gibi birkaç temel noktayı içselleştirdiğinizde, panelde gördüğünüz bu metin dizeleri gizemli olmaktan çıkar ve tam olarak neyi neden yaptığınızı bilirsiniz.

Alan adı ve DNS yönetimini profesyonelce, tek bir panelden yürütmek işleri hem hızlandırır hem de bu tür hataların önüne geçer. Clou.TR ile alan adınızı yönetebilir, hazır DNS altyapısı sunan hosting paketleriyle sitenizi güvenle yayına alabilir ve profesyonel e-posta hizmetini SPF, DKIM ve DMARC kayıtları hazır şekilde devreye alabilirsiniz. Sunucu ve DNS bakımını uzman bir ekibe bırakmak isterseniz sunucu yönetimi hizmetimiz TXT kayıtlarınızdan tüm altyapınıza kadar her ayrıntıyı sizin adınıza güvenle üstlenir.