DKIM Nasıl Çalışır: E-postanızı Sahtecilikten Koruyan Dijital İmza

DKIM olmadan gönderilen bir e-posta, alıcı sunucunun gözünde imzasız bir mektup gibidir; kimin gerçekten gönderdiğini kanıtlayamaz. Adresli B2B soğuk e-posta gönderen bir satış ekibi için bu, mesajın spam klasörüne düşmesi ya da hiç ulaşmaması demektir. Bu yazıda DKIM'in teknik olarak ne yaptığını, SPF ve DMARC ile ilişkisini ve birden fazla gönderim aracı kullanan bir ekibin kurulumu nasıl adım adım tamamlayacağını anlatıyoruz.

DKIM tam olarak ne yapar

DKIM (DomainKeys Identified Mail), giden bir e-postaya domain sahibinin elinde tuttuğu özel anahtarla kriptografik bir imza ekler. Bu imza, e-postanın başlık bölümünde DKIM-Signature adıyla görünür ve genellikle From, Subject, Date gibi belirli başlıkların yanı sıra ileti gövdesinin bir özetini (hash) de kapsar. Karşılığındaki açık anahtar ise DNS'de selector._domainkey.domain.com biçiminde bir TXT kaydında yayınlanır.

Alıcı posta sunucusu bir e-posta aldığında, başlıktaki selector bilgisini okuyup ilgili DNS kaydından açık anahtarı çeker ve imzayı bu anahtarla doğrular. Doğrulama geçerse iki şey kanıtlanmış olur: e-posta gerçekten o domain adına imzalanmıştır ve yolda (aktarım sırasında) içerik değişmemiştir. Doğrulama başarısız olursa bu, ya imzanın sahte olduğu ya da ileti gövdesinin/başlıklarının değiştirildiği anlamına gelebilir.

Burada önemli bir ayrım var: DKIM içeriği şifrelemez, sadece kimin imzaladığını ve içeriğin değişmediğini kanıtlar. Ayrıca teslimatı garanti etmez — alıcı sunucu DKIM'i geçen bir e-postayı yine de spam olarak işaretleyebilir, çünkü itibar (reputation), içerik kalitesi ve DMARC uyumu gibi başka faktörler de devrede.

DKIM-Signature başlığının kendisi de birkaç önemli parametre taşır: a= imzalama algoritmasını (genelde rsa-sha256), c= canonicalization (kanonikleştirme) modunu — relaxed veya simple, yani aktarım sırasında boşluk/satır sonu gibi küçük farklara ne kadar tolerans gösterileceğini — ve h= imzaya dahil edilen başlık alanlarının listesini belirtir. Relaxed mod, e-postanın bazı posta sunucularından geçerken maruz kaldığı küçük biçimsel değişikliklere (fazladan boşluk gibi) tolerans tanıdığı için pratikte simple moda göre daha az yanlış negatif üretir ve çoğu gönderim aracının varsayılanıdır.

SPF, DKIM, DMARC: hangisi ne işe yarar

Üç mekanizma da e-posta kimlik doğrulamasının parçasıdır ama farklı soruları yanıtlar. SPF, „bu IP adresi bu domain adına e-posta göndermeye yetkili mi?" sorusuna DNS üzerinden cevap verir. DKIM, „bu e-posta gerçekten iddia ettiği domain tarafından imzalanmış mı ve değiştirilmiş mi?" sorusunu yanıtlar. DMARC ise ikisinin sonucunu From başlığındaki domain ile hizalayıp (alignment) alıcıya „bu kontroller başarısız olursa ne yap" talimatını verir.

Üçü birlikte çalıştığında domain sahtekarlığına karşı katmanlı bir savunma oluşur. Sadece SPF kurulu bir domain, e-posta forward edildiğinde veya farklı bir yoldan iletildiğinde kolayca SPF hatası verebilir; DKIM imzası ise ileti içeriğiyle birlikte taşındığı için forward sonrasında bile büyük ölçüde geçerliliğini korur. Bu yüzden DKIM, SPF'in zayıf kaldığı senaryolarda güvenilirliği artıran tamamlayıcı bir katmandır.

