DKIM: seçiciler, anahtar rotasyonu ve 2048 bit anahtarlar

DKIM nasıl çalışır?

DomainKeys Identified Mail (RFC 6376), gönderim yapan bir sistemin iletinin seçilmiş başlıklarını ve gövdesini bir özel anahtarla imzalamasına olanak tanır. İmza iletiye DKIM-Signature başlığı olarak eklenir; bu imzayla eşleşen açık anahtar ise alan adının DNS bölgesinde yayımlanır. Alıcı taraf anahtarı DNS üzerinden çeker, imzayı doğrular ve imzalanmış bölümlerin imzalandıkları andan bu yana değişmediğini görmüş olur. Böylece kimlik doğrulaması iletinin geldiği IP adresine değil, doğrudan iletinin kendisine bağlanmış olur.

İmzadaki iki etiket anahtarın nerede aranacağını belirler: d= imzalayan alan adıdır, s= ise seçicidir. Alıcı bu ikisini birleştirerek bir DNS adı oluşturur ve tam o adreste bir TXT kaydı sorgular. DMARC değerlendirmesi açısından ayrıca d= alan adının iletinin From alan adıyla hizalı olması gerekir; imza teknik olarak doğrulansa bile hizalı değilse DMARC sonucuna hiçbir katkı sağlamaz. Bir iletide bu iki etikete bakmak, sorunun DNS tarafında mı yoksa imzalama tarafında mı olduğunu anlamanın en hızlı yoludur.

Seçicileri belirlemek

Seçici aslında yalnızca bir etikettir, bu yüzden işletme tarafını kolaylaştıracak adlar seçin. Seçiciler sayesinde gönderim yapan her sistem kendi anahtarına sahip olabilir, ayrıca rotasyon sırasında eski ve yeni anahtar bir süre boyunca yan yana yaşayabilir. Seçici adı gönderdiğiniz her iletinin imzasında göründüğü için, herkesin görmesini istemeyeceğiniz iç proje adlarından ya da tedarikçi adlarından kaçının. İyi seçilmiş bir ad, aylar sonra bir kaydın neden orada durduğunu hatırlamanızı da kolaylaştırır.

Barındırılan sağlayıcılar seçiciyi çoğu zaman sizin yerinize belirler. Microsoft 365, kendi yönettiği anahtarlara işaret eden CNAME kayıtları olarak yayımlanan selector1 ve selector2 adlarını kullanır; Google Workspace ise varsayılan olarak google seçicisini kullanır. Gönderim yapan diğer hizmetler kendi adlarını alan adı kimlik doğrulama ayarlarında belgeler, dolayısıyla kurulum sayfası size hangi kaydı eklemenizi söylüyorsa kullandığı seçici de odur.

Bir alan adının seçicilerini DNS üzerinden listeleyemezsiniz, çünkü DNS'te _domainkey altındaki adları veren bir dizin yoktur. Bir sistemin hangi seçiciyi kullandığını bulmak için o sistemden gelen bir iletinin DKIM-Signature başlığındaki s= etiketini okuyun; örneğin E-posta Başlığı Analizi aracına başlıkları yapıştırmak bu bilgiyi birkaç saniyede önünüze getirir.

Anahtar kaydı

Açık anahtar, değeri bir etiket listesinden oluşan bir TXT kaydıdır. Bu listede yalnızca p= zorunludur; v=DKIM1 kullanıldığında ilk sırada gelmelidir. Boş bırakılmış bir p= değeri ise anahtarın iptal edildiği anlamına gelir ve o anahtarla üretilmiş imzalar artık doğrulanmaz.

s2026a._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxyz...IDAQAB"

2048 bit anahtarlara geçmek

RFC 8301, DKIM'in kriptografi gereksinimlerini 2018 yılında güncelledi. İmzalayan taraf en az 1024 bitlik RSA anahtarları kullanmak zorundadır ve en az 2048 bit kullanmalıdır; doğrulayan taraf ise 1024 ile 4096 bit arasındaki anahtarları doğrulayabilmek zorundadır. Aynı RFC imzalamada rsa-sha1 kullanılmamasını şart koşar, dolayısıyla ürettiğiniz her imza a=rsa-sha256 ile üretilmelidir. Bu gereksinimler yalnızca yeni kurulumlar için değil, yıllardır hiç dokunulmamış eski imzalama yapılandırmaları için de geçerlidir.

