DKIM Kaydı Panele Sığmıyor: TXT 255 Karakter Sınırı Nasıl Aşılır?

Posta sunucunuzda DKIM anahtarını ürettiniz, ekranda uzun bir v=DKIM1; k=rsa; p=MIIBIjANBgkq... satırı duruyor. Bunu kopyalayıp DNS panelinde mail._domainkey adıyla bir TXT kaydına yapıştırıyorsunuz ve "Kaydet" diyorsunuz. İki senaryodan biri gerçekleşiyor: ya panel kırmızı bir uyarı verip "değer çok uzun" diyor ve kaydı almıyor, ya da — daha kötüsü — hiçbir şey söylemeden kaydediyor.

İkinci durum tehlikelidir çünkü panelde her şey yolunda görünür. Kayıt listede durur, yeşil tiki vardır, üstüne tıkladığınızda değer de oradadır. Ama dışarıdan sorguladığınızda değerin bir yerinden kesildiğini görürsünüz. Kesik base64 verisi geçerli bir açık anahtar değildir; alıcı sunucular imzayı çözemez ve gönderdiğiniz her e-posta dkim=permerror ya da "invalid public key" gibi bir sonuçla işaretlenir. DKIM'i kurduğunuzu sanırken aslında hiç kurmamış olursunuz.

Bunun nedeni panelinizin kalitesizliği değil, DNS protokolünün 1987'den beri değişmeyen bir kuralıdır. Bu yazıda o kuralın ne olduğunu, 2048 bit bir anahtarın neden tek parçaya sığmadığını, değeri doğru biçimde nasıl böleceğinizi, panelinizin bunu desteklemediği durumlarda elinizde hangi seçeneklerin kaldığını ve sonucu dig ile nasıl kesin olarak doğrulayacağınızı adım adım ele alacağız.

255 Karakter Sınırı Nereden Geliyor?#

TXT kaydının içeriği tek bir metin bloğu değildir. DNS standardında bir TXT kaydının veri alanı, bir veya daha fazla "character-string" parçasından oluşur. Her parça, başında kendi uzunluğunu tutan tek bir bayt taşır. Tek bir bayt en fazla 255 değerini ifade edebildiği için, bir parça en fazla 255 karakter olabilir.

Buradaki incelik şudur: sınır kaydın tamamına değil, tek bir parçaya aittir. Bir TXT kaydı arka arkaya birden fazla parça taşıyabilir ve toplam uzunluk bu sınırın çok üzerine çıkabilir. Yani 400 karakterlik bir DKIM değeri DNS'te pekâlâ yayınlanabilir; sadece 400 karakteri tek bir parça olarak yazamazsınız, iki parçaya bölmeniz gerekir.

DKIM tarafında da bunun karşılığı tanımlıdır: doğrulayıcı sunucular, TXT kaydındaki parçaları aralarına hiçbir boşluk koymadan birleştirip tek bir değer olarak okumak zorundadır. Yani "v=DKIM1; k=rsa; " ve "p=MIIBIjAN...AB" şeklindeki iki parça, alıcı tarafta otomatik olarak v=DKIM1; k=rsa; p=MIIBIjAN...AB haline gelir. Bölme işlemi yalnızca taşıma katmanını ilgilendirir, anlamı değiştirmez.

TXT kaydının genel yapısını ve diğer kullanım alanlarını hatırlamak isterseniz TXT kaydı nedir yazısı iyi bir başlangıçtır. Burada doğrudan uzun değerlerin yarattığı soruna odaklanıyoruz.

2048 Bit Anahtar Neden Sığmıyor? Rakamlarla#

Sorunun neden 2048 bitte ortaya çıkıp 1024 bitte çıkmadığını anlamak için tek yapmanız gereken karakter saymak. DKIM kaydındaki p= etiketi, RSA açık anahtarının standart ikili biçiminin base64 karşılığını taşır.

