DKIM İmzası Nedir? Selector, Açık Anahtar ve Doğrulama

DKIM, bir e-postayı gönderen sunucunun ya da servisin iletiyi özel anahtarıyla imzalaması, alıcının da DNS'teki açık anahtarla bu imzayı doğrulamasıdır. İmza, iletinin başlığında DKIM-Signature adıyla taşınır; hangi anahtarın kullanılacağını imzadaki alan adı (d=) ve seçici (s=) belirler. Geçerli bir imza, imzalanan içeriğin yolda değişmediğini gösterir; imzayı atan alan adının iletideki From alan adıyla aynı olduğunu tek başına göstermez. Bülten, sipariş bildirimi ya da kampanya e-postası gönderen blog ve site sahipleri için asıl iş, her gönderici sistemin imzasını kendi alan adlarına bağlamak ve anahtarları düzenli tutmaktır.

Kimlerin hangi izinle e-posta gönderebileceği ayrı bir konudur; onay tarafı için e-bülten aboneliği ve KVKK yazısına bakın. Aşağıda yalnızca imzanın teknik işleyişi, DNS kaydı ve sorun giderme yer alıyor.

İmza ileti içinde nasıl taşınır

DKIM, RFC 6376 (yeni sekmede açılır) ile tanımlanır. Gönderen taraf iletinin seçilmiş başlıklarını ve gövdesini bir özet fonksiyonundan geçirir, çıkan değeri özel anahtarla imzalar ve sonucu iletinin başına DKIM-Signature adlı bir başlık olarak ekler. Alıcı aynı işlemi tersine yürütür: imzadaki bilgilerle açık anahtarı bulur, kendi hesapladığı özeti imzayla karşılaştırır.

DKIM-Signature başlığındaki etiketler

RFC Bölüm 3.5, başlıktaki etiketleri tanımlar. Bir site sahibinin tanıması gereken etiketler şunlardır:

Kanonikleştirme: küçük biçim değişiklikleri

İletiler yolda boşluk düzenlemesi gibi küçük değişikliklere uğrayabilir. Kanonikleştirme bu farkları imza hesaplamadan önce eşitler. Başlıklar için simple yöntemi alanları olduğu gibi bırakır; relaxed yöntemi alan adlarını küçük harfe çevirir, ardışık boşlukları birleştirir ve baştaki ve sondaki boşlukları kaldırır (Bölüm 3.4.1 ve 3.4.2). Gövde için simple yöntemi sondaki boş satırları atar; relaxed yöntemi satır içi ve satır sonu boşlukları da azaltır (Bölüm 3.4.3 ve 3.4.4). Bir e-posta servisi kullanıyorsanız bu ayarı servis yapar; yine de başlıklarda c=relaxed/relaxed gibi bir değer görürseniz şaşırmayın.

Gmail açısından DKIM

Google'ın e-posta göndericisi yönergeleri sayfası (yeni sekmede açılır), kişisel Gmail hesaplarına ileti gönderen herkesten SPF veya DKIM kurmasını, günde 5.000 ve üzeri ileti gönderenlerden ikisini birden kurmasını ister. Kişisel Gmail hesaplarına göndermek için 1024 bit veya daha uzun bir anahtar gerekir; alan adı sağlayıcınız destekliyorsa güvenlik için 2048 bit önerilir. Google belgelerindeki sınırlar ve şartlar değişebilir; uygulamadan önce güncel sayfaya bakın.

Selector ve DNS'teki açık anahtar

Seçici (selector), bir alan adının birden çok anahtar tutabilmesini sağlayan etikettir. RFC Bölüm 3.1, seçicilerin bir alan adının anahtar ad alanını bölerek aynı anda birden fazla anahtarın geçerli olmasına imkân verdiğini anlatır. Seçicideki nokta DNS etiket ayırıcısı gibi işlenir.

Anahtar kaydı nerede durur

Açık anahtar, alan adının _domainkey alt alanında bir TXT kaydı olarak yayımlanır. RFC Bölüm 3.6.2.1 örneği verir: d=example.com ve s=foo.bar için sorgulanan ad foo.bar._domainkey.example.com olur. Genel kalıp şöyledir: seçici + ._domainkey. + alan adı. Aynı seçici için tek bir TXT kaydı bulunmalıdır; kayıt birden fazla dizi halinde yazılmışsa diziler boşluksuz birleştirilir (Bölüm 3.6.2.2).

