DKIM Selector Nedir? Birden Fazla Selector Nasıl Yönetilir?

DKIM kurulumunda bir selector tanımladınız. Sonra ikinci bir gönderim servisi eklediniz; bu servis de kendi selector'ını istedi. Üçüncü bir araç entegre edince durum daha da karmaşık hale geldi. Şimdi DNS'inizde birden fazla _domainkey kaydı var ve hangisinin ne işe yaradığını, hangisinin hâlâ aktif olduğunu, hangisini güvenle silebileceğinizi bilmiyorsunuz. Bu belirsizlik yaygın — çünkü selector kavramı genellikle kurulum sırasında "rastgele bir isim girilecek şey" olarak geçiştirilir, arka planındaki mantık açıklanmaz.

Selector, DKIM'in çok anahtar yönetimine imkân tanıyan mekanizmasıdır. Tek bir domain altında farklı göndericiler, farklı dönemler ve farklı amaçlar için ayrı ayrı anahtar çiftleri barındırılabilir; alıcı sunucu hangi anahtarla doğrulama yapacağını e-posta başlığındaki selector değerinden öğrenir. Bu mimarinin nasıl çalıştığını anlamak, DNS'inizdeki kayıtları okuyabilmenin ve yönetebilmenin temelidir.

DKIM kaydının genel kurulumu ayrı bir yazıda anlatılıyor. Burada o temel üzerine inşa ediyoruz: selector'ın ne olduğunu, DNS'te nasıl konumlandığını, birden fazla selector'ın hangi durumlarda gerektiğini ve yönetiminin pratik boyutlarını ele alıyoruz.

Selector nedir ve TXT kaydının tam yolu nasıl oluşur?

DKIM imzalamasında her anahtar çifti bir selector adıyla etiketlenir. Gönderim sunucusu bir mesajı imzalarken bu selector adını mesajın DKIM-Signature başlığına yazar. Alıcı sunucu bu başlığı okur, selector adını ve domain'i birleştirir, DNS'te ilgili TXT kaydını sorgular ve oradan gelen açık anahtarla imzayı doğrular.

TXT kaydının tam DNS yolu şu formülden oluşur: {selector}._domainkey.{domain}. Selector adı google, domain example.com ise sorgu yapılan adres:

google._domainkey.example.com

_domainkey sabit bir alt alan adı; DKIM standardının belirlediği, değiştirilemeyen bir bileşen. Selector ise tamamen size aittir — istediğiniz ismi verebilirsiniz. Servis sağlayıcılar genellikle kendi adlarını veya tarih tabanlı değerleri öneriyor: google, mailchimp, s1, k1, 2024 gibi. Bu isim ne anlama geliyor diye bir kural yok; önemli olan DNS'te tam olarak aynı adla kayıtlı bir TXT kaydının bulunması.

O TXT kaydının içeriği standart bir yapı taşır:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

v=DKIM1 versiyon etiketi, k=rsa anahtar türü (RSA en yaygın, ed25519 de destekleniyor), p= ise base64 kodlanmış açık anahtar. Gönderim sunucusundaki özel anahtar bu açık anahtarın çiftidir; imza özel anahtarla oluşturulur, doğrulama açık anahtarla yapılır. Özel anahtar asla DNS'e konmaz, yalnızca gönderim sunucusunda kalır.

DKIM-Signature başlığındaki s= etiketi selector adını taşır. Alıcı sunucu bu değeri ve d= etiketindeki domain'i birleştirerek tam DNS adresini oluşturur ve sorguyu gönderir. Süreç bu kadar doğrusal — selector adının önemi buradan geliyor: eşleşmezse sorgu yanlış adrese gider ve doğrulama başarısız olur.

Neden birden fazla selector gerekir?

Tek selector çoğu basit yapıda yeterlidir. Ama birkaç farklı senaryo, birden fazla selector kullanmayı kaçınılmaz ya da tercih edilir kılar.

En yaygın neden gönderim servisi bağımsızlığı. Her e-posta gönderim servisi kendi altyapısından imzalama yapar ve bu altyapıdaki özel anahtara yalnızca o servis erişebilir. Google Workspace, mesajları kendi özel anahtarıyla imzalar; Mailchimp, kendi özel anahtarıyla. Bu iki servisin aynı özel anahtarı paylaşması teknik olarak mümkün değildir — dolayısıyla her biri için ayrı bir açık anahtar DNS'e girilmeli ve her açık anahtarın farklı bir selector adıyla etiketlenmesi gerekir. İki servis için iki selector, üç servis için üç selector.