Tablodaki "etiketlerle toplam" sütunu, v=DKIM1; h=sha256; k=rsa; p= gibi baştaki etiketlerin de yaklaşık 25-30 karakter yer kapladığını hesaba katar.

Sonuç net: 1024 bit anahtar 255 sınırının rahatça altında kalır, 2048 bit ise sınırı yaklaşık 155 karakter aşar. Uzun yıllar DKIM örneklerinin çoğu 1024 bitle yazıldığı için bu sorun görünmezdi. Günümüzde önerilen ve çoğu sağlayıcının ürettiği varsayılan boyut 2048 bit olduğundan, artık herkes aynı duvara çarpıyor.

Anahtarı kendiniz üretiyorsanız değerin uzunluğunu daha panele gitmeden görebilirsiniz:

# 2048 bit özel anahtar ve karşılığı açık anahtar
openssl genrsa -out dkim.private 2048
openssl rsa -in dkim.private -pubout -out dkim.public

# p= değerini tek satır halinde üret ve uzunluğunu ölç
grep -v '^-----' dkim.public | tr -d '\n' > dkim.b64
wc -c < dkim.b64        # 392 civarında bir sayı görürsünüz

Daha ayrıntılı anahtar işlemleri için OpenSSL komutları yazısına bakabilirsiniz.

Kayıt Sessizce Kesildiğinde Ortaya Çıkan Belirtiler#

Panel bir hata verirse şanslısınız; en azından bir sorun olduğunu biliyorsunuz. Asıl zaman kaybettiren durum kaydın kabul edilip yayında kesik durmasıdır. Bu tabloyu belirti-sebep-çözüm sırasıyla okuyun:

Son satır az bilinen ama gerçek bir sorundur. 2048 bit bir DKIM kaydının yanıtı 500 baytı aşabilir. Modern çözümleyiciler EDNS ile daha büyük UDP yanıtları alabilir; bunu desteklemeyen ya da TCP 53 trafiğini kapatan bir güvenlik duvarı arada varsa, sorgu yarıda kalır. Bu durumda kaydınız "bazen" görünür, hata da rastgele gibi durur. Aşağıdaki komut yanıt boyutunu ve kesilme olup olmadığını gösterir:

# Yanıt boyutu ve TC (truncated) bayrağı
dig +noall +comment +stats TXT mail._domainkey.ornek.com

# UDP tampon boyutunu kısıtlayarak kesilmeyi bilerek tetikleyin
dig +bufsize=512 TXT mail._domainkey.ornek.com | grep -i 'flags\|MSG SIZE'

Doğru Çözüm: Değeri Tırnaklı Parçalara Bölmek#

Standart ve her zaman çalışan çözüm, değeri her biri 255 karakterin altında kalan, tırnak içine alınmış parçalara ayırmaktır. Parçaların nerede bölündüğü tamamen size kalmıştır; alıcı taraf onları boşluksuz birleştireceği için base64 verisinin ortasından bölmek de sorun değildir. Tek kural, hiçbir parçanın 255 karakteri aşmamasıdır.

Zone dosyası biçiminde bu şöyle görünür — parçalar parantez içinde alt alta yazılabilir:

mail._domainkey  IN  TXT  ( "v=DKIM1; h=sha256; k=rsa; "
                            "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1kJ9"
                            "8xQ2mYbF7pR0cVzL4nD6sT3hW5uK1aG7yE2oP9iX0bN4rM8jC"
                            "vH3dS6fA5lU2tQ7wZ1eY9kR0mB4nX8pL6gI3cJ7vD2sF5hT1u"
                            "wQIDAQAB" )

Bu satırları elle yazmak zorunda değilsiniz. OpenDKIM kullanıyorsanız anahtar üreticisi kaydı zaten bölünmüş halde hazırlar:

opendkim-genkey -b 2048 -d ornek.com -s mail -D /etc/opendkim/keys/ornek.com/
cat /etc/opendkim/keys/ornek.com/mail.txt

Çıkan mail.txt dosyasındaki içerik doğrudan zone dosyasına yapıştırılabilecek biçimdedir. Zone dosyası yapısını bilmek burada işinizi kolaylaştırır.