1024 bitlik bir anahtar hâlâ doğrulanır, ancak çok daha küçük bir güvenlik payı bırakır ve yeni anahtarlarda norm artık 2048 bittir. 4096 bitten büyük anahtarların her alıcıda doğrulanacağının garantisi yoktur, bu yüzden o sınırın ötesine geçmenin bir faydası da yoktur. Ed25519 anahtarları (RFC 8463) kısa ve güçlüdür, ama alıcı tarafındaki destek hâlâ eksiktir; bu nedenle RSA imzasının yerine değil, onunla birlikte kullanılır. Yaygın yaklaşım, iki anahtarı ayrı seçicilerde yayımlayıp iletileri her iki imzayla birden göndermektir.

2048 bitlik anahtarı DNS'e sığdırmak

2048 bitlik RSA için base64 açık anahtar yaklaşık 400 karakter uzunluğundadır. Tek bir TXT dizesi en fazla 255 karakter taşıyabildiğinden, değerin alıcıların aralarında boşluk bırakmadan birleştirdiği birkaç tırnaklı dizeye bölünmesi gerekir. Birçok DNS paneli bu bölme işlemini kendiliğinden yapar; bazıları dizelerin ayrı ayrı girilmesini bekler, bazıları ise uzun değerleri tümden reddeder. Panelinizin hangisini yaptığından emin değilseniz, kaydı yayımladıktan sonra değeri dışarıdan sorgulayıp kendi gözünüzle görün.

s2026a._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1SU1LfVLPHCozMxH2Mo4lgOEePzNm0tRgeLezV6ffAt0gunVTLw7onLRnrq0/IzW7yWR7QkrmBL7jTKEn5u+qKhbwKfBstIs+bMY2Zkp18gnTxKLxoS2tFczGkPLPgizskuemMghRniWaoLcyehkd3qqGElvW/VDL5AaWTg0nLVkjRo9z+40RQzuVaE8AkAFmxZzow3x+VJYKdr0"
  "CDy4jW3O/DmMvPiLqxgPVdl2i1tq+cn8hNQfvCyYe7Tnz4hWDYO0H1vPD1xJyV04BGcoJp1stVpvYy23wu8bN7DI+CWVuW5emFS2bIyCj3Q1YeW4+sPvgOvzP99l1OjMrBb4FBHGKQIDAQAB" )

Yayımladığınız sonucu, seçici adı için TXT kayıt türünü seçerek DNS Sorgulama aracıyla kontrol edin. Birleştirilmiş değerin, imzalama sisteminizin kullandığı anahtarın tam olarak aynısı olması gerekir; eksik ya da fazla tek bir karakter bile bütün imzaların dkim=fail ile başarısız olmasına yeter.

Postayı bozmadan anahtar değiştirmek

Rotasyon, sızmış bir özel anahtarın verebileceği zararı sınırlar ve eski, zayıf anahtarları devreden çıkarır. İşin püf noktası şudur: imzalar imzalandıkları anda değil, ileti alıcıya ulaştığı anda doğrulanır ve bir ileti geciktiğinde ya da sonradan yeniden doğrulandığında bu, imzalamadan dakikalar değil günler sonra olabilir. Bu yüzden eski açık anahtar, onunla imzalamayı bıraktıktan sonra da bir süre boyunca yayında kalmak zorundadır. Bu gecikme payını hesaba katmayan bir geçiş, yapılandırmada hiçbir hata olmasa bile imza hatalarına yol açar.

1. Yeni bir anahtar çifti üretin ve yeni bir seçici belirleyin, örneğin s2026b.
2. Yeni açık anahtarı s2026b._domainkey.example.com adresinde yayımlayın ve her çözümleyicinin görebilmesi için en az kaydın TTL süresi kadar bekleyin.
3. Kaydı sorgulayarak doğrulayın; sisteminiz destekliyorsa yeni seçiciyle imzalanmış bir test iletisi göndererek de doğrulayın.
4. Eski seçiciyi kullanan her sistemde imzalamayı yeni seçiciye geçirin.
5. Geciken iletilerin de doğrulanabilmesi için eski açık anahtarı bir hoşgörü süresi boyunca, genellikle bir ila birkaç hafta, yayında tutun.
6. Eski seçici için v=DKIM1; p= yayımlayarak eski anahtarı iptal edin, kaydı ise daha sonra tümüyle kaldırın.

s2026a._domainkey.example.com. IN TXT "v=DKIM1; p="

