Błąd DKIM: co oznaczają poszczególne komunikaty o błędach i jak je naprawić

DomainKeys Identified Mail (DKIM) stanowi jeden z podstawowych filarów uwierzytelniania wiadomości e-mail. Dzięki dołączaniu podpisu kryptograficznego do wysyłanych wiadomości DKIM umożliwia serwerom pocztowym odbierającym wiadomości sprawdzenie, czy dana wiadomość została rzeczywiście autoryzowana przez właściciela domeny oraz czy jej treść nie została zmodyfikowana podczas przesyłania.

Jednak gdy serwer odbiorczy sprawdza przychodzącą wiadomość e-mail i napotyka w nagłówku status „dkim=fail”, uwierzytelnianie zostaje przerwane. Błąd DKIM sygnalizuje bramkom odbiorczym, takim jak Google Workspace, Microsoft 365 czy Apple Mail, że albo treść wiadomości została zmodyfikowana po opuszczeniu serwera nadawcy, albo nie udało się pobrać klucza publicznego z serwera DNS, albo sam podpis kryptograficzny jest nieprawidłowy.

W zależności od polityki DMARC Twojej domeny oraz ustawień zabezpieczeń odbiorcy, błędy DKIM mogą powodować, że legalne wiadomości służbowe trafią do folderów ze spamem lub zostaną całkowicie odrzucone. Niniejszy przewodnik stanowi szczegółowy zbiór komunikatów o błędach, który pomoże Ci zdiagnozować dokładny tekst komunikatu o błędzie w nagłówkach wiadomości e-mail, zidentyfikować przyczynę problemu oraz szybko go rozwiązać.

Najczęstsze przyczyny niepowodzenia DKIM

Chociaż błędy weryfikacji DKIM wynikają ostatecznie z niezgodności skrótu lub niepowodzenia w pobraniu klucza, rzeczywiste przyczyny operacyjne zazwyczaj można podzielić na kilka przewidywalnych kategorii. Porównanie tych przyczyn z konkretnym komunikatem o błędzie w nagłówkach wiadomości e-mail wskaże Ci bezpośrednio rozwiązanie.

1. Modyfikacje wiadomości przez bramy pocztowe i urządzenia zabezpieczające

Najczęstszą przyczyną niepowodzeń związanych z DKIM w środowiskach korporacyjnych jest to, że usługa pośrednicząca modyfikuje treść wiadomości po tym, jak podpis DKIM został już nałożony. Urządzenia zabezpieczające, bramy wychodzące, filtry antyspamowe oraz narzędzia do zapobiegania utracie danych (DLP) często zmieniają treść wiadomości wychodzących poprzez dodawanie stopek firmowych, wstawianie linków śledzących, przekodowywanie zestawów znaków lub modyfikowanie granic MIME. 

Jeśli podpisywanie nastąpi na głównym serwerze pocztowym przed przejściem przez te urządzenia, skrót treści obliczony przez odbiorcę nie będzie zgodny z oryginalnym podpisem, co spowoduje wygenerowanie błędu „dkim=fail” (skrót treści nie został zweryfikowany).

2. Listy mailingowe i automatyczne przekazywanie wiadomości e-mail

Gdy wiadomość e-mail jest wysyłana na listę mailingową lub automatycznie przekazywana przez pośredniczące serwery transferu poczty (MTA), serwer przekazujący często modyfikuje nagłówki wiadomości (takie jak „Temat” czy „Do”) lub dodaje stopki związane z zarządzaniem listą mailingową (takie jak linki do rezygnacji z subskrypcji lub zastrzeżenia dotyczące listy). Ponieważ podpis kryptograficzny obejmuje te elementy, każda zmiana wprowadzona po podpisaniu unieważnia weryfikację. 

Chociaż nowoczesne protokoły, takie jak Authenticated Received Chain (ARC), pomagają podmiotom przekazującym wiadomości zachować stan uwierzytelnienia, surowe kontrole DKIM w przypadku przekazywanych wiadomości często kończą się niepowodzeniem.

