Jeśli DKIM nie przechodzi, podczas gdy SPF przechodzi, wiadomość dotarła do odbiorcy z prawidłowym adresem zwrotnym (return-path), ale z uszkodzonym podpisem kryptograficznym. SPF sprawdza jedynie, czy adres IP nadawcy jest autoryzowany dla domeny koperty, więc może przejść dla tej samej wiadomości, dla której DKIM zawodzi, ponieważ DKIM weryfikuje, że podpisane nagłówki i treść dotarły dokładnie w takiej postaci, w jakiej wysłał je Twój serwer. Wynik DKIM fail (a nie none) niemal zawsze oznacza jedną z dwóch rzeczy: podpisu nie udało się zweryfikować względem opublikowanego klucza albo treść objęta podpisem została zmieniona w drodze.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Ten przewodnik opisuje przyczyny na poziomie samego podpisu, a nie wyrównania DKIM. Jeśli Twój wynik DKIM to w rzeczywistości pass, a DMARC nadal zawodzi, to inny problem, który omawiamy w błędy wyrównania DKIM. Tutaj naprawiamy sam podpis.
Najpierw odczytaj dokładny wynik DKIM
Otwórz surową wiadomość i znajdź nagłówek Authentication-Results. Werdykt DKIM wskaże Ci, którą ścieżkę zbadać.
dkim=passoznacza, że podpis został zweryfikowany. Jeśli DMARC nadal zawodzi, to problem z wyrównaniem, a nie z podpisem.dkim=failoznacza, że odbiorca znalazł podpis, ale nie mógł go zweryfikować. To właśnie ten przypadek rozwiązuje ten przewodnik.dkim=noneoznacza, że w ogóle nie było nagłówkaDKIM-Signature, więc nic nie zostało podpisane.dkim=temperrorlubdkim=permerrorzwykle wskazuje na DNS: klucza nie udało się pobrać albo rekord jest błędnie sformatowany.
Typowy nagłówek z błędem wygląda tak:
dkim=fail (body hash did not verify) header.d=yourdomain.com header.s=selector1
Tekst w nawiasach to najważniejsza wskazówka na całej stronie. "Body hash did not verify" i "signature did not verify" prowadzą Cię zupełnie różnymi ścieżkami. Jeśli dopiero uczysz się interpretować ten nagłówek, zobacz jak czytać nagłówek Authentication-Results.
Przyczyna 1: treść została zmieniona w drodze (niezgodność skrótu treści)
DKIM oblicza skrót treści wiadomości (wartość bh=) oraz skrót wybranych nagłówków. Jeśli treść zmieni się choćby o jeden bajt po podpisaniu, wartość bh= przestaje pasować i otrzymujesz niezgodność skrótu treści DKIM (body hash mismatch). SPF pozostaje tym nietknięty, ponieważ SPF nigdy nie zagląda do treści.
Typowi winowajcy:
Listy mailingowe i grupy dyskusyjne
Serwery list (Mailman, Google Groups, listservy) często dopisują stopkę, dodają znacznik [list-name] do tematu albo konwertują kodowanie treści. Każda z tych operacji łamie skrót treści. To oczekiwane zachowanie list i dokładnie dlatego obsługa DMARC dla list jest trudna. Lista powinna podpisać wiadomość ponownie własną domeną (ARC pomaga zachować pierwotny wynik), ale Twój podpis po takiej modyfikacji zawiedzie w pełni zgodnie z oczekiwaniami.
Przekierowania, które przepisują treść
Niektóre przekierowania i bramy bezpieczeństwa przepisują odnośniki (ochrona URL / ochrona kliknięć), wstrzykują banery "nadawca zewnętrzny" albo dodają zastrzeżenia prawne. Każda taka edycja zmienia treść. Zwróć uwagę, że zwykłe przekierowanie SMTP łamie SPF, natomiast przekierowanie przepisujące treść łamie DKIM. Oba te tryby awarii omawiamy osobno w dlaczego przekierowanie poczty łamie SPF.
Stopki firmowe i podpisy dodawane przez bramę
Urządzenie, które dobija zastrzeżenie prawne do każdej wychodzącej wiadomości po tym, jak Twój MTA ją podpisał, złamie Twój własny DKIM. Rozwiązaniem jest kolejność: podpisuj na końcu, po każdym punkcie modyfikującym treść wewnątrz Twojej własnej infrastruktury.
Przyczyna 2: zmienił się zestaw nagłówków
DKIM tworzy skrót również z wybranej listy nagłówków wymienionych w znaczniku h=. Jeśli podpisany nagłówek zostanie zmieniony albo dodana zostanie jego druga kopia, podpis zawiedzie nawet wtedy, gdy treść pozostaje nienaruszona. Najczęstszym wyzwalaczem jest nagłówek występujący dwukrotnie (na przykład dwie linie Subject albo zduplikowany From), ponieważ DKIM podpisuje konkretne wystąpienie. Systemy pośredniczące, które przepisują Subject, by dodać znacznik, złamią podpisy, które obejmowały Subject w h=.
Przyczyna 3: błędny selektor lub klucz (awaria po stronie DNS)
Jeśli weryfikacja zawodzi jeszcze przed jakąkolwiek kontrolą treści, odbiorca nie mógł dopasować Twojego podpisu do klucza publicznego. Sprawdź s= (selektor) i d= (domenę) w nagłówku DKIM-Signature, a następnie samodzielnie odpytaj klucz:
selector1._domainkey.yourdomain.com TXT
Częste ustalenia:
Nie znaleziono selektora
Nagłówek DKIM-Signature wskazuje selektor, który nie ma rekordu TXT. Dzieje się tak po migracji dostawców, po rotacji kluczy przed opublikowaniem nowego albo przy literówce w nazwie selektora. Klucz DKIM znajduje się pod <selector>._domainkey.<domain>, więc etykieta musi pasować dokładnie.
Opublikowano błędny klucz
Rekord istnieje, ale zawiera stary lub niepasujący klucz publiczny, więc podpisu wykonanego bieżącym kluczem prywatnym nie da się zweryfikować. To klasyczny efekt rotacji klucza prywatnego u dostawcy bez aktualizacji DNS. Utrzymuj rotację skoordynowaną według harmonogramu, tak jak opisano w rotacja kluczy DKIM.
Obcięcie klucza
Ciągi TXT w DNS są ograniczone do 255 znaków każdy, a klucz 2048-bitowy to przekracza. Rekord musi zostać podzielony na kilka ciągów w cudzysłowach wewnątrz jednego rekordu TXT, które resolver skleja z powrotem. Jeśli Twój host DNS po cichu odrzucił drugi fragment albo wkleiłeś tylko część klucza, wartość p= jest niekompletna i weryfikacja zawodzi. Opublikuj ponownie pełny klucz i potwierdź, że złożona z powrotem wartość p= odpowiada temu, czego oczekuje Twój nadawca. Szczegóły konfiguracji znajdziesz w jak skonfigurować DKIM.
Odwołany klucz
Rekord z pustym p= (v=DKIM=1; p=) to celowe odwołanie. Jeśli widzisz to przy kluczu, którego nadal używasz, ktoś go wyczyścił.
Przyczyna 4: znacznik długości treści l=
DKIM obsługuje opcjonalny znacznik l=, który podpisuje tylko pierwsze N bajtów treści. Istnieje po to, aby stopka dopisana poza tą długością nie łamała skrótu. W praktyce l= jest ryzykowny: pozwala atakującemu dopisać dowolną treść poniżej podpisanej części bez unieważnienia podpisu, a niektórzy odbiorcy karzą go lub ignorują. Jeśli Twój podpisujący używa l=, a treść nadal zawodzi, wiadomość prawdopodobnie została zmodyfikowana wewnątrz podpisanego obszaru albo treść skrócono poniżej zadeklarowanej długości. Bezpieczniejszą konfiguracją jest podpisanie całej treści i usunięcie l=.
Tabela objaw-przyczyna
| Authentication-Results mówi | Najbardziej prawdopodobna przyczyna | Naprawa |
|---|---|---|
body hash did not verify | Stopka, znacznik listy, zastrzeżenie lub przepisanie odnośników po podpisaniu | Podpisuj na końcu; licz się z błędami list; użyj ARC |
signature did not verify | Podpisany nagłówek zmienił się lub został zduplikowany | Zawęź h=; podpisuj na końcu |
key not found / no key for signature | Brak selektora w DNS | Opublikuj rekord TXT <selector>._domainkey |
permerror / nieprawidłowy klucz | Obcięta lub błędnie sformatowana wartość p= | Opublikuj ponownie pełny klucz w dzielonych ciągach TXT |
pass, ale DMARC zawodzi | To nie problem z podpisem | Napraw wyrównanie, a nie podpis |
Pętla weryfikacji
Wykonuj tę pętlę, aż nagłówek pokaże dkim=pass:
- Wyślij testową wiadomość na skrzynkę, którą kontrolujesz, i otwórz jej surowe źródło.
- Odczytaj ciąg z przyczyną DKIM w
Authentication-Results. - Odnotuj
d=is=z nagłówkaDKIM-Signature. - Odpytaj
<s>._domainkey.<d>i potwierdź, że kluczp=jest obecny i kompletny. - Jeśli klucz jest w porządku, przyczyną jest treść. Wyślij tę samą wiadomość bezpośrednio (bez listy, bez przekierowania) i sprawdź ponownie. Jeśli przechodzi bezpośrednio, a zawodzi przez listę, to modyfikacja jest przyczyną.
- Przenieś każdy krok modyfikujący treść (stopki, zastrzeżenia, przepisywanie odnośników) tak, aby wykonywał się przed podpisaniem, dzięki czemu DKIM podpisze ostateczną treść.
- Przetestuj ponownie.
Czym różni się to od błędu wyrównania DMARC
To rozróżnienie, które najbardziej myli większość ludzi. Uwierzytelnianie DKIM pyta "czy podpis jest kryptograficznie prawidłowy". Wyrównanie DKIM pyta "czy domena d= w prawidłowym podpisie odpowiada domenie z From:". Możesz mieć całkowicie prawidłowy dkim=pass, który mimo to nie przechodzi DMARC, ponieważ został podpisany domeną Twojego dostawcy zamiast Twoją. To naprawa wyrównania (opublikuj klucz we własnej domenie i podpisuj z d=yourdomain.com), a nie naprawa podpisu. Jeśli Twój wynik to pass, a DMARC nadal narzeka, zatrzymaj się tutaj i przeczytaj błędy wyrównania DKIM. Jeśli Twój wynik to fail, potrzebujesz przyczyn opisanych powyżej.
Najczęściej zadawane pytania
Dlaczego DKIM nie przechodzi, a SPF tak, dla tej samej wiadomości?
SPF sprawdza adres IP nadawcy względem domeny z envelope-from i ignoruje treść wiadomości. DKIM weryfikuje kryptograficzny skrót nagłówków i treści. Przekaźnik może być autoryzowanym adresem IP (SPF pass), podczas gdy stopka lub znacznik listy zmienia treść i łamie skrót DKIM. Sprawdzają różne rzeczy, więc to, że jedno przechodzi, a drugie zawodzi, jest normalne.
Co oznacza "body hash did not verify"?
Oznacza, że treść wiadomości zmieniła się po tym, jak Twój serwer ją podpisał. Wartość bh= w podpisie nie odpowiada już treści, z której skrót policzył odbiorca. Częste przyczyny to stopki list mailingowych, dopisane zastrzeżenia, przepisywanie odnośników przez bramę lub konwersja kodowania w drodze.
Czy mogę naprawić błędy DKIM powodowane przez listy mailingowe?
Nie przez zmianę własnego podpisu, ponieważ lista w sposób uprawniony modyfikuje wiadomość. Operator listy powinien podpisać ją ponownie domeną listy i użyć ARC, aby przenieść Twój pierwotny wynik uwierzytelnienia dalej. W przypadku własnej wysyłki upewnij się, że DKIM jest ostatnim krokiem, tak aby nic wewnątrz Twojej infrastruktury nie edytowało treści po podpisaniu.
Skąd mam wiedzieć, czy problem leży w kluczu, czy w treści?
Odczytaj ciąg z przyczyną. "Key not found" lub permerror wskazuje na DNS, więc sprawdź selektor i pełną wartość p=. "Body hash did not verify" lub "signature did not verify" wskazuje na treść, więc przetestuj wiadomość wysłaną bezpośrednio w porównaniu z tą przechodzącą przez listę lub przekierowanie, które ją zmienia.