Anahtar kaydındaki etiketler

t=y test bayrağı konusunda RFC açıktır: doğrulayıcılar test kipindeki iletilere imzasız iletilerden farklı davranmamalıdır (Bölüm 3.6.1). Yani test bayrağı koymak, hatalı bir anahtarı korumaz; yalnızca doğrulamanın sonucuna göre işlem yapılmamasını bekler. Uygulama önerisi: test bayrağını yayında kullanmak yerine, bir seçiciyi önce kendi test iletilerinizle sınayın.

Anahtar uzunluğu: ne kadar ayrıntı gerekir

İmzalayanların uzun ömürlü anahtarlar için en az 1024 bit kullanması gerekir (RFC 6376, Bölüm 3.3.3). Doğrulayıcılar 512 ile 2048 bit arası anahtarları işleyebilmelidir; daha büyükleri işleyebilirler. Gmail sayfasının dediği ise şudur: kişisel Gmail hesaplarına göndermek için 1024 bit veya daha uzun anahtar gerekir ve sağlayıcı destekliyorsa 2048 bit önerilir. Bir site sahibi için pratik sonuç sadelik: sağlayıcınızın 2048 bit seçeneği varsa onu seçin. 2048 bitlik bir açık anahtarın metni uzundur; DNS panelinizin tek dize sınırı yüzünden uzun kaydı kabul etmemesi mümkündür. Bu durumda değeri tırnaklı parçalara bölme seçeneğine bakın. Ayrıntıların geri kalanını sağlayıcınızın dokümanına bırakın.

Servisin verdiği kayıtları eklemek

Bir e-posta servisi kullanıyorsanız özel anahtarı servis tutar ve DNS'e eklemeniz için size bir ad ve bir değer verir. Ad, anahtar kaydının yukarıdaki kalıba uyan konumudur. Servisin istediği kayıt türünü ve adı kendi dokümanından teyit edin; RFC yalnızca anahtarın TXT kaydı olarak yayımlandığı durumu tanımlar.

İmza geçerli ama hizalama yok

Bir iletinin DKIM sonucunun "pass" olması, From alan adının sizin olduğunu kanıtlamaz. RFC Bölüm 1.2, imzalayan kimliğin ileti başlıklarındaki herhangi bir adresle eşleşmek zorunda olmadığını söyler; Bölüm 3.11 ise d= ve i= değerlerinin diğer kimliklerle ilişkisini değerlendirmeyi, değerlendiren tarafa bırakır. DKIM'in yalnızca imzalı içeriğin değişmediğini ve imzanın belirli bir alan adının anahtarıyla atıldığını söylediği Bölüm 1.5'te de belirtilir.

DMARC bu boşluğu nasıl kapatır

DMARC, DKIM sonucunu görünen From alan adıyla ilişkilendirir. RFC 7489 (yeni sekmede açılır) Bölüm 3.1'e göre bir iletinin DMARC'tan geçmesi için en az bir mekanizmanın hizalı bir kimlik için "pass" üretmesi gerekir; birden fazla DKIM imzası varsa hizalı ve doğrulanan tek bir imza yeterlidir. Gevşek kipte kurumsal alan adları karşılaştırılır, sıkı kipte tam alan adı eşleşmesi aranır. Gmail sayfası da doğrudan gönderimde From: alan adının SPF alan adıyla veya DKIM alan adıyla hizalanmasını ister.

Sık görülen durum: servisin alan adıyla imza

Bir e-posta servisi kendi alan adıyla imzalıyorsa DKIM kendi başına geçer, ama d= değeri servisin alan adıdır; sizin From alan adınızla eşleşmez. Çözüm, servisin panelinde alan adınızı doğrulatmak ve verdiği DNS kayıtlarını eklemektir. Servis bunun ardından iletileri sizin alan adınızı d= olarak kullanarak imzalar. İsterseniz servis iki imza atabilir: biri kendi alan adıyla, biri sizinle. RFC 7489'a göre sizin imzanız hizalıysa DMARC için yeterlidir.