3. Brakujące, nieprawidłowo skonfigurowane lub skrócone rekordy TXT serwera DNS

Serwery odbierające pocztę muszą pobrać klucz publiczny użytkownika z określonego rekordu DNS typu TXT znajdującego się pod adresem selector._domainkey.yourdomain.com. Jeśli ten rekord DNS nie istnieje, został opublikowany pod nieprawidłową nazwą selektora lub występuje opóźnienie spowodowane propagacją DNS, odbiorca nie będzie w stanie pobrać klucza, co spowoduje błąd dkim=fail (brak klucza do podpisu).

Ponadto w przypadku kluczy RSA o długości 2048 bitów pojawia się konkretny i powszechny problem. Zgodnie z normą RFC 1035 długość pojedynczego ciągu znaków w rekordzie DNS typu TXT jest ograniczona do 255 bajtów. Klucz RSA o długości 2048 bitów zakodowany w formacie base64 ma długość około 392 znaków. Jeśli dostawca usług DNS lub administrator wklei klucz 2048-bitowy jako pojedynczy ciąg znaków bez cudzysłowów, starsze narzędzia do zarządzania DNS mogą skrócić treść klucza, co spowoduje, że klucz publiczny w DNS będzie niekompletny i doprowadzi do błędu „dkim=fail” (nie udało się zweryfikować podpisu).

4. Niezgodności kluczy, niezapowiedziana rotacja kluczy oraz migracje dostawców

Aby weryfikacja DKIM zakończyła się powodzeniem, klucz prywatny używany przez serwer pocztowy wysyłający wiadomość do wygenerowania podpisu musi matematycznie odpowiadać kluczowi publicznemu opublikowanemu w Twoim systemie DNS. Do niezgodności kryptograficznej dochodzi, gdy:

• Serwer poczty odpowiedzialny za podpisywanie generuje nowy klucz prywatny, ale rekord DNS nie jest aktualizowany w tym samym czasie.
• Dostawca usług poczty elektronicznej (ESP) zmienia swoje klucze podpisujące bez aktualizowania opublikowanego rekordu TXT lub docelowego rekordu CNAME.
• Domena zostaje przeniesiona na nową platformę hostingową, podczas gdy serwer poczty elektronicznej nadal podpisuje dane przy użyciu starego selektora lub wycofanej pary kluczy.

5. Błędy składniowe w rekordach DNS i ustawienia ścisłej kanonikalizacji

Niewielkie błędy formatowania w rekordzie klucza publicznego (takie jak brakujące średniki, zbędne spacje w treści klucza w formacie Base64 lub nieprawidłowe nazwy tagów) sprawiają, że klucze publiczne nie mogą zostać przetworzone przez odbiorcze serwery MTA. 

Podobnie, jeśli serwer podpisujący stosuje prostą kanonizację nagłówków lub treści (c=simple/simple), nawet niewielkie zmiany znaków końca linii (CRLF zamiast LF) lub korekty spacji końcowych wprowadzone przez serwery przekaźnikowe uniemożliwią weryfikację.

Recenzja Składnia rekordu DKIM.

6. Nie skonfigurowałeś DKIM dla zewnętrznych dostawców usług poczty elektronicznej

Jeśli korzystasz z usług kilku zewnętrznych dostawców poczty elektronicznej do wysyłania wiadomości e-mail w imieniu swojej organizacji, skontaktuj się z nimi, aby uzyskać instrukcje dotyczące aktywacji DKIM dla wychodzących wiadomości e-mail. Jeśli do wysyłania wiadomości e-mail do klientów korzystasz z własnych domen niestandardowych lub subdomen zarejestrowanych w tej zewnętrznej usłudze, poproś dostawcę o zajęcie się konfiguracją DKIM w Twoim imieniu.

W idealnym przypadku, jeśli zewnętrzny dostawca pomaga Państwu w outsourcingu obsługi poczty elektronicznej, powinien skonfigurować Państwa domenę poprzez opublikowanie rekordu DKIM w swoim systemie DNS przy użyciu selektora DKIM , który jest unikalny dla Ciebie, bez konieczności Twojej ingerencji.