Zone dosyasına doğrudan erişiminiz yoksa ve panel size tek bir metin kutusu veriyorsa, aynı bölmeyi kutunun içinde yapmayı deneyin: parçaları tırnak içine alıp aralarına boşluk koyarak tek satır halinde yazın.

"v=DKIM1; h=sha256; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1kJ9..." "...wQIDAQAB"

Panel bu biçimi anlıyorsa kaydı doğru parçalara ayırarak yayınlar. Anlamıyorsa tırnak işaretlerini değerin bir parçası sanıp harfiyen kaydeder — ki bu da başarısızlıktır ve dig çıktısında hemen fark edilir, çünkü tırnaklar birleşik değerin ortasında görünür.

Değeri programatik olarak bölmek isterseniz:

# p= değerini 200'er karakterlik parçalara ayırıp tırnakla
fold -w 200 dkim.b64 | sed 's/^/"/; s/$/"/' | tr '\n' ' '

Panelinizin Davranışını Nasıl Anlarsınız?#

Sağlayıcılar bu konuda üç farklı davranış gösterir ve hangisine denk geldiğinizi ancak deneyerek anlarsınız. Aşağıdaki tablo yaygın eğilimleri özetler; sürümler arasında fark olabileceği için kaydı yayınladıktan sonra mutlaka doğrulama yapın, panelin ekranda gösterdiği değere güvenmeyin.

Bulut tabanlı büyük DNS servisleri ile Plesk gibi olgun paneller genelde ilk iki gruba girer. Alan adı kayıt firmalarının basit "DNS yönetimi" ekranları ise çoğunlukla tek bir kısa metin alanı sunar ve üçüncü davranışı sergiler. cPanel'in Zone Editor arayüzü sürümüne göre değişkenlik gösterir; sunucuya erişiminiz varsa zone dosyasını WHM üzerinden düzenlemek daha güvenilir bir yoldur. Panelinizde kaydın nerede tutulduğundan emin değilseniz DNS kayıtları hangi panelden değiştirilir yazısı yol gösterir.

Davranışı test etmenin en hızlı yolu, gerçek anahtarınızı beklemeden sahte bir uzun değerle deneme yapmaktır:

# 400 karakterlik bir test değeri üretin, panele yapıştırın, sonra sorgulayın
python3 -c "print('v=TEST1; p=' + 'A'*390)"
dig +short TXT test._domainkey.ornek.com

Dönen değerin uzunluğu girdiğinizle aynıysa paneliniz uzun TXT ile başa çıkabiliyor demektir. Kısaysa, gerçek DKIM kaydınızı oraya koymanın anlamı yok.

Paneliniz Bölmeyi Desteklemiyorsa Üç Seçeneğiniz#

Panel değeri kesiyorsa ve tırnaklı biçimi de anlamıyorsa, elinizde üç yol kalır. Sıralama, tercih edilme sırasıdır.

1. DNS sağlayıcısını değiştirin. En doğru çözüm budur. Alan adının kayıt firmasını değiştirmenize gerek yok; yalnızca nameserver kayıtlarını uzun TXT değerlerini düzgün işleyen bir DNS servisine yöneltmeniz yeterlidir. DKIM tek başına bir sorun gibi görünse de, kesik TXT kaydı yayınlayan bir altyapı ileride DMARC, doğrulama kayıtları ve başka uzun değerlerde de karşınıza çıkacaktır. Nameserver değişikliğinin ardından kayıtların dolaşıma girmesi için propagasyon süresini hesaba katın.

2. Geçici olarak 1024 bit anahtara düşün. 1024 bit anahtar 255 sınırına rahatça sığar ve DKIM'i çalışır hale getirir. Ama bunu kalıcı çözüm saymayın: 1024 bit, günümüz önerilerinin altındadır ve bazı alıcı taraflar zayıf anahtarlara daha düşük güven puanı verebilir. Sağlayıcı değişikliğine kadar köprü olarak kullanın, sonra 2048'e geri dönün.