İkinci senaryo anahtar rotasyonu. Güvenlik pratikleri açısından DKIM anahtarlarının belirli aralıklarla yenilenmesi önerilir — yılda bir ya da güvenlik ihlali şüphesi durumunda. Rotasyon sırasında eski anahtarı hemen silmek teslimatta kesintiye yol açabilir: henüz iletilmemiş veya yeniden deneme kuyruğundaki mesajlar hâlâ eski anahtarla imzalı. Bu geçiş döneminde hem eski hem yeni selector DNS'te bulunmalı; yeni selector aktif imzalama için, eski selector geçiş sürecindeki mesajların doğrulanması için.

Üçüncü senaryo farklı gönderim kanallarını birbirinden ayırma isteği. Transactional e-postalar (sipariş bildirimleri, şifre sıfırlama) ve pazarlama e-postaları (kampanyalar, bültenler) ayrı altyapılardan, ayrı IP'lerden gönderilebilir. Her altyapı ayrı bir servis kullanıyorsa ayrı selector kaçınılmaz. Ama aynı servis üzerinden farklı kanallar yönetilse bile bazı ekipler izleme kolaylığı için selector'ları kanallardan biri olarak adlandırır — bu operasyonel tercih, zorunluluk değil.

Selector sayısı artıkça DNS yönetimi karmaşıklaşır ama her selector bağımsız çalışır. Birinin güncellenmesi diğerlerini etkilemez; birinin silinmesi yalnızca o selector'la imzalanmış mesajları etkiler.

Yeni selector oluşturma ve eski selector'ı silmenin doğru sırası

Selector oluştururken sıralama önemlidir. Yanlış sıralama teslimatta kesintiye yol açar.

Yeni bir gönderim servisi eklerken sıra şudur: önce servisin sağladığı açık anahtarı DNS'e ekleyin, ardından servisteki DKIM imzalamayı etkinleştirin. Ters sırayla — önce imzalamayı açıp sonra DNS kaydını eklerseniz — kısa bir pencerede imzalı mesajlar gönderilir ama alıcı sunucu DNS'te kaydı bulamaz, doğrulama başarısız olur. DNS değişiklikleri yayılmadan önce imzalama başlamaın. TTL değerinize bağlı olarak DNS kaydının tüm sunuculara ulaşması birkaç dakika ile birkaç saat arasında değişir; düşük TTL ile çalışıyorsanız bekleme süresi kısalır.

dig TXT yeni-selector._domainkey.example.com +short

Bu sorgudan beklenen değer kaydın tam içeriğidir. Boş ya da hata dönüyorsa kayıt henüz yayılmamış veya yazım hatası var demektir. Kaydı doğrulamadan imzalamayı etkinleştirmeyin.

Anahtar rotasyonunda sıra biraz farklı: yeni selector'ı DNS'e ekle → yayılmasını bekle → gönderim sunucusunu yeni selector'la imzalamaya geçir → eski selector'ı hemen silme. Geçiş döneminde (birkaç gün ile bir hafta arası makul) eski selector DNS'te kalmalı. Kuyruktaki veya yeniden deneme aşamasındaki mesajlar eski anahtarla imzalı gelebilir; eski selector silinmişse bu mesajların doğrulaması başarısız olur.

Bir servisi tamamen devre dışı bırakıyorsanız — o servis üzerinden artık e-posta göndermeyecekseniz — selector'ı silmek güvenlidir. Etkin gönderim olmayan bir selector için DNS kaydı tutmak zararlı değil ama gereksiz. Temiz bir DNS zone'u için kullanılmayan selector'ları kaldırmak iyi pratik.

Selector TXT kaydının doğrulanması

DNS'e eklenen bir selector kaydını doğrulamak için birkaç yöntem var. En doğrudan yol dig veya nslookup ile TXT kaydını sorgulamak.

dig TXT google._domainkey.example.com +short
dig TXT mailchimp._domainkey.example.com +short

Her sorgunun döndürdüğü değer, servisin sağladığı açık anahtar içeriğiyle eşleşmeli. Uzun bir p= değeri görüyorsanız kayıt yerinde. Hiçbir şey dönmüyorsa kayıt ya girilmemiş ya da henüz yayılmamış. Yanlış bir değer dönüyorsa — farklı bir açık anahtar veya hatalı sözdizimi — imzalama çalışmaz.