Örnek senaryo: seyahat blogu

Örnek senaryo: Bir seyahat blogu haftalık bülteni bir e-posta servisinden, yorum yanıtı bildirimlerini ise blogun kendi barındırma sağlayıcısından gönderiyor. Bülten ileti başlığında DKIM sonucu "pass" görünüyor, ancak d= servisin alan adı. Blog sahibi servis panelinde kendi alan adını doğrulatıp verilen anahtar kaydını DNS'e ekliyor ve iletilerin artık kendi alan adıyla imzalandığını yeni bir test iletisinin başlığında doğruluyor. Barındırma sağlayıcısından gelen bildirimler için ise ayrı bir DKIM anahtarı olup olmadığını sağlayıcıya soruyor; yoksa bu akış için hizalama yalnızca SPF'ye bağlı kalıyor.

Hizalamayı kontrol listesi

• İleti başlığında d= değeri sizin alan adınız mı, yoksa alt alan adınız mı?
• Servis birden fazla imza atıyor mu? Hangisi sizin alan adınızı taşıyor?
• From alan adı ile d= alan adı aynı kurumsal alan adı altında mı?
• DMARC kaydınız sıkı hizalama (adkim=s) istiyorsa, d= tam olarak From alan adıyla mı eşleşiyor?

Gönderici değişince anahtar yenileme

Servis değiştirmek ya da bir anahtarı yenilemek, DKIM'in seçici yapısı sayesinde kesintisiz yapılabilir. Sırayı bozarsanız iletiler bir süre doğrulanamaz.

Kesintisiz geçiş sırası

1. Yeni anahtar için yeni bir seçici belirleyin ve açık anahtarı DNS'e ekleyin. Eski seçici ve anahtarı yerinde kalsın.
2. DNS değişikliği yayıldıktan sonra gönderen sistemi yeni özel anahtar ve yeni seçiciyle imza atacak şekilde ayarlayın.
3. Eski seçiciyle imzalanmış iletiler hâlâ yolda olabileceği için eski açık anahtarı bir süre DNS'te bırakın. Ne kadar süre bırakacağınız RFC'de sayıyla verilmez; RFC, eski açık anahtarın doğrulamanın tamamlanabileceği kadar uzun tutulmasını söyler.
4. Süre dolunca eski kaydı kaldırın ya da p= değerini boşaltarak iptal edin.

RFC 6376 Bölüm 3.1 ve 5.2, seçicilerin bu kullanım biçimini tarif eder. Aynı bölümler seçicilerin yeni anahtarlar için yeniden kullanılmamasını da öğütler: eski bir anahtarla imzalanmış iletiler ile sahte iletileri ayırt etmek zorlaşır (Bölüm 3.1).

İptal: p= boş

Anahtar kaydındaki p= değeri boşsa anahtar iptal edilmiş sayılır ve seçici bilinir kalır (Bölüm 3.6.1). İptal edilmiş anahtarla gelen imza, doğrulayıcı tarafından başarısız imza kontrolü olarak değerlendirilir (Bölüm 6.1.2). RFC ayrıca iptalin etkisinin sınırlı olabileceğini belirtir (Bölüm 8.7). Anahtarın ele geçirildiğinden şüpheleniyorsanız yalnızca eski kaydı silmek yetmez; yeni bir seçiciye geçmek ve gönderen sistemin eski anahtarla imza atmasını durdurmak gerekir.

Servis değişikliğinde sıra

Karar kuralı: yeni anahtar mı, yeni seçici mi

1. Aynı seçiciye yeni bir anahtar yazmayın; her yeni anahtar için yeni bir seçici kullanın.
2. Servis değiştiriyorsanız servisin verdiği seçiciyi kullanın; kendi seçici adınızı dayatmanız gerekmez.
3. Eski seçiciyi kaldırmadan önce o seçiciyle imzalanmış iletinin artık gönderilmediğinden emin olun.

Bu kural RFC'nin seçici önerilerinden türetilmiş bir uygulama önerisidir.

İmzaya hangi başlıklar girer

DKIM'in neyi koruduğu, imzalanan başlıklar ve gövdeyle sınırlıdır. İmzaya girmeyen başlık değişirse imza yine geçerli kalır; bu yüzden imzalanan listeyi bilmek önemlidir.

