DNS Kayıtları Hızlı Rehber: A, AAAA, MX, TXT, CNAME

Domain DNS (Domain Name System) kayıtları, alan adınızı internet üzerindeki doğru sunucu ve servislerle eşleştiren kurallardır. Doğru DNS kaydı kombinasyonu; web sitenizin, e-postanızın ve doğrulama süreçlerinizin sorunsuz çalışmasını sağlar. Bu rehberde A, AAAA, MX, TXT ve CNAME kayıtlarını net örneklerle anlatıyor; “neden çalışmıyor?” sorusuna yol açan tipik hataları ve hızlı kontrol adımlarını paylaşıyoruz.

Aşağıdaki akış, yeni bir domain açtığınızda ya da DNS taşıma sonrası (nameserver değiştirme) aksaklık yaşadığınızda karar vermenizi kolaylaştırır.

DNS kayıtları: Genel mantık (priorite etmeden önce)

DNS kayıtları tek tek belirli bir işlemi üstlenir:

A kaydı (IPv4): Domaini bir IPv4 adresine (ör: 192.0.2.10) bağlar.
AAAA kaydı (IPv6): Domaini bir IPv6 adresine (ör: 2001:db8::10) bağlar.
MX kaydı (Mail Exchanger): Domain adına e-posta kabul edecek mail sunucusunu belirtir.
TXT kaydı: Metin tabanlı doğrulama ve politika bilgilerini taşır (SPF, DKIM, DMARC, doğrulama token’ları vb.).
CNAME kaydı (Canonical Name): Bir domaini başka bir domainin adına yönlendirir (alias mantığı).

Hızlı kural seti

Aynı domain adı için A ve AAAA birlikte tanımlanabilir; web erişimi hem IPv4 hem IPv6 ile sağlanır.
MX kayıtlarında “öncelik” (priority) sayısı vardır; birden fazla MX tanımlıysa daha düşük priority numarası daha önce denenir.
TXT kayıtları birden fazla satır/entry olarak çoğalabilir. Silerken dikkat edin.
CNAME genelde kök (zone apex) için önerilmez; servis sağlayıcınız kök domain için farklı yönlendirme istiyorsa (ör: ALIAS/ANAME), bunu sağlayıcının panel mantığına göre uygulayın.

A ve AAAA kayıtları: Web, CDN ve yönlendirme mantığı

Web trafiği çoğu senaryoda ya doğrudan IP’ye gider ya da CDN/proxy katmanından geçer.

A kaydı (IPv4) örneği

Senaryo: “example.com web sitem barındırdığım sunucunun IPv4 adresine gitsin.”

Host/Alias: @ (veya panelde “root”)
Record type: A
Value/Address: 203.0.113.10
TTL: 300-3600 (çoğu panelde varsayılan iyi çalışır)

Sık yapılan hata: Yanlış host. Örneğin www yerine @ düzenlenirse kök domain etkilenir, www ayrı kalır.

AAAA kaydı (IPv6) örneği

Senaryo: “İnternetin IPv6 kullanan kısmı için de erişim olsun.”

Host/Alias: @
Record type: AAAA
Value/Address: 2001:db8::10

IPv6 kullanmıyorsanız AAAA kaydı eklememeniz normaldir. Ancak SSL kurulumu ve modern tarayıcılar açısından IPv6 varlığı erişimi iyileştirebilir.

CNAME ile birlikte kullanım (www örneği)

Birçok kurulumda root domain (example.com) A/AAAA ile, www ise CNAME ile ilerler.

Host: www
Record type: CNAME
Value: example.com

Bu tasarım, www.example.com ve example.com arasında tutarlılık sağlar. Tersini yapmak (root için CNAME) her sağlayıcıda sorunsuz çalışmayabilir; panelinizin izin verdiği yapıya uyun.

MX kayıtları: E-postanın nereye gideceği

E-posta akışında MX kayıtları belirleyicidir. Doğru MX olmadan e-postalar ya teslim olmaz ya da “mail exchangers bulunamadı” benzeri hatalar görürsünüz.

Tek MX mi, çoklu MX mi?

Tek MX: Basit kurulumlarda yeterlidir.
Çoklu MX: Yedeklilik sağlar. Daha düşük priority daha önce denenir.