Bir mesajın gerçekten doğru selector'la imzalanıp imzalanmadığını doğrulamak için gönderilen mesajın başlıklarını incelemek gerekir. Gmail'de "Orijinali göster" seçeneği tam başlık metnini sunar; DKIM-Signature başlığındaki s= değeri hangi selector'ın kullanıldığını gösterir.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=google;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Buradaki s=google değeri, alıcı sunucunun google._domainkey.example.com adresini sorgulayacağı anlamına gelir. d=example.com ise DMARC alignment için kullanılan domain. bh= mesaj gövdesinin hash'i, b= ise imzanın kendisi.

MXToolbox ve mail-tester.com gibi araçlar bir test mesajı göndererek DKIM imzasını otomatik doğrular; hangi selector kullanıldığını, imzanın geçerli olup olmadığını ve alignment durumunu raporlar. Servis entegrasyonu tamamlandıktan sonra bu araçlardan biriyle son kontrol yapmak, teslimatta sorun çıkmadan önce yapılandırmayı onaylamanın en pratik yolu.

Bazı servislerin selector'ı CNAME ile yönetmesi

Büyük e-posta servis sağlayıcılarının bir kısmı DKIM kurulumunu TXT kaydı yerine CNAME kaydıyla yönetir. Bu yaklaşımın teknik bir nedeni var ve onu anlamak, DNS'inizde neden farklı türde bir kayıt gördüğünüzü açıklar.

TXT tabanlı kurulumda açık anahtarı DNS'inize siz girersiniz ve anahtarı servis değiştirdiğinde sizi bilgilendirmesi gerekir — siz de kaydı güncellemelisiniz. Bu süreç gecikirse geçiş döneminde DKIM başarısızlığı yaşanabilir. CNAME tabanlı kurulumda ise siz sadece bir CNAME kaydı eklersiniz; bu CNAME servisin kendi DNS altyapısına işaret eder. Gerçek TXT kaydı ve açık anahtar servisin sunucusunda barındırılır ve servis anahtarı döndürdüğünde güncelleme otomatik gerçekleşir — sizin DNS'inizde herhangi bir değişiklik yapmanız gerekmez.

; DNS'inizdeki kayıt:
s1._domainkey.example.com  CNAME  s1.domainkey.sendgrid.net

; Servisin kendi sunucusundaki TXT kaydı:
s1.domainkey.sendgrid.net  TXT  "v=DKIM1; k=rsa; p=MIGf..."

SendGrid, bu modeli kullanan servislerden biri. Mailchimp de belirli yapılandırmalarda CNAME yönlendirmesiyle çalışır. Google Workspace ise doğrudan TXT kaydı kullanır ve açık anahtarı siz girersiniz.

CNAME yaklaşımının dezavantajı DNS sorgu zinciri: alıcı sunucu önce CNAME'i çözer, ardından hedef adresi sorgular. Bu ek bir DNS hop demektir. Pratikte performans farkı ihmal edilebilir düzeyde, ama bazı katı DNS yapılandırmalarında CNAME zinciri sorun çıkarabilir. Bunun dışında kullanıcı açısından en büyük avantajı bakım yüküdür: anahtar rotasyonu otomatik, sizin müdahalenize gerek yok.

CNAME kaydının genel davranışı ve hangi bağlamlarda kullanılabileceği ayrıca incelemeye değer; DKIM için CNAME yönlendirmesi bu davranışın e-posta doğrulama alanına özgü bir uygulaması.

DNS'inizde _domainkey altında birden fazla kayıt görüyorsanız — kimi TXT, kimi CNAME — bu tutarsızlık değil, farklı servislerin farklı entegrasyon modellerini tercih etmesinin sonucu. Her selector bağımsız çalışır; TXT ve CNAME tabanlı selector'lar aynı domain altında aynı anda var olabilir, birbirini etkilemez.

Selector yönetiminin özü envanteri güncel tutmaktan geçiyor. Hangi selector hangi servise ait, hangisi aktif imzalama yapıyor, hangisi artık kullanılmıyor — bu soruların cevabı yazılı değilse DNS'teki kayıtlara bakarak çıkarmak gerekiyor. Yeni bir servis eklendiğinde yeni bir selector eklenir; bir servis devre dışı bırakıldığında o selector kaldırılır. Bu sadelik korunduğu sürece birden fazla selector yönetmek karmaşık değil — sadece dikkat isteyen, küçük ama önemli bir operasyonel detay.