h= listesi ve From zorunluluğu

h= etiketi, imzaya dahil edilen başlık adlarını sayar. RFC 6376 Bölüm 5.4 From başlığının imzalanmasını zorunlu kılar; h= içinde From yoksa doğrulayıcı imzayı yok sayar ve PERMFAIL döndürür (Bölüm 6.1.1). Aynı etiket, imza anında iletide bulunmayan başlık adlarını da listeleyebilir; böylece imzalandıktan sonra o başlıkların iletiye eklenmesi fark edilir (Bölüm 3.5). Bir e-posta servisi kullanıyorsanız bu listeyi servis belirler; ham başlıkta h= değerine bakarak Subject, To ve Date gibi başlıkların da imzalandığını görebilirsiniz.

l=, t=, x= ve z= etiketleri

l= etiketi gövdenin yalnızca ilk bölümünü imzalamaya yarar ve imzalanan gövde uzunluğunu sınırlar. RFC, bu etiketin kötüye kullanımını ayrıca ele alır (Bölüm 3.5 ve 8.2). Uygulama önerisi: kendi kurduğunuz bir imzalayıcıda l= kullanmak için net bir nedeniniz yoksa kullanmayın; gövdenin geri kalanı imza kapsamı dışında kalır. t= imza zamanını, x= bitiş zamanını belirtir; ikisi de önerilir, ama RFC x= etiketinin bir tekrar oynatma (replay) savunması olarak tasarlanmadığını açıkça yazar. z= etiketi yalnızca tanılama içindir.

Geçerli imza ile iyi niyetli ileti aynı şey değildir

RFC Bölüm 8.6 bir saldırı senaryosunu anlatır: bir spam gönderen, ileti imzalayan bir posta sunucusu üzerinden spam gönderir ve elde ettiği imzalı iletiyi başka alıcılara tekrar yollar. İmza geçerli kalır, çünkü içerik değişmemiştir. Sonuç şudur: DKIM bir kimlik ve bütünlük kanıtıdır, itibar kanıtı değildir. Gmail sayfasının spam oranı ve kullanıcı şikayetlerini imzadan ayrı etkenler olarak sayması da bu yüzden anlamlıdır.

Bir e-posta servisinde DKIM kurulumu: adım adım

Her servisin paneli farklıdır; arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir. Aşağıdaki sıra servislerden bağımsız bir çerçevedir.

1. Servis panelinde "domain" veya "sender authentication" benzeri bir bölüm arayın ve alan adınızı ekleyin. Bu bölümün adı servise göre değişir.
2. Servis size bir veya birkaç DNS kaydı verecektir. Kaydın adını, türünü ve değerini aynen kopyalayın; ad kısmında alan adının otomatik eklenip eklenmediğini DNS panelinizde kontrol edin.
3. Kaydı DNS panelinize ekleyin ve yayılması için bir süre bekleyin. Süre DNS sağlayıcınıza ve TTL değerine bağlıdır; bu konuda RFC'de ya da Gmail sayfasında bir süre yazmaz.
4. Servis panelinde doğrulama düğmesine basın. Başarısız olursa kaydın adı ve değeri yeniden gözden geçirilmelidir.
5. Kendinize bir test iletisi gönderin ve ham başlıkta DKIM-Signature satırındaki d= değerinin sizin alan adınız olduğunu doğrulayın.
6. Aynı alan adından ileti gönderen diğer sistemler için işlemi tekrarlayın.

Kurulum tamamlandı mı: bir bakışta

DKIM ve SPF yan yana

İki yöntem birbirinin yerine geçmez, farklı soruları cevaplar. Aşağıdaki tablo ikisinin farklarını kaynaklara dayanarak özetler.

Sık yapılan hatalar

Birden fazla sistem için DKIM envanteri

Bir sitenin e-postası tek yerden çıkmaz: bülten servisi, site sunucusu, destek aracı, fatura sistemi. Her birinin kendi imzası, kendi seçicisi ve kendi anahtar yaşam döngüsü olabilir. Dağınık kalırsa bir servis bırakıldığında eski anahtar yıllarca DNS'te unutulur.

