DKIM "İmza için Anahtar Yok": Seçici ve Döngü Düzeltmeleri (2026)

Yayımlanma 2026-07-08

Veriler: 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan adı üzerinde toplam sayım verileri. Bkz. nasıl derecelendiriyoruz.

“No key for signature” hatası, alıcının DKIM imzanızın işaret ettiği DNS kaydını — selector._domainkey.yourdomain — sorguladığı ve anahtar bulamadığı anlamına gelir: hiç yayınlanmadı ya da bir döngü sırasında silindi. İmzalayanın gerçekten kullandığı seçiciyi yayınlayın. Defaults.Exposed”ın 261,086,232 derecelendirilmiş alan adı sayımına göre yalnızca 10,092,481 alan adı — %3.87 — SPF+DKIM+DMARC üçlüsünü tamamlıyor.

Düzeltme tek bir DNS kaydıdır ve tek bir başlıkta bulunur. Postanızın hangi seçiciyle imzalandığını öğrenmek için gerçek bir DKIM-Signature başlığından s= ve d= etiketlerini okuyun, tam o kaydı yayınlayın (veya onarın) ve sağlayıcının sizin için anahtarları döndürmesi için CNAME delegasyonunu tercih edin. Ardından aşağıdaki talimatla döngü yapın — bu hata genellikle birinin eski seçiciyi çok erken sildiği anlamına gelir.

”dkim no key for signature” ne anlama gelir?

Her DKIM imzası, alıcıya ortak anahtarı nereden getireceğini söyleyen iki etiket taşır: d= (imzalama alanı) ve s= (seçici). Alıcı, bunlardan oluşturulan tek bir DNS adını sorgular — s._domainkey.d — anahtar için. “No key for signature” bu sorgunun boş döndüğü anlamına gelir: imza mevcut ama adlandırdığı anahtar değil.

İfade, Authentication-Results başlıklarında ve DMARC toplu raporlarında görünür — tam ifade alıcıya göre değişir, ancak iki varyant önemlidir:

Sonuç dizesi (parça, yaygın olarak gözlemlendiği şekliyle)	Gerçekte ne oldu	Geçici mi?
`dkim=temperror (no key for signature)`	DNS sorgusu başarısız oldu veya zaman aşımına uğradı — alıcı yanıt alamadı	Evet — yeniden denemeler genellikle geçer; yalnızca kalıcıysa araştırın
`dkim=permerror (no key for signature)`	DNS sorgusu başarılı oldu ve yanıt “böyle bir kayıt yok” idi — seçici gerçekten eksik	Hayır — kaydı yayınlayana kadar kayıt eksik

Tek seferlik bir temperror DNS gürültüsüdür. Birkaç gün ve alıcı boyunca tekrarlanan bir permerror — ya da temperror — imzanın işaret ettiği kaydın bölgenizde olmadığı anlamına gelir. Bu bu kılavuzdur.

Sonuç: doğrulanamaz bir imza hiç DKIM yokmuş gibi sayılır, dolayısıyla DMARC yalnızca SPF”ye geri döner — ve SPF iletimde bozulur. İmza eksik değil geçersizse (gövde karması, bozulmuş anahtar), bu farklı bir başarısızlıktır — bkz. “DKIM imzası geçerli değil”.

Postamın hangi seçiciyle imzalandığını nasıl bulurum?

Sağlayıcının belgelerinden tahmin etmeyin — gerçek bir mesajdan okuyun:

Etkilenen sistemden kontrol ettiğiniz bir posta kutusuna mesaj gönderin (Gmail adresi iyi çalışır).
Ham kaynağı açın (Gmail”de “Orijinali göster”, Outlook”ta “İleti kaynağını görüntüle”).
DKIM-Signature: başlığını bulun ve iki etiketi okuyun: s= seçicidir, d= imzalama alanıdır. Açıklayıcı bir örnek: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Alıcının sorguladığı kayıt s._domainkey.d”dir — burada, mail2026._domainkey.yourdomain.com. Kendiniz kontrol edin: dig TXT mail2026._domainkey.yourdomain.com +short. Boş yanıt = hata her alıcı için gerçektir.
Her gönderme sistemi için tekrarlayın. Bir mesaj birden fazla DKIM imzası taşıyabilir — posta kutusu sağlayıcısı, bülten aracı, yardım masası — her birinin kendi s=/d= çifti ve kaydı vardır. Başarısız olanı düzeltin ve d=”sine dikkat edin: yalnızca d=”si From alanınızla eşleşen bir imza DMARC”a yardımcı olur.

