DKIM kaydı nedir, nasıl oluşturulur ve neden "permerror" verir?

DKIM, gönderdiğiniz her iletinin başlığına alan adınızın özel anahtarıyla atılmış bir imza ekler. Alıcı sunucu bu imzayı DNS'te yayımladığınız genel anahtarla doğrular. Doğrulama geçerse iki şey kanıtlanmış olur: ileti gerçekten sizin yetkilendirdiğiniz bir sunucudan çıktı ve yolda değiştirilmedi. SPF'nin aksine DKIM, iletinin başka bir sunucu üzerinden aktarılmasından etkilenmez; bu yüzden DMARC'ın en güvenilir dayanağıdır.

Kayıt nerede durur: seçici ve _domainkey

Bir DKIM kaydı alan adının köküne değil, şu biçimde bir alt ada yazılır:

seçici._domainkey.alanadiniz.com   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Seçici (selector), aynı alan adında birden çok anahtar tutabilmenizi sağlayan etikettir. Her gönderen servis kendi seçicisini kullanır: e-posta sunucunuz bir, bülten aracınız başka bir seçiciyle imzalar. Hangi seçicinin kullanıldığını görmek için gelen bir iletinin başlığında DKIM-Signature satırına bakın; d= alan adını, s= seçiciyi verir. Kaydı sorgulamak için seçiciyi bilmeniz şarttır; DNS'te "bu alan adının tüm DKIM kayıtlarını listele" diye bir sorgu yoktur.

Kayıttaki üç alan şunlardır: v=DKIM1 sürüm, k=rsa anahtar türü, p= ise genel anahtarın kendisidir.

Anahtarı üretmek ve yayımlamak

Barındırma panelleri ve e-posta servisleri anahtarı sizin yerinize üretir ve yayımlanacak kaydı gösterir; çoğu durumda yapmanız gereken, gösterilen kaydı DNS'inize eklemektir. Kendi posta sunucunuzu çalıştırıyorsanız anahtarı kendiniz üretirsiniz. Ubuntu'da opendkim-tools paketiyle bunu bir deneme sunucusunda yaptık:

opendkim-genkey -b 2048 -d ornek.com -s mail2026
ls
mail2026.private  mail2026.txt

mail2026.private imzalamada kullanılan özel anahtardır ve sunucudan hiç çıkmamalıdır. mail2026.txt ise DNS'e yazılacak kayıttır. Dosyanın içeriği şöyle başlar:

mail2026._domainkey  IN  TXT  ( "v=DKIM1; h=sha256; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApRuW/H/yctl..." ... )

255 karakter sınırı

DNS'te tek bir TXT metin parçası en fazla 255 karakter olabilir. Ürettiğimiz 2048 bitlik anahtarla kaydın tamamı 420 karakter tuttu; yani en az iki parçaya bölünmesi gerekir. Yukarıdaki dosya bunu tırnaklı parçalarla zaten yapıyor. Alıcı sunucular parçaları aradaki boşluk olmadan birleştirir. Panelinize kaydı tek satır olarak yapıştırdığınızda panel bölmeyi kendisi yapabilir, kaydı kesebilir ya da hata verebilir; hangisini yaptığını öğrenmenin tek yolu eklemeden sonra sorgulamaktır.

1024 bitlik anahtarlar tek parçaya sığar ve bu yüzden hâlâ önerilir görünür; ama artık zayıf kabul edilirler. 2048 bit kullanın ve bölme işini doğru yapın.

Sorgulamak: kayıt yayında mı, doğru mu?

dig +short TXT mail2026._domainkey.ornek.com

Cevap birden fazla tırnaklı parça olarak gelebilir; bu normaldir. Büyük sağlayıcıların kayıtlarına bakmak, karşılaşabileceğiniz durumları gösterir. 17 Ekim 2026'daki sorgularımızda:

• Var olmayan bir seçici sorulduğunda cevap status: NXDOMAIN oldu. Seçiciyi yanlış yazdıysanız ya da kayıt hiç eklenmediyse göreceğiniz budur.
• Gmail'in 20230601 seçicisi "v=DKIM1; k=rsa; p=" döndürdü. Boş p= bir hata değil, anahtarın bilerek iptal edildiğini gösterir: bu seçiciyle imzalanmış iletiler artık doğrulanmaz.
• Microsoft'un selector1 kaydı bir TXT değil, başka bir ada yönlenen CNAME çıktı. Microsoft 365 gibi servisler anahtarı kendi altyapılarında tutar ve siz alan adınıza yalnız CNAME eklersiniz; böylece anahtarı onlar sizin müdahaleniz olmadan döndürebilir.

Kaydı komut satırı olmadan denetlemek için SPF, DKIM ve DMARC kontrolü aracına alan adınızı ve seçiciyi girebilirsiniz.

"dkim=fail" ve "permerror": sebebe göre çözüm

Alıcının verdiği sonuç iletinin başlığındaki Authentication-Results satırında yazar. Üç olumsuz sonuç farklı şeyler söyler:

• dkim=none — ileti hiç imzalanmamış. Gönderen sunucu ya da servis DKIM imzalamak üzere yapılandırılmamış.
• dkim=permerror — kayıt bulundu ama kullanılamadı. En sık sebepler: kayıt bölünürken kesilmiş ya da parçaların arasına fazladan karakter girmiş, p= değeri bozuk, kayıtta tırnak ve noktalı virgül karışmış, ya da seçici yanlış alt ada yazılmış. Kaydı sorgulayıp parçaları birleştirdiğinizde anahtarın panelin ürettiği değerle karakteri karakterine aynı olup olmadığına bakın.
• dkim=fail — anahtar bulundu, imza tutmadı. Kayıt doğru olabilir; ileti imzalandıktan sonra değişmiştir. Altbilgi ekleyen posta listeleri, ileti gövdesini yeniden yazan güvenlik ağ geçitleri ve konu satırına etiket ekleyen sistemler bunun klasik sebepleridir. Bir diğer sebep, sunucuda yeni anahtar yerine eski özel anahtarın kalmasıdır.

İmzayı okumak: DKIM-Signature başlığındaki alanlar

Gönderdiğiniz bir iletiyi kendi posta kutunuza yollayıp başlıklarını açtığınızda (Gmail'de "Orijinali göster") şuna benzer bir satır görürsünüz:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ornek.com; s=mail2026;
    h=from:to:subject:date:message-id; bh=2jUSOH9N...; b=dzdVyOfAKCdL...

Teşhiste işe yarayan alanlar şunlardır:

• d= imzalayan alan adı. DMARC hizalaması bu değere bakar; bülten aracınızın alan adını görüyorsanız imza sizin adınıza atılmıyordur.
• s= seçici. Alıcı anahtarı s ve d değerlerini birleştirerek bulur; kaydı sorgularken kullanacağınız ad budur.
• h= imzaya dahil edilen başlıklar. Burada sayılan bir başlık yolda değişirse imza tutmaz. Konu satırına etiket ekleyen sistemler bu yüzden dkim=fail üretir.
• bh= ileti gövdesinin özeti. Gövdeye eklenen tek bir altbilgi satırı bu değeri bozar.
• c= kanonikleştirme. relaxed, boşluk ve satır sonu farklarını tolere eder; simple hiçbir değişikliğe izin vermez. Yolda sık değiştirilen iletilerde relaxed/relaxed daha dayanıklıdır.

Bir iletide birden çok DKIM-Signature satırı bulunabilir: biri sizin alan adınızla, biri gönderim servisinin kendi alan adıyla. Alıcı tarafındaki Authentication-Results satırı her imzanın sonucunu ayrı yazar. DMARC için bunlardan en az birinin geçmesi ve From adresinizle hizalı olması yeterlidir; bu yüzden tüm satırlara değil, kendi alan adınızla atılan imzanın sonucuna bakın.

Birden çok gönderici, birden çok seçici

Kurumsal e-posta, bülten aracı, fatura sistemi ve destek yazılımı aynı alan adıyla gönderiyorsa her birinin kendi seçicisi olmalıdır. Aynı anahtarı birden çok servise vermek, birinde anahtar sızdığında hepsini aynı anda değiştirmek zorunda kalmak demektir. Hangi servisin hangi seçiciyi kullandığını bir listede tutun; bir servisi bıraktığınızda onun kaydını da silin.

Ne sıklıkla döndürmeli?

Tek bir doğru aralık yoktur, ama üç durum döndürmeyi zorunlu kılar: özel anahtarın bulunduğu sunucuya yetkisiz erişim şüphesi, anahtara erişimi olan bir çalışanın ya da hizmet sağlayıcının ayrılması ve hâlâ 1024 bitlik anahtar kullanıyor olmak. Bunların dışında yılda bir döndürmek makul bir alışkanlıktır; seçici adına yılı yazmak (mail2026, mail2027) hangi anahtarın ne zaman devreye girdiğini kayıtlara bakmadan gösterir. Döndürmeyi takvime bağlamanın asıl faydası, işlemin acil bir gecede değil, sakin bir günde ve adımları bilinen bir prova olarak yapılmasıdır.

Anahtar döndürme

Özel anahtar sızarsa ya da uzun yıllar aynı anahtar kullanıldıysa yenisine geçmek gerekir. Seçici yapısı bunu kesintisiz yapmayı sağlar:

1. Yeni bir seçiciyle (ör. mail2027) yeni anahtar çifti üretin ve genel anahtarı DNS'e ekleyin. Eski kayıt yerinde kalsın.
2. Yeni kaydın yayıldığını sorgulayarak doğrulayın.
3. Posta sunucusunu yeni seçici ve özel anahtarla imzalamaya geçirin.
4. Yolda olan ve sonradan doğrulanacak iletiler için eski kaydı birkaç gün bırakın; ardından p= değerini boşaltarak iptal edin ve en sonunda silin.

SPF ve DMARC ile birlikte nasıl çalıştığını görmek için e-posta teslimatı rehberine bakın. Üç kayıt birlikte doğru kurulduğunda iletilerinizin istenmeyen klasörüne düşmesinin en büyük teknik sebebi ortadan kalkar.

Sık sorulan sorular