Envanter tablosu

Seçici adlandırması

RFC seçici adlarının biçimini sizin için belirlemez; yalnızca bir alan adının aynı anda birden fazla seçici tutabileceğini söyler. Uygulama önerisi: sistem adını ve kurulum yılını içeren okunur bir ad seçin, örneğin bulten2026 gibi. Böylece DNS'e bakan biri hangi kaydın hangi sisteme ve hangi döneme ait olduğunu anlar. Servisin zorunlu kıldığı bir seçici adı varsa onu değiştirmeyin.

Yenileme sıklığı için ne denebilir

RFC 6376 anahtarların ne sıklıkla yenileneceğine dair bir süre vermez; Gmail sayfası da vermez. Bu nedenle "yılda bir yenileyin" gibi bir kural kaynaklara dayanmaz. Uygulama önerisi: yenileme takvimini kendi risk iştahınıza göre belirleyin ve en azından servis değiştirdiğinizde, ekipten biri ayrıldığında ve özel anahtarın başkasının eline geçme ihtimali doğduğunda anahtarı yenileyin. Servis özel anahtarı sizin yerinize tutuyorsa yenileme sıklığı servisin sunduğu seçeneklere bağlıdır.

Envanteri güncel tutmak

• Yeni bir araç alan adınız adına ileti göndermeye başlamadan önce envantere ekleyin.
• Bir araç bırakıldığında kaydını envanterden ve DNS'ten kaldırın.
• Her çeyrekte test iletileriyle d= ve s= değerlerini yeniden doğrulayın.

Doğrulama ve sorun giderme

Uygulama önerisi: DKIM hatasında önce iki yere bakın, DNS'teki anahtar kaydına ve imzalı içeriğin değişip değişmediğine. RFC Bölüm 6.1, doğrulayıcının imzaları işlerken karşılaşabileceği sonuçları tanımlar.

Doğrulayıcı hangi sonuçları verir

PERMFAIL ya da TEMPFAIL durumunda doğrulayıcı o imzanın işlenmesini hemen keser ve varsa sıradaki imzaya geçer (Bölüm 6.1). Yani bir iletide birden fazla imza varsa tek bir bozuk imza, diğerlerinin işlenmesini engellemez.

Geçici ve kalıcı hata ayrımı

RFC 6376 Bölüm 6.1.2'ye göre anahtar bulunamadığında doğrulayıcı bunu kalıcı hata sayabilir; DNS yanıt vermediğinde ise sonraki bir doğrulama denemesini isteyerek geçici hata döndürebilir. Bu ayrım size şunu söyler: geçici hata anlık bir DNS sorununun belirtisi olabilir ve kayıtta bir şey değiştirmeden kendiliğinden düzelebilir; kalıcı hata ise kaydı, seçiciyi ya da imzayı düzeltmeniz gerektiğini gösterir. Tek bir başarısız test iletisinden sonuç çıkarmadan önce iletiyi birkaç dakika sonra bir kez daha gönderin.

Adım adım teşhis

1. Test iletisi gönderin ve ham başlıkları açın. DKIM-Signature başlığında d= ve s= değerlerini not edin.
2. Bu iki değerden anahtar adını kurun: s değeri + ._domainkey. + d değeri. DNS sorgu aracıyla bu adın TXT kaydını çekin.
3. Kayıt dönmüyorsa seçici ve alan adı yazımını, kaydın doğru alan adı altında yayımlanıp yayımlanmadığını kontrol edin. Bazı DNS panelleri alan adını kendiliğinden ekler; adın iki kez yazılmadığına bakın.
4. Kayıt dönüyorsa p= değerinin dolu olduğunu, v=DKIM1 etiketinin ilk sırada durduğunu ve uzun değerin parçalara bölünürken bozulmadığını kontrol edin.
5. İmza var, anahtar var, yine de doğrulanmıyorsa iletinin yolda değişip değişmediğine bakın: bir posta ağ geçidi altbilgi eklemiş ya da gövdeyi yeniden biçimlendirmiş olabilir. Bu durum gövde özeti uyuşmazlığı olarak görünür.

Sorun giderme kontrol listesi

