DKIM Kaydı Kurulumu: Selector, TXT Kaydı ve Kontrol

DKIM, bir e-postanın gerçekten beklenen alan adı adına imzalanıp imzalanmadığını doğrulamaya yardımcı olur. SPF hangi sunucuların gönderim yapabileceğini söylerken, DKIM iletinin başlık ve gövde bütünlüğüne kriptografik imza katmanı ekler. Bu sayede mesaj yolda değiştirilmiş mi ve görünen alan adına ait imza gerçekten mevcut mu soruları daha güvenilir biçimde cevaplanır.

Uygulamada en büyük karışıklık şurada ortaya çıkar: herkes DKIM'i tek tip DNS kaydı sanır. Oysa bazı sistemlerde DKIM doğrudan TXT kaydı ile kurulur, bazı yapılarda ise CNAME selector mantığı kullanılır. Bu fark anlaşılmadığında kullanıcılar doğru veriyi yanlış kayıt türüne ekler, imzalama hiç başlamaz veya kontrol sırasında neden başarısız olunduğu anlaşılamaz. SPF ile birlikte düşünmek için SPF kaydı oluşturma yazısı da bu konuyu tamamlar.

DKIM İmzası Ne Yapar?

DKIM, DomainKeys Identified Mail ifadesinin kısaltmasıdır. Temel mantık şu şekildedir: gönderici sistem, giden mesaja özel anahtarla bir imza ekler. Alıcı sistem ise DNS üzerinden yayınlanan açık anahtarı bulur ve imzayı doğrular. İmza doğrulanıyorsa, iletinin belirli kısımlarının gönderimden sonra değiştirilmediği anlaşılır.

RFC 6376, DKIM anahtarlarının DNS tarafında _domainkey alt alanı altında tutulduğunu ve selector yapısının burada devreye girdiğini açıkça tanımlar. Bu yüzden DKIM tarafında karşılaşılan selector1._domainkey veya google._domainkey gibi kayıtlar rastgele değildir; imza anahtarının nerede aranacağını tanımlar.

Selector Mantığı Neden Vardır?

Selector, DKIM anahtarının hangi kayıt adı altında bulunduğunu belirler. Aynı domain için zaman içinde anahtar değiştirmeniz, eski ve yeni imzaları kısa süre birlikte yönetmeniz veya farklı sistemleri ayırmanız gerekebilir. Selector, bu ayrımı düzenli biçimde yapmaya yarar.

Örneğin bir mesaj başlığında s=selector1 görülüyorsa, doğrulayan sistem ilgili public key'i selector1._domainkey.ornekdomain.com altında arar. Başka bir selector kullanıldığında sorgu adı da değişir. Bu yüzden selector adı ile DNS kaydı birbiriyle birebir uyumlu olmalıdır.

selector1._domainkey.example.com
google._domainkey.example.com
default._domainkey.example.com

Farklı servislerin farklı selector adları kullanması normaldir. Kritik olan, mail başlığındaki s= değeri ile DNS tarafında yayınlanan anahtarın aynı selector altında bulunmasıdır.

TXT ile DKIM Kurulumu ve CNAME ile DKIM Kurulumu Aynı Değildir

Google Workspace gibi bazı yapılarda DKIM için doğrudan TXT kaydı oluşturulur. Google yardım dokümanı, yönetim panelinden üretilen kaydın host alanına örneğin google._domainkey gibi bir ad yazılarak TXT olarak eklenmesini ister ve değerin v=DKIM1 ile başlayan anahtar metni olduğunu açıkça belirtir.

Microsoft 365 özel alan adlarında ise yaklaşım farklı olabilir. Microsoft Learn, custom domain DKIM kurulumu sırasında iki CNAME selector kaydı üretildiğini ve bu kayıtların Microsoft'un yönettiği public key değerlerine işaret ettiğini açıkça gösterir. Yani burada doğrudan TXT anahtarı girmek yerine selector1 ve selector2 için verilen CNAME değerleri eklenir.

Bu yüzden “DKIM her zaman TXT kaydıdır” demek eksik ve bazı senaryolarda yanlıştır. Daha doğru ifade şudur: DKIM doğrulama mantığı DNS üzerinden çalışır; ancak kullanılan kayıt biçimi servis sağlayıcısına göre değişebilir.

Google Workspace Tarafında DKIM Kurulumu

Google Workspace tarafında genel akış nettir: önce yönetim panelinden DKIM anahtarı üretilir, ardından DNS sağlayıcısında ilgili host altında TXT kaydı oluşturulur, son olarak Google panelinden imzalama etkinleştirilir. Google, Gmail organizasyon için yeni açıldıysa DKIM anahtarını üretmeden önce 24 ila 72 saat beklenmesi gerekebileceğini özellikle not eder.

Google'ın yardım sayfasında TXT host alanı için örnek olarak google._domainkey verilir ve değerin v=DKIM1 ile başlayan uzun public key metni olduğu belirtilir. Burada kopyalama hatası, satır kırılması veya eksik karakter, imzalamanın başlamamasına neden olabilir.