openssl genrsa -out dkim1024.private 1024
openssl rsa -in dkim1024.private -pubout -out dkim1024.public
grep -v '^-----' dkim1024.public | tr -d '\n' | wc -c    # ~216

3. Ed25519 anahtar kullanın. Ed25519 açık anahtarı yalnızca 44 karakterdir; hiçbir sınıra takılmaz. Ancak doğrulayıcı desteği RSA kadar yaygın değildir. Bu yüzden Ed25519'u RSA'nın yerine değil, ikinci bir seçici olarak yanında yayınlayın; posta sunucunuz her iki imzayı da eklesin. Ed25519'u anlamayan alıcı RSA imzasını doğrular, anlayan ikisini birden görür.

dig ile Birleşik Değeri Okuyup Doğrulama#

Kaydı girdikten sonra iş bitmiş sayılmaz. Doğrulamanın tek güvenilir yolu, kaydı dışarıdan sorgulayıp parçaları birleştirerek okumaktır. dig çıktısında parçalar ayrı ayrı tırnak içinde görünür:

dig +short TXT mail._domainkey.ornek.com
# "v=DKIM1; h=sha256; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..." "...wQIDAQAB"

Parçaları alıcı sunucunun yaptığı gibi boşluksuz birleştirmek için:

# Bitişik parçaları birleştir, tırnakları temizle
dig +short TXT mail._domainkey.ornek.com | sed 's/" "//g; s/"//g'

# Toplam uzunluğu ölç (2048 bit için ~410 beklenir)
dig +short TXT mail._domainkey.ornek.com | sed 's/" "//g; s/"//g' | tr -d '\n' | wc -c

En kesin test ise anahtarın gerçekten ayrıştırılabildiğini görmektir. Yayındaki p= değerini alıp OpenSSL'e verin; kesikse "unable to load Public Key" hatası alırsınız, sağlamsa anahtar bilgilerini basar:

dig +short TXT mail._domainkey.ornek.com | sed 's/" "//g; s/"//g' \
  | grep -o 'p=[A-Za-z0-9+/=]*' | cut -d= -f2- > yayindaki.b64

{ echo "-----BEGIN PUBLIC KEY-----"; fold -w 64 yayindaki.b64; \
  echo "-----END PUBLIC KEY-----"; } > yayindaki.pem

openssl rsa -pubin -in yayindaki.pem -noout -text | head -3
# "Public-Key: (2048 bit)" görüyorsanız kayıt sağlamdır

Bu üç komutu çalıştırıp temiz sonuç aldıysanız, DNS tarafı bitmiştir. dig seçeneklerini ve alternatif sorgulama yollarını derinleştirmek isterseniz dig ve nslookup ile DNS sorgulama yazısına göz atın.

Yayına Aldıktan Sonra Uçtan Uca Test#

DNS'te doğru duran bir anahtar, imzanın da doğru üretildiği anlamına gelmez. Son adım gerçek bir e-posta göndermektir.

1. Sunucu tarafındaki seçiciyi teyit edin. Posta sunucunuzun imzalarken kullandığı seçici adı ile DNS'teki kayıt adı birebir aynı olmalıdır. mail._domainkey yayınlayıp sunucuda default seçicisini kullanmak, en sık yapılan ve en çok zaman kaybettiren hatadır.
2. Kendinize bir dış adrese e-posta gönderin. Ardından iletinin ham kaynağını açın ve Authentication-Results satırını okuyun. dkim=pass ifadesinin yanında header.d= alanının kendi alan adınızı gösterdiğinden emin olun.
3. DKIM-Signature başlığındaki s= değerini kontrol edin. Bu değer, sorguladığınız kaydın seçicisiyle aynı olmalıdır.
4. Yeni anahtara geçerken eskisini hemen silmeyin. Anahtar değiştirdiğinizde yolda olan iletiler hâlâ eski anahtarla imzalanmış olabilir. Eski seçicinin kaydını birkaç gün yayında bırakın, sonra kaldırın.
5. SPF ve DMARC ile birlikte değerlendirin. DKIM tek başına yeterli bir kimlik doğrulama katmanı değildir; üçünün nasıl birlikte çalıştığını SPF, DKIM ve DMARC yazısında bulabilirsiniz.