Somut bir örnek: bir satış temsilcisinin gönderdiği e-postayı alıcı kendi asistanına iletiyor (forward). Orijinal SPF kontrolü, e-postanın artık asistanın posta sunucusundan geçtiğini gördüğü için başarısız olabilir çünkü zarf gönderen (envelope sender) adresi değişmiştir. DKIM imzası ise ileti başlıklarıyla birlikte taşındığından ve zarf değil içerik üzerinden doğrulandığından, forward sonrasında da genelde geçerliliğini korumaya devam eder — bu da DKIM'in neden SPF'e göre daha „taşınabilir" bir kanıt olduğunu gösterir.

• SPF: gönderen IP'nin domain adına yetkili olup olmadığını DNS üzerinden kontrol eder
• DKIM: e-postayı kriptografik olarak imzalar, kimlik ve bütünlük kanıtı sağlar
• DMARC: SPF ve DKIM sonuçlarını From alanıyla hizalar, başarısızlık durumunda politika uygular

Birden fazla gönderim aracı kullanıyorsanız DKIM neden karmaşıklaşır

Bir satış ekibi genelde tek bir kanaldan e-posta göndermez: CRM veya soğuk e-posta platformu, Google Workspace/Microsoft 365 üzerinden manuel yazışma, fatura/muhasebe sistemi, destek hattı bildirimleri gibi birkaç araç aynı domain adına e-posta çıkarır. Her aracın kendi imzalama altyapısı olduğundan, her biri için ayrı bir selector ve ayrı bir DKIM anahtarı tanımlanması gerekir — tek bir selector'ı tüm araçlarda paylaşmaya çalışmak genelde çalışmaz çünkü özel anahtar aracın kendi sunucusunda tutulur.

Pratikte en sık karşılaşılan durum şu: ekip CRM için DKIM'i özenle kurar, testleri geçer, sonra birkaç ay sonra yeni bir bildirim aracı veya webinar platformu eklenir ve bu araç için DKIM adımı unutulur. O araçtan giden e-postalar DKIM'siz gider, SPF'e güvenmek zorunda kalır ve SPF'in 10 DNS lookup sınırına yaklaşan bir domain'de bu durum toplam deliverability'yi düşürür.

DKIM kurulum adımları

Kurulum, kullandığınız gönderim aracına göre küçük farklar gösterse de temel akış aynıdır. Aracın panelinde genellikle „domain authentication" veya „DKIM setup" gibi bir bölüm bulunur; bu bölüm size eklemeniz gereken TXT kaydını (selector adı ve açık anahtar değeriyle birlikte) verir.

DNS tarafında bu kaydı doğru host adıyla eklemek kritik önemde: host adı tam olarak selector._domainkey.domaininiz.com biçiminde olmalı, bazı DNS panelleri domain kısmını otomatik ekleyip sadece selector._domainkey yazmanızı ister — bu, panelin dokümantasyonuna göre değişir.

DNS sağlayıcıdan sağlayıcıya küçük ama can sıkıcı farklar olabilir: bazı panellerde TXT değerinin sonuna otomatik bir nokta ekleniyor ve bu değeri bozabiliyor, bazılarında uzun açık anahtar değeri (2048-bit bir anahtar genelde 250 karakteri aşar) tek bir TXT satırına sığmayıp parçalara bölünmesi gerekebiliyor. Bu tür sağlayıcıya özgü davranışları önceden bilmek yerine, kaydı ekledikten sonra mutlaka bir DNS sorgu aracıyla (komut satırında dig veya online bir DNS lookup aracı) kaydın gerçekte ne şekilde yayınlandığını kontrol etmek en güvenli yoldur.

• 1) DNS sağlayıcınıza ve gönderim aracının yönetim paneline erişim sağlayın
• 2) Gönderim aracında DKIM/domain authentication'ı etkinleştirip verilen TXT kaydını kopyalayın
• 3) selector._domainkey.domaininiz.com adresine bu TXT kaydını DNS'e ekleyin
• 4) DNS yayılmasını bekleyin (genelde birkaç dakika, bazı sağlayıcılarda 24-48 saate kadar sürebilir)
• 5) Bir test e-postası gönderip alıcı tarafta header'ı inceleyerek dkim=pass sonucunu doğrulayın
• 6) Aynı adımları domain adına e-posta çıkaran her ayrı araç için tekrarlayın

Sık yapılan hatalar

