Defaults.Exposed › Düzeltmeler › Guides

DKIM "Body Hash Did Not Verify" — İletiyi Ne Değiştirdi ve Nasıl Düzeltilir (2026)

Yayımlanma 2026-07-08

Veriler 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan genelinde toplu sayım verileri. Bkz. nasıl derecelendiriyoruz.

“Body hash did not verify” hatası, DKIM imzanızın ileti sizden ayrıldığında geçerli olduğunu gösterir — ve sonrasında bir şey ileti gövdesini yeniden yazmıştır. İmza bozuk değil; ileti transit sürecinde değiştirilmiştir. Defaults.Exposed’un 261,086,232 alan sayımına göre yalnızca 3.87% oranındaki alan — 10,092,481 alan — eksiksiz SPF-DKIM-DMARC üçlüsünü tamamlamaktadır (2026-06-29).

Düzeltme sürecinin iki aşaması vardır: araştırma, ardından karar. Postanızı değiştiren atlamayı bulun — bir yasal bildirim ekleyen ağ geçidi, bağlantıları yeniden yazan bir cihaz, altbilgi ekleyen bir posta listesi. Ardından bu atlamadan sonra imzalayın, değişikliği durdurun ya da imzayı buna toleranslı hale getirin; bu sırayla.

”Body hash did not verify” gerçekte ne anlama gelir?

Bir DKIM imzası (RFC 6376) iki karma taşır: bh= (imzalandığı haldeki ileti gövdesinin karması) ve b= (başlıkları artı gövde karmasını imzalar). Doğrulayıcı, aldığı iletiden gövde karmasını yeniden hesaplar; bh= ile eşleşmezse doğrulama, herkesin bir arama motoruna yapıştırdığı şu dizeyle durur:

Authentication-Results: …; dkim=fail (body hash did not verify)

Bu, Microsoft’un belgelenmiş hata dizesidir; Gmail aynı tanıyı çoğunlukla dkim=neutral (body hash did not verify) olarak gösterir. Her iki durumda da bu sonuç sorunu büyük ölçüde daraltır. DNS anahtarınız, seçiciniz ve imzalama yapılandırmanız — hepsi sağlamdır. Kriptografi görevini yaptı: imzalama ve doğrulama arasında gövde değişti — eklenen bir satır, yeniden yazılan bir URL, yeniden kodlanan tek bir karakter bile yeterlidir. (Farklı bir ileti — signature did not verify, no key for signature — farklı bir hata anlamına gelir; “DKIM signature not valid” sayfasından başlayın.) Bu durum acildir: başarısız bir imza, DMARC’a hizalı bir geçiş sağlayamaz — aynı iletide SPF hizalı olarak geçmiyorsa, posta doğrudan DMARC’ta başarısız olur.

İletiyi ne değiştirdi? Olası nedenler

Teslimat yolundaki bir şey, imzalayıcınız mühürledikten sonra gövdeyi düzenledi. Pratikte dört olası neden vardır:

Vurgulanan satırı önce kontrol edin — posta sunucusu imzalar, uç cihaz düzenler ve her ileti otuz milisaniye önce doğru olan bir imzayla ayrılır.

Postamı değiştiren atlamayı nasıl bulurum?

Ayırıcı tanı — çalışan bir yolu başarısız olan yolla karşılaştırın:

1. Denetlediğiniz büyük bir alıcıdaki posta kutusuna (Gmail iyi çalışır) doğrudan bir test iletisi gönderin; giden zincirinizin mümkün olduğunca fazla bölümünü atlayın.
2. Başarısız yoldan ikinci bir ileti gönderin — ağ geçidinden, listeden veya etkilenen alıcının alanına.
3. Her iki tam başlıktaki Authentication-Results satırlarını karşılaştırın. Doğrudan gönderimde dkim=pass, başarısız yolda body hash did not verify ile dkim=fail (veya dkim=neutral): değiştirici bu iki güzergâh arasında bir yerde.
4. Alınan gövdeye bakın: yazmadığınız bir bildirim, başlık veya altbilgi mi var? Bağlantılar bir tarama alanına mı yeniden yazılmış? İşte bu sizin atlamanız — ve Received: zinciri yalnızca başarısız yolda görünen geçiş noktasını gösterir.