Ne sıklıkta rotasyon yapılacağı bir politika kararıdır. Birçok kurum altı ila on iki ayda bir rotasyon yapar, ayrıca özel anahtarın açığa çıkmış olabileceği her durumda, örneğin bir sunucu ele geçirildiğinde ya da bir tedarikçiyle ilişki sona erdiğinde bunu hemen yapar. CNAME devri kullanan barındırılan sağlayıcılar ise anahtarlarını kendi takvimlerine göre değiştirir ve bunun için sizden bir işlem beklemez. Seçtiğiniz aralığı yazılı bir yordam hâline getirin; böylece iş, anahtarı üreten kişinin hafızasına bağlı kalmaz.

Geçiş yapmadan önce yeni anahtarı test etmek

Yanlış yayımlanmış bir anahtar, kendisini kullanan her imzayı başarısız kılar; bu yüzden üretim trafiğini yeni anahtara taşımadan önce mutlaka doğrulama yapın. Önce yeni seçicinin TXT kaydını sorgulayın ve p= değerini kendi özel anahtarınızdan türettiğiniz açık anahtarla karşılaştırın. Tek bir yanlış karakter, bölünmüş bir kayıtta eksik kalan bir dize ya da araya karışmış bir boşluk doğrulamayı bozmaya yeter. Bu karşılaştırma birkaç dakika sürer ve üretim postasının tamamını riske atmanızı engeller.

# public key derived from the private key, as one base64 line
openssl rsa -in s2026b.private.pem -pubout -outform DER 2>/dev/null | openssl base64 -A; echo

# published value (strings joined)
dig +short TXT s2026b._domainkey.example.com | tr -d '" \n'; echo

Ardından, sisteminiz seçiciyi seçmenize izin veriyorsa yeni seçiciyle imzalanmış bir test iletisi üretin ve bunu büyük bir sağlayıcıdaki posta kutusuna gönderin. İletinin Authentication-Results başlığında dkim=pass sonucu ve onun yanında header.s=s2026b görünmelidir. Test iletisini birden fazla sağlayıcıya göndermek, bir sorunun tek bir alıcıya mı özgü olduğunu da gösterir. Ancak bütün bunları gördükten sonra trafiğin tamamını yeni seçiciye geçirin.

Fark yaratan imzalama tercihleri

Kanonikleştirme

c= etiketi, boşlukların ve başlık adlarındaki büyük küçük harf farklarının ne kadar katı karşılaştırılacağını belirler. c=relaxed/relaxed, iletiyi yolda taşıyan posta sunucularının yaptığı küçük biçim değişikliklerini hoş görür ve yaygın tercih de budur; simple ise çok daha kolay bozulur. Katı karşılaştırma, iletiyi taşıyan her ara sunucunun kusursuz davranmasını beklemek anlamına gelir.

Hangi başlıklar imzalanmalı

From başlığı her koşulda imzalanmak zorundadır (RFC 6376 §5.4). Bunun yanında iletiye anlamını veren başlıkları da imzalayın: Subject, Date, To, Message-ID ve Reply-To gibi. Bir başlık adını, iletide göründüğünden bir kez daha fazla listelemek, imzayı bozmadan o başlığın ikinci bir kopyasının eklenmesini engeller.

l= etiketinden kaçının

l= etiketi gövdenin yalnızca ilk bölümünü imzalar. RFC 6376 §8.2, bunun imzalanmış bir iletinin sonuna içerik eklenmesine izin verdiği ve eklemeye rağmen imzanın doğrulanmaya devam ettiği konusunda uyarır; bu yüzden etiketi hiç kullanmayın.

Uygulamada DKIM ve DMARC hizalaması

Bir ileti birden fazla DKIM imzası taşıyabilir ve bu oldukça yaygın bir durumdur. Bir bülten hizmeti, sizin d=example.com imzanızın yanına d=esp.example.net etiketiyle kendi imzasını ekleyebilir. DMARC, doğrulanan imzalardan herhangi biri From alan adıyla hizalı olduğunda geçer; dolayısıyla sağlayıcının eklediği fazladan imza size hiçbir zarar vermez. Sizin yapmanız gereken, kendi imzanızı kaldırmak değil, onun hizalı biçimde doğrulandığından emin olmaktır.

DMARC'ın varsayılanı olan gevşek hizalama, kurumsal alan adını paylaşan imzalama alan adlarını kabul eder. d=mail.example.com ile atılmış bir imza, example.com üzerindeki bir From adresiyle hizalı sayılır; bu da gönderim yapan her sisteme kendi imzalama alt alan adını vermenize olanak tanır. Katı hizalama (adkim=s) birebir eşleşme ister ve getirdiği ek kırılganlık çoğu kurumda bu kazanca değmez.