Özetle: 255 karakter kuralı bir hata değil, protokolün tasarımıdır ve doğru cevabı da protokolün kendisi verir — değeri parçalara bölün. Paneliniz buna izin vermiyorsa sorun anahtarınızda değil altyapınızdadır; anahtarı zayıflatmak yerine altyapıyı değiştirmek uzun vadede her zaman daha ucuza gelir.

Sıkça Sorulan Sorular#

DKIM kaydını bölmek imzanın doğrulanmasını etkiler mi?#

Hayır. Doğrulayıcı sunucular TXT kaydındaki parçaları aralarına boşluk koymadan birleştirip tek bir değer olarak okumak zorundadır; bu davranış DKIM standardında açıkça tanımlıdır. Parçaların kaç tane olduğu, nerelerden bölündüğü ve uzunlukları sonucu değiştirmez. Tek kural, hiçbir parçanın 255 karakteri aşmamasıdır.

Kaydı bölerken base64 verisinin ortasından kesmem sakıncalı mı?#

Sakıncası yoktur. Parçalar birleştirildikten sonra base64 çözülür, yani bölme noktası anlam taşımaz. İstediğiniz karakterde bölebilirsiniz. Tek dikkat edilmesi gereken, parçaları birleştirirken araya boşluk veya satır sonu karakteri karışmamasıdır; bu yüzden metin düzenleyicide otomatik satır kaydırmanın gerçek bir satır sonu eklemediğinden emin olun.

Panelim uzun değeri kabul etti ama DKIM yine çalışmıyor, sırada ne var?#

Önce kaydı dışarıdan sorgulayıp yayındaki değerin uzunluğunu ölçün; kesilmişse sorun paneldedir. Değer tamsa seçici adına bakın: posta sunucunuzun imzada kullandığı seçici ile DNS'teki kayıt adının aynı olması gerekir. İkisi de doğruysa sorun büyük olasılıkla gövde imzasıyla ilgilidir, yani anahtardan bağımsız bir konudur.

1024 bit anahtar kullanmak güvenli mi?#

Çalışır ve alıcılar tarafından kabul edilir, ancak günümüzde önerilen boyut 2048 bittir. 1024 bit anahtarı yalnızca DNS altyapınızı düzeltene kadar geçici bir köprü olarak kullanın. Kalıcı olarak bırakırsanız, hem kriptografik olarak zayıf kalırsınız hem de bazı alıcı sistemlerin itibar değerlendirmesinde dezavantaj yaşayabilirsiniz.

DKIM kaydı için TTL değerini kaç yapmalıyım?#

Kaydı ilk kurarken veya değiştirirken 300 saniye gibi kısa bir değer kullanmak, yaptığınız düzeltmelerin hızlı yayılmasını sağlar. Kayıt oturduktan ve doğrulamayı geçtikten sonra 3600 veya daha uzun bir değere çıkarabilirsiniz. Anahtar değişimi planlıyorsanız, değişimden birkaç gün önce TTL'i tekrar düşürmek geçişi sorunsuz kılar.

Aynı alan adında birden fazla DKIM anahtarı yayınlayabilir miyim?#

Evet ve bu oldukça yaygındır. Her anahtar farklı bir seçici altında yayınlanır; örneğin kendi posta sunucunuz için bir seçici, pazarlama e-postası gönderen bir servis için başka bir seçici. Alıcı, iletinin imza başlığındaki seçici adına bakarak doğru kaydı sorgular. Bu yapı sayesinde anahtar değişimini de kesintisiz yapabilirsiniz: yeni seçiciyi yayınlar, geçişi tamamlar, sonra eskisini kaldırırsınız.