OR, 

Możesz wygenerować parę kluczy DKIM i przekazać klucz prywatny dostawcy usług poczty elektronicznej, a klucz publiczny opublikować we własnym systemie DNS. 

Błędna konfiguracja może prowadzić do nieprawidłowego działania DKIM, dlatego należy otwarcie komunikować się z dostawcą usług w sprawie konfiguracji DKIM. 

Uwaga: Niektóre serwery pocztowe innych dostawców dodają sformatowane stopki do treści wiadomości. Jeśli serwery te pełnią rolę serwerów pośredniczących w procesie przekazywania wiadomości e-mail, połączona stopka może być jednym z czynników powodujących niepowodzenie weryfikacji DKIM. 

7. Problemy z komunikacją z serwerem

W niektórych sytuacjach wiadomość e-mail może zostać wysłana z serwera, na którym wyłączono DKIM. W takich przypadkach weryfikacja DKIM dla tej wiadomości zakończy się niepowodzeniem, nawet jeśli pozostałe serwery w Twojej infrastrukturze są poprawnie skonfigurowane. Ważne jest, aby upewnić się, że wszystkie strony uczestniczące w komunikacji mają prawidłowo włączoną funkcję DKIM. 

8. Awaria DNS / przerwa w działaniu DNS

Jest to częsty powód niepowodzeń DKIM. Awaria DNS może wystąpić z różnych powodów, w tym z powodu ataków typu denial of service. Rutynowa konserwacja serwera nazw może być również przyczyną przestoju DNS. W tym (zwykle krótkim) okresie serwery odbiorców nie mogą wykonywać zapytań DNS. 

Ponieważ wiemy, że DKIM istnieje w DNS użytkownika jako rekord TXT/CNAME, serwer-klient podczas uwierzytelniania wykonuje wyszukiwanie w DNS nadawcy w celu odszukania klucza publicznego. W czasie przerwy w działaniu serwera nie jest to możliwe, co może spowodować uszkodzenie DKIM. 

9. Korzystanie z OpenDKIM

OpenDKIM to implementacja DKIM typu open source, którą można wdrożyć na własnym serwerze pocztowym w celu podpisywania i weryfikacji wychodzących wiadomości e-mail. W przypadku korzystania z samodzielnie hostowanej konfiguracji OpenDKIM usługa zazwyczaj komunikuje się z serwerem pocztowym przez port 8891.

Aby upewnić się, że OpenDKIM działa poprawnie, możesz skorzystać z internetowego narzędzia do sprawdzania portów i zweryfikować, czy port 8891 jest otwarty i dostępny na Twoim serwerze. Należy również sprawdzić, czy wymagane uprawnienia są poprawnie skonfigurowane. Nieprawidłowe uprawnienia mogą uniemożliwić OpenDKIM dostęp do gniazda lub prawidłowe nawiązanie połączenia z nim.

Sprawdź konfigurację serwera oraz katalog zawierający gniazdo OpenDKIM, aby upewnić się, że katalog ten istnieje i ma odpowiednie prawa własności oraz uprawnienia.

10. Sprawdzenie DKIM pod kątem błędu dopasowania

Jeśli masz DMARC dla swojej domeny oprócz DKIM, podczas sprawdzania DKIMwartość domeny w polu d= podpisu DKIM w nagłówku wiadomości e-mail musi być zgodna z domeną znalezioną w adresie nadawcy. Może to być zgodność ścisła, w której obie domeny muszą być dokładnie takie same, lub zgodność luźna, która pozwala na dopasowanie organizacyjne w celu przejścia kontroli. 

Błąd DKIM może wystąpić, jeśli domena w nagłówku podpisu DKIM nie zgadza się z domeną podaną w nagłówku „From”, co może być typowym przypadkiem fałszowania domeny lub ataku polegającego na podszywaniu się. 

Wyjaśnienie błędów DKIM (według komunikatów o błędach)

Znajdź poniżej swój konkretny błąd, aby dowiedzieć się, jaki problem wystąpił na serwerze odbiorczym i jak go rozwiązać.