MX örneği

Senaryo: “example.com maili mail sağlayıcısının sunucusuna gitsin.”

Hostname	Record type	Priority	Mail server (Value)
`@`	MX	10	`mx1.provider.com`
`@`	MX	20	`mx2.provider.com`

Buradaki kritik nokta: Provider genelde “mx1/mx2” gibi isimlerle birlikte tam olarak hangi alan adının MX olarak yazılacağını verir. IP adresi değil, mail sunucusunun domaini yazılır.

MX ile yaşanan tipik sorunlar

MX kaydını doğru domain yerine yanlış alt domaine girmek (ör: mail host’una yazmak).
Priority değerlerini rastgele değiştirmek (daha yüksek priority yedek çalıştırır; ana akış gecikebilir).
MX sonrası SPF/DKIM/DMARC TXT kayıtlarının unutulması: Teslim olur gibi görünse bile spam klasörüne düşme oranı artar.

TXT kayıtları: SPF, DKIM, DMARC ve doğrulama

TXT kayıtları, DNS’in “metin taşıyan” bölümüdür. E-posta güvenilirliği (SPF/DKIM/DMARC) ve birçok servis doğrulaması (domain verification) burada yapılır.

SPF (Sender Policy Framework) TXT örneği

SPF, gönderenden hangi sunucuların yetkili olduğunu bildirir. Provider çoğu zaman size hazır bir SPF string’i verir.

Örnek (format örneğidir): - Host: @ - Record type: TXT - Value: v=spf1 include:provider.com -all

Sık hata: Provider’ın verdiği SPF string’ini “kendi cümlelerinizle” bölmek veya eklemek. SPF tek başına değil, bütünleşik değerlendirilir; yanlış ekleme doğrulamayı bozar.

DKIM TXT (public key) mantığı

DKIM’de çoğu panelde selector._domainkey gibi bir host yapısı görülür.

Host: selector1._domainkey
Record type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

Sık hata: p= kısmını kırpmak ya da sondaki =/karakterleri eksik girmek.

DMARC TXT örneği

DMARC; SPF ve DKIM sonuçlarını nasıl ele alacağınızı bildirir.

Host: _dmarc
Record type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s

Sık hata: rua= ve ruf= adreslerini yanlış yazmak. Bu durumda raporlar gelmez; politika uygulaması yine çalışabilir ama doğrulama izleme zorlaşır.

Domain doğrulama TXT’leri (ACME/SSL sağlayıcıları, CMS, e-posta sağlayıcıları)

Cloudflare, Google Workspace, Microsoft 365, bazı SSL doğrulama süreçleri veya web servisleri alan adı sahipliğini TXT ile doğrular.

Kural: Provider’ın verdiği değeri birebir girin; boşluk, tırnak, satır kırılımı değişikliği yapmayın. Paneliniz uzun metinleri bölebilir; genelde sorun olmaz ancak hatalı kırpma sorun yaratır.

CNAME kayıtları: Alias (www ve servisler)

CNAME, bir domain adını başka bir domain adına bağlar. Örneğin www.example.com, example.com veya server.provider.com adına yönlenebilir.

CNAME örnekleri

1) www → root domain - Host: www - Record type: CNAME - Value: example.com

2) Subdomain → servis sağlayıcı adı Senaryo: api.example.com belirli bir platforma yönlensin. - Host: api - Record type: CNAME - Value: api.platformprovider.com

CNAME ile ilgili kritik nokta

CNAME bir kez bir host için tanımlandıysa, aynı host adı altında genellikle A/AAAA veya MX gibi başka kayıtlar bulunmamalıdır. Paneliniz bu kuralı uygulayabilir ya da çakışma yüzünden “garip” sonuçlar doğurabilir.

DNS değişiklikleri neden hemen görünmez? (TTL + propagation)

DNS güncellemeleri anında her yerde görünmez. Bunun ana sebepleri: - TTL (Time To Live): DNS resolver’ların cache’de tutma süresi. - Farklı sağlayıcıların cache davranışları. - Nameserver değiştirildiğinde bekleme süresi.

Pratik yaklaşım