DMARC toplu raporlarınız aynı hikâyeyi ölçekte anlatır: sürekli olarak SPF geçişiyle DKIM başarısızlığı bildiren bir kaynak, genellikle saldırgan değil, kendi güzergâhınızda transit sırasında değiştirmedir.

Nasıl düzeltirim?

1. Herhangi bir şeye dokunmadan önce defaults.exposed üzerinden ücretsiz taramayı çalıştırın. Bu, yayımlanmış DKIM anahtarlarınızın ve DMARC politikanızın sağlam olduğunu doğrular; böylece gerçek sorunu — değişikliği — ayıklar, DNS’teki hayaletleri değil. DKIM düzeltme sayfası kayıt tarafı kontrollerini kapsar.
2. Değiştiren atlamadan sonra imzalayın. Mimari açıdan doğru düzeltme: DKIM imzalamayı, iletiyle temas eden en dış cihaza taşıyın. Exchange artı ağ geçidi kullanan kurumlar, ağ geçidinde imzalamalı (Mimecast, Proofpoint ve benzer ürünler bunu destekler) ve akış yukarısındaki imzalamayı devre dışı bırakmalıdır. Google Workspace veya Microsoft 365 son atlamanızsa, orada imzalayın ve hiçbir şeyin sonrasında postaları düzenlemesine izin vermeyin — bkz. Google Workspace’te DKIM kurulumu veya Microsoft 365.
3. Ya da değişikliği durdurun. Düzenlemeyi aktarım yolundan kaldırın: aktarım kuralı yerine istemci imzasındaki veya şablondaki yasal bildirim; yalnızca gelen postaya kapsanmış “EXTERNAL:” başlığı (kendi giden postanızı harici olarak etiketlemek iki kez yanlış yapılandırmadır); kimliği doğrulanmış giden postanın bağlantı yeniden yazımından muaf tutulması.
4. relaxed/relaxed kanonizasyon kullanın (c=relaxed/relaxed). simple gövde kanonizasyonu tek yeniden sarılmış satırda başarısız olur; relaxed boşluk ve satır sonu değişikliklerine toleranslıdır. Sınırı dürüstçe kabul edin: relaxed yalnızca biçimlendirmeyi bağışlar, içerik değişikliklerini asla — eklenen bir altbilgi yine de başarısız olur, olmalıdır.
5. Her iki yolu yeniden test edin, ardından yeniden tarayın. Her iki güzergâh artık d= alanında kendi alanınızla dkim=pass göstermeli ve tarama raporu temiz olmalıdır.

l= etiketini kullanarak DKIM’in eklenen içeriği görmezden gelmesini sağlamalı mıyım?

Hayır — bunu öneren herhangi bir kılavuzdan şüphelenin. l= etiketi gövdenin yalnızca ilk N baytını karma olarak alır; böylece eklenen bir altbilgi artık imzayı bozmaz. Bu “çalışır” çünkü iletinizin sonunu imzasız bırakır: meşru imzalı bir iletiyi elinde bulunduran herhangi biri rastgele içerik ekleyebilir ve geçerli imzanız yine de sonuç üzerinde doğrulanır. Bu, bir düzeltme kılığına girmiş bir sahtecilik açığıdır — pratik kötüye kullanım gösterilmiştir ve bazı alıcılar tam da bu nedenle l= etiketini cezalandırır veya yok sayar. Değişikliği çözün; postanızın bir bölümünü imzasız bırakmayın.

Posta listeleri hakkında ne yapabilirim — bunları düzeltebilir miyim?

Büyük ölçüde hayır — bunu bilmek size haftalar kazandırır. Konu etiketi veya altbilgi ekleyen bir liste, gövde karmanızı tasarım gereği bozar ve listeyi siz kontrol etmiyorsunuzdur. İki şey yardımcı olur:

• Bu kalıntı tam da DMARC dağıtımının aşamalı olmasının nedenidir. p=none’dan pct= artışıyla p=quarantine’e geçiş yaparak, toplu raporları okurken, liste tarafından bozulan iletilerin etkisini değerlendirirken yok edilmek yerine karantinaya alınmasını sağlarsınız — bu, p=none’dan meşru e-postayı kaybetmeden p=reject’e konusunda ele alınan bir konudur.
• ARC, alıcının mekanizmasıdır, sizin değil. Kimlik Doğrulamalı Alınan Zinciri (Authenticated Received Chain), listenin varışta kimlik doğrulamanın nasıl göründüğüne tanıklık etmesine ve alıcının buna güvenip güvenmeyeceğine karar vermesine olanak tanır. Gönderici olarak sizin yapılandırmanız gereken bir şey yoktur. İyi yönetilen listeler From başlığını yeniden yazarak hafifletir; kötü yönetilenler postanızı bozar.

