Domain sağlığı rehberi
DKIM seçici (selector) nedir?
DKIM seçici (selector), bir gönderen sistem için tek bir DKIM anahtar kaydını tanımlar. Domainin, her kaydı aynı anda değiştirmeden imzalama anahtarını yenilemesini ya da birden fazla anahtar kullanmasını sağlar.
Seçici DKIM içinde nereye oturur?
DKIM, herkese açık bir DNS kaydını bulmak için domainle birlikte bir seçici (selector) kullanır. Bir sağlayıcı google ya da selector1 gibi bir seçici kullanabilir. Bu da selector1._domainkey.example.com gibi bir sorgu adı üretir.
Seçiciyi gönderen ya da e-posta sağlayıcısı belirler. Domain adından tahmin edilecek bir değer değildir ve farklı sağlayıcılar aynı domain için farklı seçiciler kullanabilir.
Bilinen bir seçici nerede bulunur?
E-posta sağlayıcısının kurulum belgelerini ya da sağlayıcı kurulumu sırasında oluşturulan DNS yapılandırmasını kullanın. İncelemeye yetkili olduğunuz e-postalarda, gönderilmiş bir iletinin DKIM-Signature ya da Authentication-Results başlıkları da seçiciyi gösterebilir.
E-posta iletilerini ya da özel başlıkları herkese açık bir denetleyiciye yüklemeyin. CloudSpex aracı bir domain ve tek bir seçici alır, ardından ilgili herkese açık DNS kaydını okur.
Seçicileri birer birer doğrulayın
Seçiciye özgü bir kontrol, herkese açık kaydın erişilebilir ve güvenle yorumlanabilir olup olmadığını doğrulayabilir. Domainden gelen her iletinin doğru imzalandığını ya da her e-posta sağlayıcısının amaçlandığı gibi yapılandırıldığını kanıtlayamaz.
Her gönderen sistemin kullandığı seçiciyi, özellikle bir e-posta sağlayıcısı geçişinden, DNS değişikliğinden ya da anahtar yenilemesinden sonra kontrol edin.
- Kontrol ettiğiniz göndereni ya da sağlayıcıyı belirleyin.
- Belgelenmiş seçicisini bulun.
- Bu tek seçiciyi gönderen domaine karşı kontrol edin.
- Kayıt eksik, geçersiz ya da iptal edilmiş ise sağlayıcı kurulumunu gözden geçirin.
- Bir DNS değişikliğinden ya da anahtar yenilemesinden sonra yeniden kontrol edin.
Seçiciyi tahmin etmeye çalışmayın
Bir domainde yaygın seçicileri denemek güvenilir bir yapılandırma incelemesi değildir. Asıl anahtarı kaçırabilir ve gereksiz sorgu denemeleri yaratır.
CloudSpex her istekte tek bir seçiciyi doğrular. Otomatik seçici keşfi ya da kaba kuvvetle sorgulama yapmaz.
Seçici nerede görünür?
DKIM ile imzalanmış her ileti bir DKIM-Signature başlığı taşır. Bu başlıktaki iki etiket, alıcı sunucuya açık anahtarı nerede bulacağını söyler: d imzalayan domain, s ise seçicidir. Alıcı sunucu bunları bir DNS adında birleştirir: önce seçici, sonra _domainkey, sonra domain. Ardından orada bir TXT kaydı arar.
Anahtarın bulunmasında başka hiçbir şey rol oynamaz. Kayıt tam olarak bu adda yoksa, domain başka kaç DKIM kaydı yayınlarsa yayınlasın doğrulama başarısız olur.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=s1; h=from:to:subject:date;
bh=...; b=...
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."Yaygın sağlayıcıların kullandığı seçiciler
Seçicileri anahtarı üreten taraf belirler, bu yüzden değişkenlik gösterir. Birkaç sağlayıcı sabit ve belgelenmiş adlar kullanır. Bu, bir domaini e-postasına erişmeden kontrol etmeniz gerektiğinde işe yarar. Google Workspace, yönetici başka bir önek seçmediyse google kullanır. Microsoft 365, selector1 ve selector2 kullanır. Bunlar, Microsoft'un anahtarları yenileyebilmesi için Microsoft'un kendi domainini gösteren CNAME kayıtları olarak yayınlanır.
Diğer birçok servis, müşteri başına ya da anahtar başına bir seçici üretir. Bu çoğunlukla kısa bir kod ya da bir tarihtir. Bunlar için tek güvenilir kaynak, servisin DNS kurulum sayfası ve gerçek bir iletinin başlığıdır.
selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com. CNAME selector2-example-com._domainkey.example.onmicrosoft.com.TXT mi, CNAME mi?
Bir DKIM anahtarı doğrudan TXT kaydı olarak ya da dolaylı biçimde, sağlayıcının tuttuğu bir TXT kaydını gösteren CNAME olarak yayınlanabilir. İkisi de çalışır. Fark, anahtarı kimin değiştirebildiğidir.
TXT kaydında anahtarı siz yönetirsiniz: yenilemek, yeni bir anahtar çifti üretmek ve DNS'i düzenlemek demektir. CNAME ile sağlayıcı, sizden DNS'e yeniden dokunmanızı istemeden adın arkasındaki anahtarı değiştirebilir. Bu kullanışlıdır, ama aynı zamanda kaydın yalnızca sağlayıcı kendi tarafını yerinde tuttuğu sürece çözülmeye devam ettiği anlamına gelir. Bir servis iptal edildiğinde CNAME hiçbir şeyi göstermez hâlde kalır ve kaldırılmalıdır.
Tek bir domainde neden birden fazla seçici olur?
Bir domain adına e-posta imzalayan her sistemin kendi anahtarına, her anahtarın da kendi seçicisine ihtiyacı vardır. Tipik bir kurumsal domainde sonunda e-posta sağlayıcısı için bir, pazarlama platformu için bir, yardım masası için bir ve web sitesinden gelen işlemsel e-postalar için bir seçici bulunur. Bu normaldir ve istenen durumdur.
Ayrı seçiciler servisleri birbirinden bağımsız tutar. Bir servisin anahtarı, diğerlerini etkilemeden yenilenebilir ya da iptal edilebilir. Bir DMARC raporunda görünen seçici de iletiyi hangi sistemin gönderdiğini söyler.
E-posta kaybetmeden anahtar yenileme
Seçiciler, anahtar yenilemeyi güvenli kılmak için vardır. Seçici sorgu adının bir parçası olduğundan, eski ve yeni anahtar farklı seçiciler altında aynı anda yayınlanabilir.
- Gönderen sistemde yeni bir anahtar çifti üretin ve bunun için yeni bir seçici belirleyin.
- Yeni açık anahtarı DNS'te yeni seçici altında yayınlayın. Eski kaydı yerinde bırakın.
- Yeni kayıt herkese açık DNS'ten görünür olana kadar bekleyin, sonra gönderen sistemi yeni anahtarla imzalayacak şekilde değiştirin.
- Eski kaydı en az bir hafta yayında tutun. Eski anahtarla imzalanmış iletiler hâlâ yolda olabilir ya da iletildiklerinde yeniden doğrulanabilir.
- Eski kaydı kaldırın ya da anahtarını boş bir p= değeriyle değiştirin. Bu, anahtarı açıkça iptal edilmiş olarak işaretler.
s1._domainkey.example.com. TXT "v=DKIM1; p="Anahtar boyutu ve uzun kayıtlar
Bir DKIM kaydının uzunluğu anahtara bağlıdır. 1024 bitlik bir RSA anahtarı tek bir DNS dizgisine sığar. Güncel öneri olan 2048 bitlik anahtar ise sığmaz: kaydı 255 karakteri aşar ve tek bir TXT kaydı içinde tırnak içine alınmış iki ya da daha fazla dizgi olarak yayınlanmalıdır. Alıcı sunucular anahtarı okumadan önce dizgileri birleştirir.
Doğru bir anahtarın doğrulamadan geçememesinin en yaygın nedeni budur. Değeri sessizce kesen bir DNS paneli ya da anahtarın ortasına satır sonu veya boşluk karışmış bir kopya, makul görünen ama doğrulanmayan bir kayıt üretir. Yayınladıktan sonra, herkese açık DNS'in döndürdüğü anahtarı sağlayıcının size verdiğiyle karşılaştırın ya da anahtarı ayrıştıran bir denetleyici kullanın.
Ed25519 anahtarları çok daha kısadır ve DKIM tarafından desteklenir, ancak henüz her alıcı sunucu bunları doğrulamaz. Bir sistem ikisini de sunuyorsa, ikinci bir seçici altında RSA ile de imzalayın.
Kontrol sonucunu okuma
Bir seçici kontrolü dar bir soruyu yanıtlar: bu adda kullanılabilir bir açık anahtar var mı? Dört sonuç mümkündür. Kayıt vardır ve geçerli bir anahtar içerir. Kayıt vardır ama anahtar boştur, yani iptal edilmiştir. Kayıt vardır ama ayrıştırılamaz, çoğunlukla kesilme ya da araya karışan karakterler yüzünden. Ya da o adda hiçbir şey yayınlanmamıştır. Bu, ya seçicinin yanlış olduğu ya da kaydın hiç oluşturulmadığı anlamına gelir.
Bunların hiçbiri e-postanın gerçekten imzalanıp imzalanmadığını söylemez. Gönderen sistem imzalayacak şekilde yapılandırılmamışsa ya da farklı bir seçiciyle imzalıyorsa kusursuz bir kayıt hiçbir işe yaramaz. Bu kısım yalnızca alınan bir iletide görülebilir. Orada Authentication-Results başlığı, kullanılan domain ve seçiciyle birlikte dkim=pass sonucunu gösterir.
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=s1Seçiciler ve DMARC hizalaması
Seçicinin kendisi DMARC'ta rol oynamaz, ama yanındaki domain oynar. DMARC, bir DKIM geçişini yalnızca d etiketindeki imzalayan domain görünen From adresindeki domainle eşleştiğinde kabul eder. Kendi domainiyle imzalayan bir servis DKIM'den geçer ve DMARC'a hiçbir katkı sağlamaz.
Bir sağlayıcı sizden kendi domaininiz altında seçici kayıtları yayınlamanızı istiyorsa hizalı imzalamayı kuruyordur: d etiketi sizin domaininizi taşıyacaktır. Bir servis hiç DNS kaydı istemediyse neredeyse kesinlikle kendi domainiyle imzalıyordur ve e-postası yalnızca SPF hizalamasına bağlıdır.
Sık yapılan hatalar
DKIM sorunlarının çoğu kısa bir hata listesinden kaynaklanır ve her birinin tanınabilir bir belirtisi vardır.
- Kaydı yanlış adda yayınlamak. Örneğin DNS paneli domaini otomatik eklediği için domainin iki kez eklenmiş olması.
- Anahtarı içinde satır sonları ya da boşluklarla yapıştırmak. Bu durumda anahtar artık çözülemez.
- Kaydı yayınladıktan sonra sağlayıcıdaki imzalama seçeneğini kapalı bırakmak. Kayıt tek başına imzalamayı başlatmaz.
- Yeni seçiciye geçtiğiniz anda eski seçiciyi kaldırmak.
- İptal edilmiş servislerin seçicilerini DNS'te bırakmak. Özellikle de artık başka birinin kaydedebileceği adları gösteren CNAME kayıtlarını.
Sık sorulan sorular
DKIM seçici gizli midir?
Hayır. Seçici ve açık anahtar kaydı DNS'te yayınlanır, ancak özel imzalama anahtarları gizli kalmalıdır.
Bir domain birden fazla seçici kullanabilir mi?
Evet. Birden fazla gönderen ya da anahtar yenileme aşamaları farklı seçiciler kullanabilir.
DKIM kaydının bulunması e-postanın teslim edildiğini kanıtlar mı?
Hayır. Yalnızca ilgili herkese açık kaydın değerlendirilebildiğini doğrular. E-posta akışı ayrıca imzalamaya ve alıcı sunucu tarafındaki değerlendirmeye bağlıdır.
Aldığım bir iletinin seçicisini nasıl bulurum?
İleti kaynağını açın ve DKIM-Signature başlığını bulun. s= etiketi seçici, d= etiketi imzalayan domaindir.
Her domainde default adlı bir seçici var mıdır?
Hayır. Standart bir seçici adı yoktur. Bazı sistemler default adını kullanır, ancak çoğu sağlayıcıya özgü ya da üretilmiş bir ad kullanır.
DKIM anahtarları ne sıklıkla yenilenmeli?
Sabit bir kural yoktur. Yılda bir ya da iki kez yenilemek yaygın bir uygulamadır. Özel anahtara erişimi olan biri ayrıldığında ya da anahtarı barındıran bir sistemin güvenliği ihlal edildiğinde anahtar her zaman yenilenmelidir.
Herkese açık kontrolleri başlangıç noktası olarak kullanın
CloudSpex yalnızca dışarıdan görülebilen sınırlı sinyalleri okur. DNS, web sitesi, sertifika ya da e-posta ayarlarınızı değiştirmez. Bir düzeltmeyi uygulamadan önce sorumlu sağlayıcıyı doğrulayın ve değişikliği test edin.
Yayın bilgisi
Yazan ve gözden geçiren: CloudSpex. Kaynaklar: konuyla ilgili herkese açık teknik standartlar ve sağlayıcı belgeleri. Son gözden geçirme: 10 Kasım 2026. Ürünün davranışı ya da dayanılan kurallar değiştiğinde rehberleri güncelliyoruz.