dkim=fail (nie udało się zweryfikować skrótu treści wiadomości)

Błąd „dkim=fail” (nie udało się zweryfikować skrótu treści) oznacza, że klucz publiczny został pomyślnie pobrany z serwera DNS, a ogólny nagłówek podpisu miał prawidłowy format, jednak skrót kryptograficzny treści wiadomości obliczony przez odbiorcę nie zgadza się ze skrótem zapisanym w tagu „bh=” podpisu.

Mówiąc prościej, treść wiadomości e-mail została zmodyfikowana po tym, jak serwer wysyłający ją podpisał.

Główne przyczyny:

• Bramki bezpieczeństwa wychodzące, narzędzia do generowania zastrzeżeń prawnych lub wtyczki CRM dodawały zastrzeżenia prawne, stopki promocyjne lub piksele śledzące po zakończeniu procesu podpisywania.
• Przekaźniki pośrednie modyfikowały podczas przesyłania znaki końca linii, zestawy znaków lub spacje.
• Oprogramowanie do przekierowywania wiadomości e-mail lub obsługi list mailingowych zmodyfikowało treść wiadomości.

Jak to naprawić:

1. Zmień kolejność przetwarzania wychodzących wiadomości tak, aby podpisywanie DKIM odbywało się jako absolutnie ostatni etap przed opuszczeniem infrastruktury sieciowej przez wiadomość, co zapewni, że wszystkie stopki i linki śledzące zostaną dodane przed podpisaniem.
2. Upewnij się, że serwer pocztowy korzysta z łagodnej kanonizacji treści wiadomości (c=relaxed/relaxed lub c=relaxed/simple), która toleruje niewielkie różnice w rozmieszczeniu spacji i znaków końca linii podczas przesyłania wiadomości.
3. Jeśli w nagłówkach DKIM używasz tagu l= (długość), usuń go. Tag l= ogranicza zakres treści podlegającej podpisaniu i stwarza luki w zabezpieczeniach, a jednocześnie nie rozwiązuje problemów związanych z modyfikacją treści.

dkim=fail (brak klucza do podpisu)

Błąd „dkim=fail” (brak klucza do podpisu) pojawia się, gdy serwer odbiorczy wyodrębnia domenę (d=) i selektor (s=) z nagłówka DKIM-Signature wiadomości e-mail i próbuje wysłać zapytanie do serwera DNS pod adresem s=._domainkey.d=, ale nie udaje mu się pobrać prawidłowego rekordu klucza publicznego.

Ten błąd pozwala zawęzić problem konkretnie do konfiguracji DNS lub nieprawidłowego dopasowania selektorów.

Główne przyczyny:

• Nazwa selektora podana przez aplikację wysyłającą nie zgadza się z prefiksem selektora opublikowanym w systemie DNS.
• Rekord TXT lub CNAME nigdy nie został opublikowany na serwerze DNS pełniącym rolę serwera autorytatywnego.
• Rekord DKIM został opublikowany niedawno i nie rozprzestrzenił się jeszcze w pełni wśród globalnych serwerów DNS.
• Rekord klucza publicznego został przypadkowo usunięty podczas migracji domeny lub czyszczenia kluczy.

Jak to naprawić:

1. Sprawdź surowy nagłówek wiadomości e-mail, aby zidentyfikować dokładny ciąg selektora w tagu „s=”.
2. Sprawdź, czy pod adresem selector._domainkey.yourdomain.com istnieje rekord DNS typu TXT lub CNAME (instrukcje dotyczące lokalizowania ciągów selektorów znajdziesz w naszym szczegółowym przewodniku pt. jak znaleźć swój selektor DKIM).
3. Należy sprawdzić, czy rekord DNS zawiera obowiązkowe tagi v=DKIM1; oraz k=rsa; (lub k=ed25519;) wraz z treścią klucza publicznego p=.

dkim=fail (nie udało się zweryfikować podpisu)