TXT tabanlı bu yaklaşım, anahtarın doğrudan sizin DNS bölgenizde tutulduğu modeldir. TXT tabanlı kayıtların genel mantığını daha geniş okumak için TXT kaydı kullanımı rehberi bu noktada faydalı olur.

Microsoft 365 Tarafında DKIM Kurulumu

Microsoft 365 custom domain yapısında DKIM çoğu zaman iki selector üzerinden CNAME kayıtlarıyla kurulur. Microsoft Learn, selector1._domainkey ve selector2._domainkey için ayrı hedefler üretildiğini ve bunların Microsoft altyapısındaki public key'lere yönlendiğini açıkça gösterir.

Buradaki önemli ayrıntı, iki selector bulunmasına rağmen aynı anda yalnızca bir selector'ün aktif kullanılabilmesidir. Microsoft ayrıca diğer selector'ün sonraki anahtar rotasyonları için hazır beklediğini belirtir. Bu yapı, anahtar yenileme sırasında kesintisiz geçişe yardımcı olur.

Yani Microsoft tarafında iki selector kaydı görmek hata değil, tasarımın parçasıdır. Kayıtlar eklendikten sonra imzalama panelde ayrıca etkinleştirilir ve sistemin yeni CNAME kayıtlarını algılaması birkaç dakika veya daha uzun sürebilir.

DKIM Kurulumu Sonrası Nasıl Kontrol Edilir?

Kurulumun ilk kontrolü DNS tarafında yapılır. Selector adı doğru mu, TXT ya da CNAME değeri eksiksiz mi, hedef yanlışlıkla kesilmiş mi, önce bunlar doğrulanmalıdır. DNS doğru görünmüyorsa uygulama katmanında daha ileri kontroller zaman kaybettirir.

İkinci kontrol, gönderilen bir test iletisinin başlıklarında DKIM-Signature alanının bulunup bulunmadığıdır. Burada özellikle d= ile imzalayan domain ve s= ile selector değeri okunur. Bu iki alan, DNS'te beklenen yapı ile uyumluysa kurulumun doğru yöne gittiği anlaşılır.

Üçüncü kontrol ise alıcı tarafın verdiği doğrulama sonucudur. SPF ile birlikte geçtiğinde teslimat davranışı daha öngörülebilir hale gelir. Bu nedenle DKIM'i tek başına değil, SPF ve bir sonraki aşamada DMARC ile birlikte değerlendirmek gerekir.

Yaygın DKIM Hataları

En yaygın hata, yanlış selector adı kullanmaktır. Panelin verdiği selector ile DNS'te açılan kayıt adının harf, tire veya alt çizgi farkı taşıması bile doğrulamayı bozar. Microsoft da kendi dokümantasyonunda tire, nokta ve alt çizgi hatalarının çok kolay yapıldığını özellikle vurgular.

İkinci hata, uzun TXT anahtarını eksik kopyalamaktır. Bazı sağlayıcılarda karakter sınırları nedeniyle uzun değerler parçalı gösterilebilir. Google bu tür durumlarda TXT uzunluk sınırlarına dikkat edilmesi gerektiğini açıkça belirtir. Eksik bir public key, DKIM'in görünürde kurulmuş ama fiilen çalışmayan hale gelmesine neden olur.

Üçüncü hata, aynı selector adı altında birden fazla TXT bırakmaktır. RFC 6376, belirli selector adı için birden fazla TXT kaydı bulunduğunda sonucun belirsiz olacağını açıkça söyler. Yani selector tarafında mükerrer kayıt bırakmak güvenli değildir.

DKIM Anahtar Rotasyonu Neden Önemlidir?

DKIM kurulumu yalnızca bir kez yapılıp unutulacak konu değildir. Özellikle kurumsal yapılarda anahtar yenileme planı düşünülmelidir. Microsoft 365 tarafında selector ikililerinin bulunması da zaten bu rotasyon mantığına hizmet eder. Microsoft Learn, 2048 bit anahtara geçiş ve rotasyon komutlarını açıkça gösterir.

Rotasyon, eski anahtarın sonsuza kadar kullanılmaması ve güvenlik seviyesinin korunması açısından önemlidir. Her ekibin manuel rotasyon yapması gerekmez; ancak kullanılan sistemin selector ve anahtar yaşam döngüsünü nasıl yönettiği bilinmelidir.

Pratik Kurulum Sırası

Bu sıra, DKIM kurulumunu yalnızca bir DNS girdisi eklemekten çıkarır ve gerçek doğrulama sürecine dönüştürür. Özellikle birden fazla posta sağlayıcısı kullanılan yapılarda, hangi domainin hangi selector ile imzaladığını belgelemek yönetimi ciddi biçimde kolaylaştırır.

DKIM kurulumunda belirleyici nokta, kullandığınız sağlayıcının sizden TXT mi yoksa CNAME selector yapısı mı beklediğini doğru anlamaktır. Selector adı, kayıt tipi ve imzalama etkinleştirme adımı birbiriyle uyumlu olduğunda doğrulama sorunsuz çalışır. Böylece e-posta güvenliği zincirinin en kritik halkalarından biri sağlam kurulmuş olur.