Seçici kaydı neden eksik?

Neredeyse tüm bu hataları dört neden açıklar — bunları şu sırayla kontrol edin:

Hiç yayınlanmadı. İmzalayıcı, kimsenin DNS”e eklemediği bir seçiciyle açıldı (veya varsayılan olarak açık). Yeni araçlar ve beklenmedik şekilde imzalayan ağ geçitleriyle yaygındır.
Döngü sırasında silindi. Birisi eski seçiciyi hâlâ iletimde, yeniden deneme kuyruğunda veya yönlendirme beklerken olan mesajlar imzalıyken “temizledi”. Bu postaların zaten imzalı olduğu s=old şeklindedir; old._domainkey silinmesi bu mesajların her birini geriye dönük olarak bozar.
DNS arayüzünüz bir CNAME hedefini bozdu. Pek çok sağlayıcı CNAME aracılığıyla delegasyon yapar (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com) ve pek çok DNS paneli hedefe bölgenizi sessizce ekler — s1.domainkey.u123.esp.com.yourdomain.com saklayarak, hiçbir şeye çözümlenmez. Hedefi doğrulayın: dig CNAME s1._domainkey.yourdomain.com +short. Aynı tuzak araç geçişleri sırasında da ısırır — bkz. e-posta araçlarını değiştirdikten sonra DKIM başarısız oluyor.
Sağlayıcı döndürdü, bölgeniz döndürmedi. CNAME”leri yerine statik TXT kaydı olarak yapıştırılan bir sağlayıcı anahtarı, zamanlanmış döngüsü tarafından sahipsiz bırakılır — imzalayıcı hiç yayınlamadığınız bir seçiciye geçer. Sayımdaki 261 milyon alan adından yalnızca %51.84 tarama anında keşfedilebilir bir DKIM anahtarı sunuyor (veriler: 2026-06-29 itibarıyla).

”No key for signature” nasıl düzeltilir?

DNS”e dokunmadan önce defaults.exposed üzerinde ücretsiz taramayı çalıştırın. Canlı DKIM, SPF ve DMARC kayıtlarınızı okur ve alıcıların gerçekte gördüklerini gösterir — seçicinin çözümlenip çözümlenmediğini ve bir CNAME hedefinin bozulup bozulmadığını dahil ederek.
İmzalayanın gerçekten kullandığı seçiciyi yayınlayın — başlıktaki s= değerini, eski bir talimatnameden değil. Sağlayıcınızın yönetici konsolundan kaydı alın (Google Workspace DKIM kurulumu · Microsoft 365 DKIM kurulumu) ve tam olarak s._domainkey.yourdomain.com adresine ekleyin.
TXT anahtarını yapıştırmak yerine CNAME delegasyonunu tercih edin. Sağlayıcınız DKIM CNAME”leri sunuyorsa bunları kullanın: anahtar kendi bölgelerinde yaşar, dolayısıyla siz DNS”e bir daha dokunmadan döndürürler — neden 4 imkânsız olur. Bülten platformlarının neredeyse tamamı bu şekilde çalışır; bkz. Mailchimp/Brevo/Klaviyo e-postaları DMARC”da başarısız oluyor.
Panelinizin dışından doğrulayın. Ağınızın dışındaki bir makineden dig TXT s._domainkey.yourdomain.com +short (ya da delegeli seçiciler için dig CNAME …). Panel kaydı gösteriyor olması, bölge başka bir şey sunuyorsa hiçbir şey kanıtlamaz.
Yeniden tarayın ve test mesajını yeniden gönderin. Authentication-Results artık dkim=pass okumalıdır. Ardından DKIM”i düzeltin sayfasında taramanın işaretlediği diğer her şeyi çözün — From alanınızla hizalanmayan geçen bir imza hâlâ DMARC”ta başarısız olur.

DKIM anahtarlarını bu hataya neden olmadan nasıl döndürürüm?

Döngü, çalışan kurulumların bozulduğu yerdir. Bunu önleyen kural: bir seçici yalnızca onunla imzalanmış son mesaj boşaldıktan sonra silinir — asla geçişte. İmzalı posta düşündüğünüzden daha uzun yaşar: yeniden deneme kuyrukları günlerce çalışır ve yönlendirilen mesajlar her hareket ettiklerinde yeniden doğrulanır.