W przeciwieństwie do błędu związanego z treścią wiadomości, błąd „dkim=fail” (nie udało się zweryfikować podpisu) oznacza, że nie powiodła się kryptograficzna weryfikacja głównego ciągu podpisu (tag „b=”). Odbiorca pobrał klucz publiczny z serwera DNS, ale klucz ten nie zdołał odszyfrować i zweryfikować treści podpisu nagłówka.

Ten błąd wskazuje bezpośrednio na nieprawidłową parę kluczy lub zmodyfikowane pola nagłówka.

Główne przyczyny:

• Niezgodność pary kluczy: Klucz prywatny użyty przez serwer wysyłający do podpisania wiadomości nie zgadza się z kluczem publicznym opublikowanym w systemie DNS pod tym selektorem.
• Skrócony klucz DNS: Klucz o długości 2048 bitów został nieprawidłowo opublikowany jako pojedynczy ciąg znaków o długości ponad 255 bajtów, co spowodowało, że serwer DNS skrócił dane klucza publicznego.
• Modyfikacja nagłówków: Pośredni serwer pocztowy lub brama zmieniły nagłówki wyraźnie zawarte w tagu h= podpisu (takie jak „From”, „To”, „Subject” lub „Date”) po wygenerowaniu podpisu.

Jak to naprawić:

1. Sprawdź, czy rekord klucza publicznego o długości 2048 bitów w systemie DNS został prawidłowo podzielony na kilka ciągów znaków w cudzysłowie, z których każdy ma długość poniżej 255 bajtów.
2. Upewnij się, że klucz prywatny na serwerze pocztowym odpowiada opublikowanemu kluczowi publicznemu. W razie wątpliwości wygeneruj nową parę kluczy, zaktualizuj zapisy DNS i sprawdź, czy klucze są zgodne.
3. Należy zadbać o to, aby urządzenia zabezpieczające pośredniczące nie modyfikowały podpisanych pól nagłówka podczas przesyłania.

Błąd DKIM typu „soft fail”

W procesie uwierzytelniania wiadomości e-mail „soft fail” nie jest natywnym statusem protokołu DKIM. Podczas gdy SPF wyraźnie definiuje wynik SoftFail (~all), RFC 6376 definiuje wyniki DKIM wyłącznie jako pass, fail, policy, neutral, temperror lub permerror.

Gdy administratorzy lub narzędzia zabezpieczające pocztę elektroniczną zgłaszają „miękki błąd DKIM”, zazwyczaj mają na myśli jedną z dwóch sytuacji:

1. Ocena DMARC przy ustawieniu p=none: Wiadomość nie przeszła uwierzytelniania DKIM, ale ponieważ polityka DMARC właściciela domeny jest ustawiona w trybie monitorowania (p=none), dostawca skrzynki odbiorczej dostarcza wiadomość e-mail do skrzynki odbiorczej, oznaczając jednocześnie wewnętrzny status oceny jako „miękki błąd”.
2. Klasyfikacja specyficzna dla bramy: Bramki zabezpieczające pocztę (takie jak Cisco Secure Email lub Mimecast) czasami generują wewnętrzne etykiety diagnostyczne, np. „soft fail”, gdy wiadomość e-mail nie przechodzi weryfikacji DKIM, ale spełnia wymagania SPF przy prawidłowym dostosowaniu DMARC, co oznacza, że ogólnie rzecz biorąc, wiadomość może zostać dostarczona.

Jeśli w logach natrafisz na oznaczenie „soft fail”, potraktuj je jako standardowy błąd DKIM i sprawdź nagłówki pod kątem odpowiedniego ciągu błędu zgodnego z RFC (nie udało się zweryfikować skrótu treści lub brak klucza do podpisu).

Inne błędy DKIM, które mogą się pojawić

Serwery odbierające pocztę mogą również wysyłać następujące standardowe kody diagnostyczne DKIM w nagłówkach „Authentication-Results”:

DKIM nie przeszedł, ale SPF przeszedł (oraz inne mieszane wyniki)