Büyük değişiklikten önce TTL’yi düşürmek: Mümkünse değişiklikten 24-48 saat önce TTL’yi 300-600 bandına çekin.
Değişiklik sonrası sadece “panel güncellendi mi”ye bakmayın. Resolver’larda farklı sonuçlar görebilirsiniz.

Hızlı kontrol: Hangi kayıtları nasıl test edersiniz?

Bir DNS problemi yaşadığınızda test akışı şu şekilde olmalı:

1) A/AAAA kontrolü (web erişimi)

Browser’da example.com ve www.example.com ayrı ayrı deneme
Ping her zaman yeterli değildir; bazı servisler ICMP’i kapatır.

2) MX kontrolü (mail teslimi)

Mail sağlayıcınız genelde “DNS check” ekranı sunar.
MX’ler doğru görünüyorsa bile SPF/DKIM/DMARC yanlışsa teslim “tam” olmayabilir.

3) TXT kontrolü (e-posta ve doğrulama)

SPF/DKIM/DMARC değerleri birebir doğrulanmalı.
Çok satır/çok entry varsa silme-kopyalama hatalarına dikkat edin.

4) CNAME zinciri kontrolü

www üzerinden bir servis adına yönlendiriyorsanız zincir uzadıkça hata ayıklamak zorlaşır.

En sık DNS hataları ve çözüm şablonları

Aşağıdaki durumlar genellikle DNS tabanlı arızaların büyük kısmını oluşturur.

Hata 1: “Web çalışmıyor” ama A/AAAA görünmüyor

Çözüm: - Root (@) ve www kayıtlarını ayrı ayrı doğrulayın. - CDN kullanıyorsanız provider’ın istediği “origin” mi “edge” mi yönlendirme yaptığını kontrol edin.

Hata 2: “E-posta gelmiyor”

Çözüm: - MX kayıtları doğru mu? (host @ mi, priority doğru mu?) - SPF/DKIM/DMARC TXT’leri e-posta sağlayıcısının verdiği şekilde mi?

Hata 3: “Spam’a düşüyor”

Çözüm: - SPF alignment ve DKIM imzasının çalıştığından emin olun. - DMARC politikasını (p=none/quarantine/reject) doğru kademede tutun.

Hata 4: TXT değerleri ekleniyor ama doğrulama yine başarısız

Çözüm: - Provider’ın verdiği TXT değerini birebir girin. - Panelinizde yanlışlıkla tırnak, fazladan boşluk veya eksik karakter oluşmuş mu kontrol edin.

Kurulum senaryolarına göre örnek DNS seti

Aşağıda en yaygın üç kullanım için “mantık” seviyesinde örnek setler var. Değerler provider’a göre değişir; doğru değerleri sağlayıcınızdan alın.

Senaryo A: Sadece web (tek sunucu)

@ → A: web sunucu IPv4
www → CNAME: @ (veya example.com)
(Opsiyonel) @ → AAAA: IPv6

Senaryo B: Web + e-posta (ayrı mail sağlayıcı)

@ → A: web IPv4
www → CNAME: @
@ → MX: provider mx1/mx2
@ → TXT: SPF
selector._domainkey → TXT: DKIM
_dmarc → TXT: DMARC

Senaryo C: Web CDN arkasında + mail dışarıda

CDN’in istediği şekilde root ve www yönlendirmeleri (çoğu zaman CNAME ile)
MX ve TXT kayıtları mail sağlayıcı ile birebir uyumlu

Sonuç: Değişikliği “kayıt türüne göre” planlayın

Domain DNS kayıtlarında ilerlerken en iyi yaklaşım; problemi tek bir kayda bağlamadan önce A/AAAA (erişim), MX (mail akışı) ve TXT (doğrulama) ayrımını netleştirmektir. İlk adım olarak panelinizde root (@) ile www/mail/_dmarc gibi host isimlerini aynı ekran üzerinde karşılaştırın; sonra sağlayıcınızın verdiği TXT değerlerini birebir doğrulayın. DNS değişikliği yapacağınız gün TTL’yi düşürüp, 1-2 saat boyunca propagation farklarını hesaba katarak test edin. Bu düzenli kontrol akışıyla “güncelledim ama neden çalışmıyor?” süresi ciddi şekilde kısalır.