Adım	Eylem	Sonraki adıma geçmeden önce kapı
1. Ekle	Yeni seçiciyi eskisinin yanına yayınlayın (`s2._domainkey…`)	`dig` dışarıdan çözümlendiğini onaylar
2. Geç	İmzalayanı yeni seçiciye yönlendirin	Test mesajı `s=s2` ve `dkim=pass` gösteriyor
3. Bekle	Uçuştaki, kuyruktaki ve yönlendirilen trafik boşalırken eski seçiciyi yayında bırakın	≥ 7 gün; eski seçici raporlarda görünmeyene kadar DMARC toplu raporlarını izleyin
4. Emekli edin	Eski anahtarı kaldırın — ya da daha iyisi, boş `p=` etiketiyle yeniden yayınlayın: “emekli edildi”, “hiç var olmadı” değil	Bunu asla geçişte başlatmayın — erken silme “no key for signature” hatasının 1 numaralı nedenidir

CNAME delegasyonuyla sağlayıcınız bu tam talimatı kendi bölgesinde çalıştırır ve siz hiç görmezsiniz — delegasyonun en güçlü argümanı.

Sık sorulan sorular

“No key for signature” bir temperror mu yoksa permerror mu? Her iki dize de mevcuttur: temperror, başarısız olan veya zaman aşımına uğrayan bir DNS aramasıdır — geçici, genellikle yeniden denemede geçer — permerror ise DNS”in “böyle bir kayıt yok” yanıtı verdiği anlamına gelir. Alıcılar genelinde tekrarlanan bir temperror da genellikle gerçekten eksik kayıt çıkar. dig ile kontrol edin ve etiketi değil yanıtı güvenin.

Bu hata birinin alan adımı taklit ettiği anlamına mı gelir? Hayır — bir sahtekar sizin seçicinizle imzalamaz. Kendi postanızın alıcıların doğrulayamadığı bir imza taşıdığı ve bu nedenle imzasız sayıldığı, DMARC”ın yalnızca SPF”ye dayandığı anlamına gelir. Tam, hizalanmış kimlik doğrulama nadirdir: Defaults.Exposed sayımında yalnızca 10,092,481 alan adı (261,086,232 alanın %3.87‘i) SPF+DKIM+DMARC üçlüsünü tamamladı (veriler: 2026-06-29 itibarıyla).

Yeni seçici çalışır çalışmaz eskisini silebilir miyim? Hemen değil. Onunla imzalanmış mesajlar hâlâ yeniden deneme kuyruklarında ve yönlendirme yollarındadır; anahtarı silmek onları geriye dönük olarak bozar. Eski kaydı en az bir hafta tutun, eski seçici görünmeyene kadar DMARC raporlarınızı izleyin, ardından emekli edin — ideal olarak silmek yerine boş p= ile.

Sağlayıcının denetleyicisi DKIM”in yapılandırıldığını söylüyor ama alıcılar hâlâ anahtar yok bildiriyor. Nasıl? Neredeyse her zaman CNAME hedef tuzağıdır: DNS paneliniz hedefe bölgenizi ekledi (…esp.com.yourdomain.com), dolayısıyla kayıt mevcut ama hiçbir yere işaret etmiyor. dig CNAME selector._domainkey.yourdomain.com +short, saklanan hedefi olduğu gibi gösterir — sağlayıcının istediğiyle karakter karakter karşılaştırın.

Sahibine raporu gönderin

Bunu bir müşteri veya işvereniniz için düzeltiyorsanız, kanıtla döngüyü kapatın. Seçici çözümlendikten sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu işletme sahibine iletin: tarihli, sade dilli, DKIM artık doğrulanıyor. Siber sigorta yenilemesinde ve bir sonraki tedarikçi güvenlik anketinde ihtiyaç duyacakları eserdir — kapalı bilet değil, çalışan bir kontrol kanıtı.

DKIM”i ücretsiz kontrol edin

Seçicilerinizin çözümlenip çözümlenmediğini ve tam olarak neyin düzeltileceğini görün — gizli ve yalnızca sahibine.

Alan adınızı kontrol edin → · “DKIM imzası geçerli değil” → · DKIM”i düzeltin → · Google Workspace”te DKIM kurulumu → · Yalnızca toplu veriler. Veriler AB”de depolanır ve işlenir.