Podczas analizowania raportów dotyczących dostarczalności wiadomości e-mail często można natknąć się na sytuacje, w których wyniki protokołów są ze sobą sprzeczne. Zrozumienie, w jaki sposób bramy odbiorcze oceniają te kombinacje, ma kluczowe znaczenie dla rozwiązywania problemów.

Zgodnie ze specyfikacją DMARC (RFC 7489) wiadomość e-mail przechodzi ogólną weryfikację DMARC, o ile przynajmniej jeden z protokołów bazowych (SPF lub DKIM) uzyska status „PASS” oraz jest prawidłowo dopasowany do domeny podanej w widocznym nagłówku „From:”.

Oto, w jaki sposób rozstrzygane są typowe kombinacje protokołów podczas dostarczania:

Dlaczego moja wiadomość została zablokowana z powodu DKIM?

Jeśli test SPF zakończył się powodzeniem, ale Twoja wiadomość nadal jest blokowana lub oznaczana jako spam z powodu niepowodzenia testu DKIM, oznacza to, że ma miejsce jedna z dwóch sytuacji:

1. Brak zgodności SPF: Sprawdzanie SPF zakończyło się powodzeniem dla domeny serwera strony trzeciej (np. mail.mcsv.net), ale nie pasowało do rzeczywistej domeny w nagłówku „From:”. Ponieważ nie udało się dopasować SPF, a weryfikacja DKIM zakończyła się całkowitą porażką, weryfikacja DMARC zakończyła się niepowodzeniem.
2. Rygorystyczne egzekwowanie zasad przez dostawców: Główni odbiorcy, tacy jak Google i Microsoft, stosują rygorystyczne zasady bezpieczeństwa wobec nadawców masowych wiadomości. Jeśli wiadomość e-mail wykazuje strukturalne błędy uwierzytelniania oraz wysokie wskaźniki skarg dotyczących spamu, algorytmy odbiorców mogą zablokować wiadomość, nawet jeśli częściowo spełnia ona wymagania.

Aby zrozumieć, w jaki sposób egzekwowanie zasad wpływa na wiadomości e-mail niezgodne z wymogami, zapoznaj się z naszym przewodnikiem na temat tego, czym jest polityka DMARC i przetestuj swoją domenę za pomocą naszego bezpłatnego narzędzia do sprawdzania rekordów DMARC.

Jak odczytywać wyniki DKIM w nagłówkach wiadomości e-mail

Aby zidentyfikować konkretny komunikat o błędzie, należy sprawdzić surowe nagłówki internetowe dostarczonej wiadomości e-mailowej służącej do testów.

Krok 1: Otwórz nagłówki w formacie surowym w swoim kliencie pocztowym

• Gmail: Otwórz wiadomość, kliknij trzy pionowe kropki obok przycisku „Odpowiedz” i wybierz opcję „Pokaż oryginał”.
• Microsoft Outlook (wersja internetowa): Otwórz wiadomość, kliknij trzy kropki na pasku akcji, wybierz opcję „Widok”, a następnie kliknij „Wyświetl szczegóły wiadomości”.
• Apple Mail: Otwórz wiadomość e-mail, kliknij opcję „Widok” na górnym pasku menu, najedź kursorem na pozycję „Wiadomość” i wybierz opcję „Surowe źródło”.

Krok 2: Znajdź nagłówek „Authentication-Results”

Przejrzyj surowy tekst nagłówka, aby znaleźć blok „Authentication-Results”. Poszukaj wpisu „dkim=”.

Typowy wpis w nagłówku wskazujący na błąd wygląda następująco:

Wyniki uwierzytelniania: mx.google.com;
dkim=niepowodzenie (nie udało się zweryfikować skrótu treści) [email protected] header.s=s1 header.b=W8xKz2L;
spf=pass (google.com: domena [email protected] wskazuje adres 192.0.2.1 jako dozwolonego nadawcę) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Najważniejsze tagi nagłówkowe, które należy sprawdzić:

• dkim=: Wyświetla status bieżącej weryfikacji (powodzenie, niepowodzenie, błąd stały itp.), a po nim w nawiasach konkretny ciąg znaków opisujący błąd.
• header.i=: Wyświetla tożsamość/domenę, która podpisała wiadomość e-mail.
• header.s=: Określa dokładny selektor używany do pobrania klucza publicznego z serwera DNS.
• header.d=: Wskazuje domenę organizacyjną przyjmującą odpowiedzialność za podpis.

Ręczne sprawdzanie surowych nagłówków wiadomości e-mail może być skomplikowane, czasochłonne i ogólnie uciążliwe. Możesz pominąć te etapy, korzystając z naszego bezpłatnego narzędzia do analizy nagłówków wiadomości e-mail , które zapewnia natychmiastowy, czytelny dla człowieka wgląd w wyniki uwierzytelniania SPF, DKIM i DMARC. 

Jak naprawić błędy DKIM i zapobiegać ich ponownemu wystąpieniu

Postępuj zgodnie z poniższym systematycznym schematem działań naprawczych, aby rozwiązać problemy związane z DKIM w całej infrastrukturze wysyłkowej:

1. Sprawdź poprawność klucza publicznego w systemie DNS

Skorzystaj z internetowego narzędzia do wyszukiwania, takiego jak nasze Wyszukiwanie rekordów DKIM , aby sprawdzić klucz publiczny opublikowany pod adresem selector._domainkey.yourdomain.com.

• Upewnij się, że nie ma błędów składniowych, literówek ani podwójnych średników.
• Sprawdź, czy klucz został poprawnie podzielony na fragmenty: w przypadku korzystania z klucza 2048-bitowego upewnij się, że edytor DNS podzielił treść na segmenty tekstowe ujęte w cudzysłowy, zawierające mniej niż 255 znaków (np. „v=DKIM1; k=rsa; p=part1…” „part2…”). Nigdy nie twórz oddzielnych rekordów TXT dla tego samego selektora.

2. Przeniesienie podpisywania DKIM do ostatniego węzła w sieci wychodzącej

Jeśli Twoja organizacja kieruje wiadomości e-mail przez dodatkowe bramy bezpieczeństwa, narzędzia do umieszczania zastrzeżeń prawnych lub rozwiązania CRM, upewnij się, że podpisywanie DKIM odbywa się po tym, jak narzędzia te wprowadzą swoje zmiany. Jeśli urządzenie musi modyfikować treść, skonfiguruj je tak, aby wykonywało końcowy etap podpisywania DKIM w imieniu Twojej domeny.

3. Zaktualizuj ustawienia kanonizacji

Zmień ustawienia kanonizacji serwera pocztowego na „relaxed/relaxed” (lub „c=relaxed/relaxed” w nagłówku DKIM). Spowoduje to, że serwery odbierające pocztę znormalizują spacje, spacje końcowe oraz formatowanie pól nagłówkowych przed ponownym obliczeniem skrótu, co zapobiegnie fałszywym błędom weryfikacji spowodowanym drobnymi zmianami podczas przesyłania.

4. Zapewnienie zgodności par kluczy podczas rotacji

Podczas rotacji kluczy DKIM należy zawsze najpierw opublikować nowy klucz publiczny w systemie DNS pod nową nazwą selektora. Przed skonfigurowaniem serwera pocztowego tak, aby podpisywał wiadomości nowym kluczem prywatnym, należy odczekać od 24 do 48 godzin na propagację zmian w systemie DNS. Po zakończeniu migracji należy pozostawić stary wpis klucza publicznego w systemie DNS przez kilka dni, aby wiadomości znajdujące się w tranzycie lub w kolejce, podpisane starym selektorem, mogły nadal zostać zweryfikowane.

Należy pamiętać, że omówiliśmy niektóre typowe komunikaty o błędach DKIM oraz ich prawdopodobne przyczyny, podając jednocześnie możliwe rozwiązania. Jednak błędy mogą pojawiać się z różnych przyczyn, specyficznych dla danej domeny i serwerów, które nie zostały omówione w niniejszym artykule. 