Yönlendirme, bitişik durumdur — SPF’yi güvenilir biçimde bozar ama yalnızca bazen DKIM’i; bu nedenle hizalı DKIM, gövde ayakta kalırken yönlendirmeye dayanıklı bacağınızdır: bkz. yönlendirilen e-posta SPF’de başarısız olur — neden düzeltemezsiniz.

Pek çok alan tam yığına sahip değilken DKIM neden bu kadar sık bozuluyor?

Çünkü DKIM, üçlünün kırılgan orta çocuğudur: SPF statik bir DNS kaydı, DMARC bir politika bildirimidir; ama DKIM yolculukta ayakta kalmak zorundadır. Defaults.Exposed sayımına göre derecelendirilmiş alanların yalnızca 51.84%‘si DNS’te keşfedilebilir bir DKIM anahtarı yayımlar ve yalnızca 10,092,481 alan — derecelendirilmiş 261,086,232 alanın 3.87%‘si — SPF, DKIM ve zorlayıcı bir DMARC politikasını bir arada tutar (SPF benimseme olgunluk modeli bu merdiveni ayrıntılı inceler). Bu düzeltmeyi doğru yapmak, o 3.87%‘ye katılmanın en zor kısmıdır.

Sık sorulan sorular

“Body hash did not verify” hatası, birinin alanımı sahtekârlıkla kullandığının işareti mi? Genellikle hayır — sahtecilik yapan biri DKIM imzanızı üretemez, bu nedenle postaları imzasız veya no key ile görünür. Başarısız bir gövde karması, altyapınız tarafından gerçekten imzalanmış bir iletinin sonradan düzenlendiği anlamına gelir. Saldırgan varsaymadan önce kendi ağ geçidinizi kontrol edin.

Bu iletilerde SPF geçiyor — sorun yok mu? Şimdilik belki: DMARC yalnızca bir hizalı geçişe ihtiyaç duyar. Ancak SPF’nin geçişi, birinin iletiyi yönlendirmesiyle buharlaşır; From alanınıza hizalı değilse zaten DMARC için hiç sayılmıyordu. Yalnızca 3.87%‘lik bir alanın tam üçlüye sahip olmasıyla (2026-06-29 sayımı, 261,086,232 alan), “bir bacağı topallayan” normal durumdur — ve düzeltilebilir olan budur.

relaxed/relaxed kanonizasyona geçmek bildirimi sorunumu çözer mi? Hayır. relaxed yalnızca boşluk ve satır sarma değişikliklerine toleranslıdır. Eklenen bir bildirim içerik değişikliğidir ve karma üzerinde başarısız olmak zorundadır — bu DKIM’in doğru çalıştığının kanıtıdır. İmzalama noktasını veya bildirimi taşıyın.

Hata yalnızca bir müşterinin alanında oluyor. Neden? Onların tarafı büyük ihtimalle gelen postayı değiştiriyor — doğrulayıcıları çalışmadan önce bağlantıları yeniden yazan veya başlık ekleyen bir güvenlik cihazı ya da gövdeyi yeniden kodlayan dahili bir yönlendirme. Bu sayfanın tanı bölümünü onlara gönderin; düzeltme kendi ağ geçitlerindedir, DNS’inizde değil.

Sahiplerine raporu gönderin

Bunu bir müşteri veya işvereniniz için düzeltiyorsanız, kanıtla döngüyü kapatın. Değiştiren atlama düzeldikten sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu iş sahibine iletin: tarihli, sade dilli, tek sayfada DKIM ve DMARC durumu. Bu, siber sigorta yenileme ve bir sonraki tedarikçi anketi için ihtiyaç duyacakları belgedir — şirketten çıkan postanın artık varılan posta olduğunun kanıtı.

Alanınızı kontrol edin → · “DKIM signature not valid” rehberi → · DKIM’i düzelt → · Nasıl derecelendiriyoruz → · Yalnızca toplu veriler. Veriler AB’de depolanır ve işlenir.