1024 mü 2048 mi: DKIM anahtar uzunluğu ve 255 karakterlik TXT duvarını doğru aşmak
DKIM'i çökerten şey anahtar uzunluğu değil, 2048 bit RSA anahtarının base64 halinin DNS TXT'in 255 karakterlik sınırını aşıp yarım yayınlanmasıdır. Anahtar seçimi, doğru bölme, sağlayıcı farkları ve Ed25519 ile bu duvarı tamamen kaldırmak.
EvilMail Team17 Temmuz 202611 dk okuma
opendkim-testkey yeşil dönüyor, sunucuda her şey yolunda görünüyor, ama Gmail'in "Show original" ekranında hâlâ dkim=neutral (bad format) yazıyor. Bu senaryoyu evilmail.pro tarafında onlarca kez gördük ve neredeyse her seferinde sebep aynıydı: 2048 bitlik RSA anahtarının TXT kaydı 255. karakterde kesilmiş, ikinci parça ya hiç yayınlanmamış ya da yanlış tırnaklanmıştı. Anahtar "çok küçük" değildi; DNS'te yarım duruyordu.
İşin sinir bozucu yanı şu: "her zaman 2048 bit kullan" tavsiyesi bu tuzağı büsbütün görünmez kılıyor. DKIM'i pratikte çökerten şey anahtar uzunluğunun kendisi değil, uzun public anahtarın DNS TXT kaydının fiziksel sınırına çarpmasıdır. Önce doğru boyutu nasıl seçeceğinizi, sonra 255 karakter duvarını nasıl aşacağınızı, en sonunda da bu duvarı kökten nasıl kaldıracağınızı görelim.
1024 mü 2048 mi: tehdit modeli ve gerçek maliyet
RFC 6376, DKIM için 1024–2048 bit RSA aralığını önerir. RFC 8301 işi netleştirir: 1024 bitin altını yasaklar ve SHA-1'i devre dışı bırakır. 512 bit zaten tarihe karıştı; 2012'de Google'ın 512 bitlik selector'ü bir hafta sonu sıradan bir laptopta faktörlendiğinde bu tartışma kapanmıştı. Taban çizgisi bugün net: 1024 bit alt sınır, altı kabul edilemez.
Peki 2048'in maliyeti nedir? Alıcı tarafta imza doğrulama farkı ölçülebilir ama ihmal edilebilir; bir mesajın RSA-2048 imzasını doğrulamak mikrosaniyeler meselesidir ve alıcı MTA'yı zorlamaz. Asıl maliyet kriptografik değil,
DKIM Anahtar Uzunluğu: 1024 vs 2048 ve TXT Split String Sorunu — EvilMail Blog
operasyoneldir
: 2048 bitlik public anahtar DNS'te tek bir TXT string'ine sığmaz ve bütün yayın karmaşıklığı buradan doğar.
Karar verirken anahtar rotasyonunu da hesaba katın. Selector'ünüzü 6-12 ayda bir döndürüyorsanız (mail2025q1, mail2025q3 gibi), her anahtarın maruz kalma penceresi dar kalır ve 1024 bitin teorik kırılma riski pratik bir tehdit olmaktan çıkar. Buna karşılık statik, uzun ömürlü tek bir selector kullanıyorsanız — ki kurumsal ortamlarda sık görülür — anahtar yıllarca sabit kaldığından 2048 bit lüks değil, zorunluluktur.
Pratik özet:
Yüksek hacimli transactional + düzenli selector rotasyonu: 1024 bit kabul edilebilir; tek string olduğu için split derdi de yoktur.
Kurumsal, uzun ömürlü selector, uyumluluk baskısı (BIMI, denetim): 2048 bit; böl ve doğrula.
Yeni kurulum ve DNS'e hâkimsen: doğrudan Ed25519 (aşağıda), ya da en dayanıklısı olarak RSA-2048 + Ed25519 çift imzalama.
255 karakter duvarı: DNS TXT neden bölünür
Bütün mesele RFC 1035'teki tek bir tanımda saklı. DNS'te bir TXT kaydı bir veya birden fazla character-string'den oluşur ve tek bir character-string en fazla 255 oktet taşıyabilir. Bu bir öneri değil, protokol limiti. Bir TXT kaydı birden çok string tutabilir; resolver bunları alıcıya teslim ederken aralarına hiçbir şey koymadan, uç uca birleştirir. DKIM doğrulaması tam olarak bu birleştirilmiş sonuca güvenir.
Anahtar boyutlarını base64 p= uzunluğu cinsinden koyalım — sınırın tam nereden geçtiği burada görünür:
1024 bit RSA → base64 public anahtar ≈ 216 karakter → tek string'e sığar, sorun yok.
2048 bit RSA → ≈ 392 karakter → tek string'e SIĞMAZ, en az 2 parçaya bölünmek ZORUNDA.
4096 bit RSA → ≈ 736 karakter → 3+ parça; kazandırdığı yok, tavsiye etmiyoruz.
Ed25519 → ≈ 44 karakter → her zaman tek string.
Duvar tam da 1024 ile 2048 arasında. "2048'e geç" tavsiyesinin sakladığı şey işte bu: geçtiğiniz anda kaydınız ilk kez bölünmek zorunda kalır ve çoğu insanın ilk kez hata yaptığı yer de burasıdır.
En yaygın yanlış anlama: parçaları \n ile ya da araya boşluk koyarak ayırmak. Resolver stringleri uç uca birleştirdiği için, araya giren her karakter base64'ü bozar ve doğrulama signature verification failed ya da bad format ile düşer. Parçalar mantıksal olarak ayrı durur ama içerik olarak kesintisiz tek bir base64 dizisi oluşturmalıdır.
Anahtarı üret ve TXT'yi doğru böl
opendkim-genkey en pratik yol; hem .private hem yayınlanacak .txt dosyasını üretir:
mail.txt içeriği zaten çok parçalı ve tırnaklı gelir; anatomisi şudur:
text
mail._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF"
"AAOCAQ8AMIIBCgKCAQEA... (255. karaktere kadar ilk parça)"
"...geri kalan base64 ve son == dolgusu" ) ; ----- DKIM key mail
Parantez, BIND'in çok satırlı kayıt sözdizimidir; parçalar ayrı ayrı tırnaklanmıştır ama içerik olarak kesintisizdir. Anahtarı openssl ile elle ürettiyseniz base64'ü tek satıra çıkarıp 255'lik parçalara siz bölmelisiniz:
bash
# 2048 bit anahtar üret ve public kısmın base64'ünü tek satır al
openssl genrsa -out mail.private 2048
openssl rsa -in mail.private -pubout -outform der 2>/dev/null \
| openssl base64 -A > pubkey.b64
# 255'lik parçalara kır ve her parçayı tırnak içine al
fold -w 255 pubkey.b64 | sed 's/.*/"&"/'
Bu son komutun çıktısını doğrudan zone dosyanıza p= değeri olarak yapıştırırsınız. Ed25519 tarafında bu uğraş hiç yok, çünkü kayıt tek string:
text
eddsa._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
Sağlayıcıya göre davranış: asıl saha kısmı
Aynı 2048 bitlik anahtar, hangi DNS paneline girdiğinize göre bambaşka davranır. Varsaymayın, doğrulayın.
Cloudflare (dashboard): 392 karakterlik değeri tek parça yapıştırabilirsiniz; arayüz kabul eder ve yayınlarken 255'lik stringlere kendisi böler. Ama Terraform veya API kullanıyorsanız bu otomatik değildir — value alanına "parça1" "parça2" biçiminde tırnakları elle koymalısınız, yoksa 392'lik tek string reddedilir.
Route53:ResourceRecords içinde her string ayrı bir tırnaklı eleman olmak zorunda. AWS 255 sınırını sizin yerinize halletmez; JSON'da [{"Value": "\"parça1\" \"parça2\""}] gibi elle bölersiniz.
BIND / PowerDNS: BIND parantezli çok satır sözdizimini destekler. evilmail altyapısının dayandığı PowerDNS'te ise content alanına çok stringli TXT yazarsınız; parçaları tırnakla ayırıp aradaki boşluğa dikkat edin. PowerDNS parçaları protokole uygun biçimde uç uca yayınlar.
cPanel / Plesk: Asıl tuzak burada. Bazı sürümler 255 karakterden uzun değeri sessizce kesip kalanını çöpe atar, hata bile vermez. Sahada gördüğümüz "yarım anahtar" arızalarının açık ara en büyük kaynağı budur. Bu panellerde girişten sonra ham çıktıyı mutlaka dig ile kontrol edin.
Doğrulama ve hata ayıklama
Yayınladıktan sonra sunucuya değil, resolver'a sorun. Ham TXT çıktısını görün:
bash
dig +short TXT mail._domainkey.example.com
# İki ayrı tırnaklı eleman görmek NORMALDİR — resolver bunları
# birleştirir. Asıl kontrol: panelin İKİSİNİ de yayınladığından emin ol.
İki tırnaklı parça görmeniz sorun değil; endişelenmeniz gereken şey ikinci parçanın hiç görünmemesi ya da arada boşlukla birleşmiş olmasıdır. Sonra anahtarı eşleştirin:
bash
opendkim-testkey -d example.com -s mail -vvv
# beklenen: "key OK"
Son olarak gerçek bir mesajı Gmail'e atıp "Show original" ile DKIM: 'PASS' görün, ya da mail-tester üzerinden puanlayın. Alıcıda dkim=neutral (bad format) görüyorsanız neredeyse kesinlikle split bozuktur.
Sık karşılaşılan hata imzaları ve gerçek anlamları:
`public key too small` → anahtar 1024'ün altında ya da p= parse edilemiyor (çoğu zaman bozuk split bunu tetikler).
`signature verification failed` → body hash uyuşmuyor ya da p= içeriği bozulmuş (araya kaçan boşluk/\n).
`key not found` → selector ya da domain adı yanlış; mail._domainkey yerine hatalı selector.
Kayan `==` dolgusu → ikinci parçanın sonundaki base64 padding'i eksik ya da fazla kopyalanmış.
Ed25519 ile duvarı tamamen kaldırın (2026 yaklaşımı)
RFC 8463, DKIM'e Ed25519'u getirdi: k=ed25519 ve yalnızca 44 karakterlik p=. Tek string, sıfır split derdi, minik kayıt. 2048 bitlik RSA'nın bütün DNS acısı buharlaşır. Anahtar üretimi de basit:
Tek gerçekçi engel uyumluluk: hâlâ Ed25519 doğrulamayan alıcılar var ve bunlar imzayı reddetmeden neutral geçebilir. Çözüm ikisini birden kullanmak — çift imzalama (dual-signing). İki ayrı selector tanımlayıp mesajı hem RSA-2048 hem Ed25519 ile imzalarsınız:
text
mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=..." ; 2 parça
eddsa._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=..." ; tek string
OpenDKIM tarafında SigningTable içinde her iki selector'ü de tanımlarsınız; modern alıcılar Ed25519'u doğrular, eski olanlar RSA'ya düşer. 2026 için en dayanıklı kurulum budur: hem geleceğe hazır hem geriye dönük güvenli.
Dağıtımdan önce hızlı kontrol listesi
Parça sayısı: 2048 bit için TXT en az 2 string mi? Ed25519 için tek string mi?
Tırnaklama: Her parça ayrı tırnak içinde ve aralarında görünür karakter yok mu?
Resolver testi:dig +short TXT selector._domainkey.example.com ikinci parçayı da döndürüyor mu?