Przed wdrożeniem protokołów uwierzytelniania w swojej organizacji lub wprowadzeniem odpowiednich zasad należy odpowiednio poszerzyć swoją wiedzę na ich temat. Błąd w weryfikacji DKIM, SPF lub DMARC może negatywnie wpłynąć na dostarczalność wiadomości e-mail. 

Najczęściej zadawane pytania

Co oznacza komunikat „nie udało się zweryfikować skrótu pliku”?

„Nie udało się zweryfikować skrótu treści” oznacza, że klucz publiczny został znaleziony w systemie DNS, a format nagłówka był poprawny, jednak treść wiadomości uległa zmianie po jej podpisaniu. Ponieważ treść została zmodyfikowana podczas przesyłania (w wyniku dodania zastrzeżeń, działania bramek zabezpieczających, ponownego kodowania lub przekazania dalej), skrót obliczony przez odbiorcę nie zgadzał się z oryginalnym skrótem zapisanym w tagu bh= podpisu.

Jak rozwiązać problem z błędem DKIM?

Aby rozwiązać problem związany z niepowodzeniem weryfikacji DKIM, należy zlokalizować dokładny ciąg błędu w nagłówku „Authentication-Results” wiadomości e-mail. Jeśli błąd dotyczy brakującego klucza (brak klucza do podpisu), należy opublikować lub skorygować rekord TXT klucza publicznego w systemie DNS pod właściwym selektorem. Jeśli błąd dotyczy niezgodności skrótu treści (skrót treści nie został zweryfikowany), dostosuj przepływ wiadomości tak, aby podpisywanie DKIM odbywało się jako ostatni krok po dodaniu wszystkich stopek i linków, a także ustaw kanonizację na „relaxed/relaxed”.

Co oznacza naruszenie DKIM?

„Naruszenie DKIM” to termin używany przez niektóre bramy bezpieczeństwa poczty elektronicznej w celu wskazania, że przychodząca wiadomość e-mail nie przeszła pomyślnie kontroli poprawności DKIM. Zazwyczaj oznacza to, że podpis kryptograficzny był nieprawidłowy, wiadomość została zmodyfikowana podczas przesyłania lub nadawca próbował podpisać wiadomość przy użyciu domeny, która nie pokrywa się z widocznym adresem nadawcy.

Czy błąd DKIM oznacza, że mój e-mail nie zostanie dostarczony?

Niekoniecznie. Jeśli Twoja domena posiada prawidłowy rekord SPF, który przechodzi weryfikację przy odpowiednim dostosowaniu DMARC, wiadomość e-mail w większości przypadków nadal przejdzie ogólną weryfikację DMARC i dotrze do skrzynki odbiorczej. Jednak poleganie wyłącznie na SPF sprawia, że dostarczalność wiadomości staje się zagrożona w przypadku ich przekazywania dalej. Ponadto, jeśli weryfikacja DMARC zakończy się niepowodzeniem w obu protokołach, a polityka domeny jest ustawiona na p=quarantine lub p=reject, wiadomość, która nie przeszła weryfikacji, zostanie dostarczona do folderu spam lub całkowicie odrzucona.

• O
• Latest Posts

Maitham Al Lawati

Ekspert ds. cyberbezpieczeństwa, dyrektor generalny w PowerDMARC

Maitham jest przedsiębiorcą technologicznym, ekspertem ds. cyberbezpieczeństwa, dyrektorem generalnym i założycielem PowerDMARC z ponad 15-letnim doświadczeniem w branży. Maitham posiada tytuł Global MBA Uniwersytetu w Manchesterze oraz różne certyfikaty zawodowe, w tym CISSP, CISM, CRISC i ISC2 CCSP.

Najnowsze posty autorstwa Maitham Al Lawati (zobacz wszystkie)

• Błąd DKIM: co oznacza każdy błąd i jak go naprawić – 13 września 2026 r.
• Metody uwierzytelniania wiadomości e-mail: w jaki sposób SPF, DKIM i DMARC chronią Twoją domenę – 9 sierpnia 2026 r.
• Czym jest polityka DMARC? Brak, Kwarantanna i Odrzucenie – 27 lipca 2026 r.