Bir hizmet sizden hiç DNS kaydı istemeden “otomatik DKIM” sunuyorsa, büyük olasılıkla iletilerinizi kendi alan adıyla imzalıyordur. Bu kurulum DKIM doğrulamasını geçirir ama DMARC hizalamasını sağlamaz; DMARC geçiş planı rehberinin zorlamaya geçmeden önce düzeltmenizi söylediği durum tam olarak budur.

Özel anahtarları korumak

DKIM özel anahtarınızı ele geçiren herkes, sizin alan adınız adına DKIM ve DMARC doğrulamasını geçen posta imzalayabilir. Bu yüzden anahtarı bir TLS özel anahtarı gibi ele alın: erişim izinlerini kısıtlayarak saklayın, kaynak kodu depolarının ve çok sayıda kişinin okuyabildiği yedeklerin dışında tutun, mümkünse bir anahtar yönetimi hizmetini ya da imzalama platformunun kendi anahtar deposunu tercih edin. CNAME devri kullanan barındırılan sağlayıcılar özel anahtarı size hiçbir zaman vermez, bu da riski tümüyle ortadan kaldırır.

Tek bir ortak anahtar yerine gönderim yapan her sistem için ayrı bir anahtar kullanın. Bir tedarikçiyle yollar ayrıldığında ya da bir sunucu ele geçirildiğinde tek bir seçiciyi iptal edersiniz ve postanızın geri kalanı geçmeye devam eder. Ayrı anahtarlar ayrıca raporlarda ve ileti başlıklarında belirli bir iletiyi hangi sistemin imzaladığını ilk bakışta görmenizi sağlar. Bu ayrım, bir olay müdahalesi sırasında hangi sistemin kapatılacağına karar vermeyi de kolaylaştırır.

• Anahtarları dizüstü bilgisayarda değil, imzalamayı yapan sistemde veya bir anahtar yönetimi hizmetinde üretin.
• Hangi seçicinin hangi sisteme ait olduğunu ve o sistemin sahibinin kim olduğunu yazılı olarak kayıt altına alın.
• Hizmetten çıkardığınız sistemlerin anahtarlarını yayında bırakmak yerine iptal edin.
• Özel anahtarın açığa çıkmış olabileceği her durumda beklemeden rotasyon yapın.

DKIM replay saldırısı ve sınırlandırılması

Bir DKIM imzası, iletinin alan adınız tarafından imzalandığını kanıtlar; kime gönderildiğini değil. Replay saldırısında saldırgan, meşru biçimde imzalanmış tek bir iletiyi ele geçirir, örneğin kullanıcılarına posta göndertebilen bir hizmete kaydolarak, ve sonra o iletiyi çok sayıda alıcıya yeniden gönderir. İmza hâlâ doğrulandığı için gönderilen istenmeyen postalar alan adınızın itibarını devralır.

Başlıca savunma, güvenilmeyen bir kullanıcının içeriğini belirlediği iletileri hız sınırı ve kötüye kullanım izlemesi olmadan imzalamamaktır. Daha fazla başlığı imzalamak da işe yarar, çünkü saldırgan imzayı bozmadan konuyu değiştiremez veya yeni bir başlık ekleyemez. İsteğe bağlı x= etiketi imzaya bir son kullanma zamanı verir ve kopyalanmış bir iletinin doğrulanmaya devam ettiği pencereyi daraltır; bunun bedeli, gerçekten gecikmiş postaların da başarısız olmasıdır.

dkim=fail sonucunu gidermek

Denetlediğiniz bir posta kutusuna bir test iletisi gönderin, iletinin özgün hâlini açın ve başlıkları E-posta Başlığı Analizi aracına yapıştırın. Araç SPF, DKIM ve DMARC sonuçlarını tek bakışta gösterir; JSON çıktısı ise header.d ve header.s değerlerini taşıyan Authentication-Results satırı dahil olmak üzere ayrıştırılmış her başlığı içerir.

SSS

Kaynaklar

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 8463: A New Cryptographic Signature Method for DKIM (Ed25519)
• Microsoft Learn: Kendi alan adınızdan gönderilen postaları imzalamak için DKIM kurulumu
• Google Workspace: DKIM kurulumu