En yaygın hata, selector adının panel ile DNS arasında birebir eşleşmemesidir — büyük/küçük harf farkı, fazladan nokta veya eksik alt alan adı doğrulamayı anında bozar. İkinci sırada, yalnızca ana gönderim aracında DKIM kurulup diğer araçların (webinar davetleri, fatura bildirimleri, destek e-postaları) açıkta bırakılması gelir; bu araçlardan giden e-postalar hem kendi deliverability'sini düşürür hem de domain itibarını genel olarak zedeleyebilir.

Üçüncü sık hata, eski veya zayıf anahtar uzunluğunun (512-bit gibi) kullanılmaya devam etmesidir; günümüzde 2048-bit anahtar standart kabul edilir ve bazı büyük posta sağlayıcıları zayıf anahtarları güvenilmez sayabilir. Son olarak, e-posta gönderim sırasında içerik bir ara katman (ör. bir güvenlik duvarı, arşivleme aracı veya izleme pikseli ekleyen bir sistem) tarafından değiştirilirse imzalanmış gövde hash'i uyuşmaz ve DKIM başarısız görünür — bu durumda sorun DKIM kurulumunda değil, aradaki değişiklikte aranmalıdır.

• Selector adının panel ile DNS kaydı arasında birebir eşleşmemesi
• Yalnızca bir gönderim aracında DKIM aktif, diğerleri imzasız
• 512-bit gibi zayıf/eski anahtar uzunluğunun kullanılmaya devam etmesi
• İçeriği yolda değiştiren ara katmanlar yüzünden bozulan imza
• DNS TTL değerinin çok uzun tutulup değişikliklerin geç yayılması

Kurulumu nasıl doğrularsınız

DNS kaydını eklemek işin yarısı; kaydın gerçekten doğru okunup okunmadığını test etmeden kurulumu tamamlanmış saymak riskli olur. En basit yöntem, kendinize (ör. kişisel bir Gmail veya Outlook hesabına) bir test e-postası göndermek ve alıcı tarafta e-postanın „orijinalini göster" seçeneğiyle ham başlıkları incelemektir; burada Authentication-Results satırında dkim=pass ve hangi domain/selector için geçtiği görülür.

Komut satırına aşina bir ekip üyesi varsa, dig txt selector._domainkey.domaininiz.com gibi bir sorguyla DKIM kaydının DNS'de tam olarak ne döndürdüğünü doğrudan görebilir; bu, panel arayüzünün gösterdiği değerle DNS'in gerçekte yayınladığı değer arasında bir tutarsızlık olup olmadığını netleştirir. Bu iki yöntemi (uçtan uca test e-postası ve doğrudan DNS sorgusu) birlikte kullanmak, hem imzalamanın hem de yayınlamanın doğru çalıştığını teyit eder.

Adresli B2B gönderimi için checklist

Toplu ESP gönderiminden farklı olarak, hedefli B2B soğuk e-posta genelde birden fazla gönderim hesabı ve aracı üzerinden yürür (ör. birkaç satış temsilcisinin ayrı hesapları, bir CRM'den otomatik dizi gönderimi). Bu yapıda DKIM'i tek seferde kurup unutmak yerine, her yeni hesap veya araç eklendiğinde kısa bir doğrulama adımını sürece dahil etmek gerekir.

Küçük bir ekip için bile bu adımları bir kez yazılı hale getirmek (ör. bir kurulum belgesi veya onboarding checklist'i) zaman içinde büyük fark yaratır: yeni bir satış temsilcisi işe başladığında veya yeni bir gönderim aracı denendiğinde, DKIM adımının atlanmadığından emin olmanın en pratik yolu budur.

• Domain adına e-posta çıkaran her araç için ayrı selector ve ayrı DKIM anahtarı tanımlayın
• 2048-bit anahtar kullanın, mümkünse yılda bir rotasyon planlayın
• DKIM'i her zaman SPF ve DMARC alignment ile birlikte değerlendirin, tek başına yeterli görmeyin
• Yeni bir gönderim hesabı veya aracı devreye alırken test e-postasıyla dkim=pass sonucunu doğrulayın
• DNS değişikliklerinden sonra en az bir hafta boyunca header sonuçlarını takip edin

Sık sorulan sorular