DKIM 'Body Hash Did Not Verify' — co zmieniło Twoją wiadomość i jak to naprawić (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

„Body hash did not verify” oznacza, że Twój podpis DKIM był prawidłowy gdy wiadomość Cię opuściła — i coś przepisało ciało wiadomości potem. Podpis nie jest zepsuty; wiadomość została zmodyfikowana w tranzycie. Tylko 3,87% domen — 10 092 481 — wypełnia pełną triadę SPF-DKIM-DMARC, zgodnie ze spisem Defaults.Exposed obejmującym 261 086 232 domen (2026-06-29).

Naprawą jest poszukiwanie, a następnie decyzja. Znajdź skok, który modyfikuje Twoją pocztę — bramkę dołączającą zastrzeżenie, urządzenie przepisujące linki, listę mailingową dodającą stopkę. Następnie podpisuj po tym skoku, zatrzymaj modyfikację lub spraw, żeby podpis był na nią odporny — w tej kolejności.

Co tak naprawdę oznacza „body hash did not verify”?

Podpis DKIM (RFC 6376) niesie dwa hashe: bh=, hash ciała wiadomości takiej jak była podpisana, i b=, który podpisuje nagłówki plus ten hash ciała. Weryfikator przelicza hash ciała z otrzymanej wiadomości; jeśli nie pasuje do bh=, weryfikacja zatrzymuje się z ciągiem, który wszyscy wklejają w wyszukiwarkę — nagłówek odbiorcy jak:

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

To udokumentowany ciąg przyczyny Microsoftu; Gmail często renderuje tę samą diagnozę jako dkim=neutral (body hash did not verify). Tak czy inaczej, werdykt ogromnie zawęża problem. Twój klucz DNS, selektor i konfiguracja podpisywania są wszystkie w porządku. Kryptografia wykonała swoją pracę: ciało zmieniło się między podpisaniem a weryfikacją — jedna dołączona linia, jeden przepisany URL, jeden przekodowany znak wystarczą. (Inna wiadomość — signature did not verify, no key for signature — oznacza inny błąd; zacznij od „DKIM signature not valid”.) I to pilne, bo nieudany podpis nie może dać DMARC wyrównanego zaliczenia: chyba że SPF przechodzi z wyrównaniem na tej samej wiadomości, poczta wprost nie przechodzi DMARC.

Co zmieniło Twoją wiadomość? Zwykli podejrzani

Coś na ścieżce dostarczania edytowało ciało po zapieczętowaniu przez podpisującego. W praktyce to jedna z czterech rzeczy:

Kto zmodyfikował	Co zmienia	Typowy sygnał
Bramka wychodząca / smart host (reguły transportu Exchange, Mimecast, Proofpoint, Barracuda…)	Dołącza zastrzeżenie prawne, stopkę marketingową lub baner „EXTERNAL:” po tym, jak serwer pocztowy już podpisał	Każda wiadomość na tej trasie nie przechodzi; bezpośrednie wysyłki omijające bramkę przechodzą
Urządzenie bezpieczeństwa / ochrona linków	Przepisuje URL-e na przekierowania do skanowania, dodaje wrappery śledzenia	Nie przechodzą tylko wiadomości zawierające linki
Lista mailingowa (Google Groups, Mailman…)	Dodaje tag tematu i stopkę listy, czasem przepływa ciało	Nie przechodzi tylko poczta wysłana przez listę
Przekaźnik / przekazywanie z przekodowaniem MIME	Transkoduje zestaw znaków, przepakowuje linie — niewidoczne dla człowieka, fatalne dla hasha	Błędy grupują się na jednym odbiorcy lub adresie przekazującym

Sprawdź wyróżniony wiersz najpierw — serwer pocztowy podpisuje, urządzenie brzegowe edytuje, i każda wiadomość wychodzi z podpisem, który był prawdziwy przez trzydzieści milisekund.

Jak znaleźć skok modyfikujący moją pocztę?

Diagnoza różnicowa — porównaj ścieżkę, która działa, ze ścieżką, która nie przechodzi:

Wyślij bezpośrednią wiadomość testową do skrzynki, którą kontrolujesz, u dużego odbiorcy (Gmail działa dobrze), omijając jak największą część łańcucha wychodzącego.
Wyślij drugą wiadomość nieprzechodzącą ścieżką — przez bramkę, przez listę, do domeny dotkniętego odbiorcy.
Porównaj linie Authentication-Results w obu pełnych nagłówkach. Bezpośrednie wysłanie dkim=pass, nieprzechodzące dkim=fail (lub dkim=neutral) z body hash did not verify: modyfikator mieszka między tymi dwiema trasami.
Przejrzyj otrzymane ciało: zastrzeżenie, baner lub stopka, której nie wpisałeś? Linki przepisane do domeny skanowania? To Twój skok, z nazwą — i łańcuch Received: pokazuje, który przekaźnik pojawia się tylko na nieprzechodzącej ścieżce.

Twoje raporty zbiorcze DMARC mówią tę samą historię w skali: źródło konsekwentnie raportujące błąd DKIM z zaliczeniem SPF to zazwyczaj modyfikacja w tranzycie na Twojej własnej trasie, a nie atakujący.

Jak to naprawić?

Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem czegokolwiek. Potwierdza, że Twoje opublikowane klucze DKIM i polityka DMARC są prawidłowe, więc debugujesz jeden prawdziwy problem — modyfikację — a nie gonisz duchy w DNS. Strona naprawy DKIM opisuje sprawdzenia po stronie rekordu.
Podpisuj po modyfikującym skoku. Architektonicznie poprawna naprawa: przenieś podpisywanie DKIM na najbardziej zewnętrzne urządzenie dotykające wiadomości. Instalacje Exchange+bramka powinny podpisywać na bramce (Mimecast, Proofpoint i podobne wszystkie to obsługują) i wyłączyć podpisywanie powyżej. Jeśli Google Workspace lub Microsoft 365 jest Twoim ostatnim skokiem, podpisuj tam i nie pozwól niczemu edytować poczty po tym — patrz konfiguracja DKIM w Google Workspace lub Microsoft 365.
Lub zatrzymaj modyfikację. Usuń edycję ze ścieżki transportu: zastrzeżenie w podpisie klienta lub szablonie zamiast reguły transportu; baner „EXTERNAL:” ograniczony tylko do poczty przychodzącej (tagowanie własnej poczty wychodzącej jako zewnętrznej to podwójna błędna konfiguracja); uwierzytelniona poczta wychodząca wyłączona z przepisywania linków.
Używaj kanonizacji relaxed/relaxed (c=relaxed/relaxed). Kanonizacja ciała simple nie przechodzi na jednej przepakownej linii; relaxed toleruje białe znaki i zmiany zakończeń linii. Bądź szczery co do limitu: relaxed wybacza formatowanie, nigdy treść — dołączona stopka nadal nie przechodzi, tak jak powinna.
Przetestuj ponownie obie ścieżki, a następnie ponów skanowanie. Obie trasy powinny teraz pokazywać dkim=pass z Twoją domeną w d=, a raport ze skanowania powinien być czysty.

Czy powinienem użyć tagu l=, żeby DKIM ignorował dołączoną treść?

Nie — i bądź podejrzliwy wobec każdego przewodnika, który to sugeruje. Tag l= hashuje tylko pierwsze N bajtów ciała, więc dołączona stopka już nie psuje podpisu. „Działa” przez pozostawienie końca wiadomości niepodpisanym: każdy trzymający legalnie podpisaną wiadomość może dołączyć dowolną treść, a Twój ważny podpis nadal weryfikuje wynik. To luka spoofingu ubrana w strój naprawy — praktyczne nadużycie zostało zademonstrowane, a niektórzy odbiorcy penalizują lub ignorują l= z dokładnie tego powodu. Rozwiąż modyfikację; nie pozbawiaj podpisu części swojej poczty.

Co z listami mailingowymi — czy mogę je naprawić?

Przeważnie nie — i wiedzenie o tym oszczędza tygodnie. Lista dodająca tag tematu lub stopkę psuje Twój hash ciała z założenia, i nie kontrolujesz listy. Dwie rzeczy pomagają:

Ta resztka to dokładnie powód, dla którego wdrożenie DMARC jest etapowe. Przejście od p=none przez p=quarantine z rampą pct=, podczas czytania raportów zbiorczych, oznacza, że wiadomości zniekształcone przez listę są poddawane kwarantannie, a nie niszczone, podczas gdy oceniasz wpływ — temat od p=none do p=reject bez utraty legalnej poczty.
ARC to mechanizm odbiorcy, nie Twój. Authenticated Received Chain pozwala liście zaświadczyć, jak wyglądało uwierzytelnienie przy przybyciu, a odbiorcy zdecydować, czy mu ufać. Dla Ciebie, nadawcy, nie ma nic do skonfigurowania. Dobrze prowadzone listy łagodzą problem przepisując nagłówek From; źle prowadzone po prostu psują Twoją pocztę.

Przekazywanie to sąsiedni przypadek — niezawodnie psuje SPF, ale tylko czasem DKIM, dlatego wyrównany DKIM jest Twoją odporną na przekazywanie nogą gdy ciało przeżywa: patrz przekazywana poczta nie przechodzi SPF — dlaczego tego nie da się naprawić.

Dlaczego DKIM tak często się psuje, gdy tak mało domen ma w ogóle pełny stos?

Bo DKIM to kruche środkowe dziecko triady: SPF to statyczny rekord DNS, DMARC to oświadczenie polityki, ale DKIM musi przeżyć podróż. Tylko 51,84% ocenionych domen publikuje w ogóle możliwy do odkrycia klucz DKIM w DNS, zgodnie ze spisem Defaults.Exposed, i tylko 10 092 481 domen — 3,87% z 261 086 232 ocenionych — posiada razem SPF, DKIM i wymuszającą politykę DMARC (model dojrzałości wdrożenia SPF rozkłada drabinę). Prawidłowe wykonanie tej naprawy to najtrudniejsza część dołączania do tych 3,87%.

Często zadawane pytania

Czy „body hash did not verify” to znak, że ktoś podszywa się pod moją domenę? Zazwyczaj nie — spoofer zazwyczaj w ogóle nie może wyprodukować Twojego podpisu DKIM, więc jego poczta pokazuje brak podpisu lub no key. Nieudany hash ciała oznacza, że wiadomość naprawdę podpisana przez Twoją infrastrukturę została potem edytowana. Sprawdź własną bramkę przed założeniem, że to atakujący.

SPF przechodzi na tych wiadomościach — czy jestem nadal bezpieczny? Na razie może tak: DMARC potrzebuje tylko jednego wyrównanego zaliczenia. Ale zaliczenie SPF paruje w chwili, gdy ktokolwiek przekaże wiadomość, i jeśli nie jest wyrównane z domeną From, nigdy nie liczyło się dla DMARC. Przy tylko 3,87% domen posiadających pełną triadę (spis 2026-06-29 z 261 086 232 domen), „jedna kulawa noga” to normalny stan — i ten do naprawienia.

Czy przejście na kanonizację relaxed/relaxed naprawi mój problem z zastrzeżeniami? Nie. Relaxed toleruje tylko zmiany białych znaków i przepakowywania linii. Dołączone zastrzeżenie to zmiana treści i hash musi na niej nie przejść — to DKIM działający poprawnie. Przenieś punkt podpisywania lub przenieś zastrzeżenie.

Błąd pojawia się tylko dla domeny jednego klienta. Dlaczego? Ich strona prawie na pewno modyfikuje przychodzącą pocztę — urządzenie bezpieczeństwa przepisujące linki lub stemplujące banery przed uruchomieniem weryfikatora, lub wewnętrzne przekazywanie przekodowujące ciało. Prześlij im sekcję diagnostyczną tej strony; naprawa leży na ich bramce, a nie w Twoim DNS.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zamknij pętlę z dowodem. Gdy modyfikujący skok jest naprawiony, ponów bezpłatne skanowanie i prześlij oceniony raport właścicielowi firmy: z datą, w prostym języku, DKIM i DMARC na jednej stronie. To artefakt, który będzie mu potrzebny przy przedłużeniu ubezpieczenia cybernetycznego i kolejnym kwestionariuszu dostawcy — dowód, że poczta opuszczająca firmę jest teraz pocztą, która dociera.

Sprawdź swoją domenę → · Przewodnik „DKIM signature not valid” → · Napraw DKIM → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.