• d= alan adı sizin alan adınız (ya da bilinçli olarak servisinki) mi?
• s= seçicisi için DNS'te tek bir TXT kaydı var mı?
• p= değeri dolu ve eksiksiz mi?
• h= listesinde From var mı?
• Anahtar uzunluğu en az 1024 bit mi, mümkünse 2048 bit mi?
• Eski seçiciler kullanılmıyorsa temizlendi mi?

Bu, tek başına yetmez

Geçerli bir DKIM imzası iletinin gelen kutusuna düşeceğini söylemez. Gmail sayfası SPF, DKIM, DMARC, hizalama, spam oranı ve abonelikten çıkış gibi birbirinden bağımsız şartlar sayar. Bültende sponsorlu bölümler varsa sponsorlu içerik etiketleme kurallarını, reklam verenlerle paylaşacağınız kitle bilgisi için medya kiti hazırlama adımlarını ve bülten bağlantılarının ölçümü için UTM ve Search Console raporlamasını ayrıca gözden geçirin.

Sık Sorulan Sorular

DKIM imzası tam olarak neyi kanıtlar?

RFC 6376'ya göre geçerli bir imza, imzalanan içeriğin imzalandıktan sonra değişmediğini gösterir. İmzalayan alan adının iletideki From alan adıyla aynı olduğunu tek başına kanıtlamaz; bu ilişkiyi DMARC hizalaması kurar.

Selector nedir, nasıl seçilir?

Seçici, DKIM-Signature başlığındaki s= etiketidir ve DNS'te hangi anahtar kaydına bakılacağını söyler. Anahtar adı seçici, ._domainkey. ve alan adından oluşur. E-posta servisi kullanıyorsanız seçici adı, servisin size verdiği DNS kayıtlarında yer alır.

DKIM anahtarı kaç bit olmalı?

RFC 6376'ya göre imzalayanlar uzun ömürlü anahtarlar için en az 1024 bit kullanmalıdır. Gmail sayfası kişisel Gmail hesaplarına göndermek için 1024 bit veya daha uzun anahtar ister ve sağlayıcı destekliyorsa 2048 bit önerir.

DKIM geçiyor ama DMARC geçmiyor, neden?

Büyük ihtimalle imza servisin alan adıyla atılmıştır ve From alan adınızla hizalı değildir. Servis panelinde kendi alan adınızı doğrulatıp servisin verdiği DNS kayıtlarını ekleyin; imzadaki d= değeri sizin alan adınız olmalıdır.

Servisi değiştirirken eski DKIM kaydını ne zaman silmeliyim?

Önce yeni servisin anahtarını ekleyip gönderimi doğrulayın, eski servisle gönderimi durdurun ve eski kaydı doğrulamanın tamamlanabileceği kadar bir süre tutun. RFC süreyi sayıyla vermez. Sonra kaydı kaldırın ya da p= değerini boşaltarak iptal edin.

DKIM hatasını nasıl teşhis ederim?

Ham başlıktaki DKIM-Signature satırından d= ve s= değerlerini alın, s + ._domainkey. + d adının TXT kaydını sorgulayın, p= değerinin dolu olduğunu ve From başlığının h= listesinde bulunduğunu doğrulayın. İmza doğrulanmıyorsa iletinin yolda değişip değişmediğine bakın.

Sonuç

DKIM, iletinin imzalanmasıyla içeriğin yolda değişmediğini gösterir; hangi anahtarın kullanılacağını imzadaki alan adı ve seçici belirler, açık anahtar ise seçici._domainkey.alanadi adındaki TXT kaydında durur. Geçerli imza, tek başına From alan adının sizin olduğunu kanıtlamaz; bu ilişki DMARC hizalamasıyla kurulur, bu yüzden servisinizde kendi alan adınızla imzalamayı açın. Anahtar yenilerken yeni bir seçici kullanın, eski anahtarı doğrulamanın tamamlanması için bir süre tutun ve sonra kaldırın. Sorun çıktığında anahtar adını ham başlıktan kurup DNS kaydını çekmek, nedenin DNS'te mi yoksa iletide mi olduğunu ayırmanızı sağlar.

Bültenle ulaştığınız kitleyi reklam verenlere sunmak istiyorsanız Akua Adforce'ta tanıtım yazısı ilanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.