Jak naprawić błędy „Podpis DKIM jest nieprawidłowy” i „Skrót treści nie został zweryfikowany”

Jeśli pojawił się błąd „Podpis DKIM jest nieprawidłowy”, oznacza to, że w konfiguracji DKIM wystąpił problem, który należy naprawić. Błędy te wynikają zazwyczaj z nieprawidłowego wpisu rekordu DNS DKIM, opóźnień w propagacji DNS, błędów podczas weryfikacji podpisu DKIM lub zmian wprowadzonych w wiadomości po jej podpisaniu. 

W niniejszym przewodniku omówiono poszczególne przyczyny i sposoby ich usunięcia, a także poświęcono osobną sekcję ściśle powiązanemu błędowi „Nie zweryfikowano skrótu treści podpisu DKIM”, który wskazuje na konkretny i bardzo łatwy do usunięcia problem.

Informacje o podpisach DKIM

DKIM dodaje podpis kryptograficzny do nagłówków wiadomości e-mail, a serwer odbiorczy porównuje ten podpis z kluczem publicznym opublikowanym w Twoim systemie DNS. Jeśli te dwa elementy nie są zgodne, pojawia się błąd „Podpis DKIM jest nieprawidłowy”. Pełne wyjaśnienie działania tego protokołu znajdziesz w naszym przewodniku na temat czym jest DKIM.

Ponieważ większość osób, u których pojawia się ten błąd, ma już skonfigurowany DKIM i musi jedynie naprawić to, co przestało działać, dalsza część tej strony skupia się raczej na diagnozowaniu i usuwaniu problemów niż na podstawowych zagadnieniach.

Kiedy może wystąpić błąd DKIM z komunikatem „Twój podpis DKIM jest nieprawidłowy”?

Komunikat „Twój podpis DKIM jest nieprawidłowy” pojawi się, gdy weryfikacja uwierzytelniania DKIM zakończy się niepowodzeniem. Oto najczęstsze przyczyny:

• Domena podpisu DKIM i domena nadawcy nie są zgodne.
• Rekord klucza publicznego DKIM opublikowany w systemie DNS jest nieprawidłowy.
• Rekord klucza publicznego DKIM nie jest w ogóle publikowany w systemie DNS.
• Serwer nie może nawiązać połączenia ze strefą DNS domeny nadawcy w celu wyszukania adresu — jest to częsta sytuacja w przypadku niewiarygodnych dostawców usług hostingowych.
• Długość klucza DKIM jest niewystarczająca. Współcześni dostawcy oczekują kluczy o długości 2048 bitów, a starsze klucze 1024-bitowe budzą coraz większą nieufność, natomiast klucze bardzo krótkie są od razu odrzucane.
• Wiadomość została zmodyfikowana podczas automatycznego przekazywania.

Wszystkie te problemy, z wyjątkiem ostatniego, to kwestie techniczne, które możesz rozwiązać samodzielnie. Sytuacja z przekazywaniem wiadomości wygląda inaczej, ponieważ nie masz wpływu na to, czy serwer odbiorcy doda stopkę zgodności lub w inny sposób zmodyfikuje treść wiadomości. Co więc się stanie, gdy te automatycznie przekazane wiadomości nie spełnią wymagań zarówno SPF, jak i DKIM, a Twoja polityka DMARC jest ustawiona na odrzucanie?

Kiedyś stanowiło to prawdziwy problem dla serwerów odbiorczych próbujących obsłużyć legalną, ale nieautoryzowaną pocztę przekazaną dalej. Obecnym rozwiązaniem tymczasowym jest protokół Authenticated Received Chain (ARC), który pozwala każdemu serwerowi pocztowemu w łańcuchu rejestrować wyniki uwierzytelnienia, które zaobserwował, dzięki czemu ostateczny odbiorca może nadal rozpoznać, że wiadomość została uwierzytelniona przed jej przekazaniem. ARC zawsze było jednak eksperymentalnym rozwiązaniem, a branża obecnie odchodzi od jego stosowania. W oddzielnym projekcie IETF z kwietnia 2026 r. zaproponowano przeklasyfikowanie ARC jako standardu historycznego, ponieważ wnioski z jego stosowania są włączane do DKIM2, nowej wersji DKIM opracowywanej w ramach IETF (draft-ietf-dkim-dkim2-spec), która rozwiązuje problem przekazywania wiadomości w ramach samego protokołu, zamiast nakładać na niego dodatkowy mechanizm. Zamiast prosić odbiorców o zaufanie do relacji pośrednika na temat tego, co zaobserwował, DKIM2 wymaga, aby każdy węzeł rejestrował dokładnie to, co zmienił, w postaci odwracalnej instrukcji, dzięki czemu weryfikator może cofnąć te zmiany i ponownie sprawdzić podpis pierwotnego nadawcy. Proces ten wciąż jest w trakcie standaryzacji, więc ARC pozostaje obecnie praktycznym rozwiązaniem, ale warto wiedzieć, że prawdziwe rozwiązanie problemu przekazywania jest już w drodze.

Jak naprawić błąd „Podpis DKIM jest nieprawidłowy”

Nawet jeśli rekordy DKIM są już skonfigurowane, nadal może pojawiać się błąd dotyczący nieprawidłowego podpisu. Poniżej przedstawiono sposoby rozwiązania tego problemu, dostosowane do poszczególnych przyczyn wymienionych powyżej.

Rozwiązanie 1: Rozwiązywanie problemów związanych z nieprawidłowymi wpisami DNS dotyczącymi DKIM

Po utworzeniu rekordu TXT DKIM i dodaniu go do konfiguracji DNS błąd dotyczący nieprawidłowego podpisu często wynika z błędu w tym rekordzie. Aby go znaleźć:

• Skorzystaj z funkcji PowerDMARC funkcji wyszukiwania DKIM , aby sprawdzić swój rekord.

• Wprowadź nazwę domeny i selektor lub pozostaw pole selektora puste, aby platforma wykryła go automatycznie, a następnie kliknij „Sprawdź”.

• Narzędzie to analizuje wpis DNS DKIM i wskazuje wszelkie błędy w składni rekordu.

Aby poprawić ten rekord, zaloguj się do cPanel lub innej używanej przez Ciebie konsoli do zarządzania DNS, otwórz „Zaawansowany edytor stref DNS” w sekcji „Domeny”, wybierz swoją domenę, przejdź do opcji „Edytuj rekordy DNS”, popraw wartość rekordu DKIM i zapisz zmiany.

Rozwiązanie 2: Poczekaj, aż miną opóźnienia związane z propagacją DNS

Błędy mogą pojawić się również zaraz po zmianie ustawień DNS. Jest to normalne: propagacja DNS trwa od 24 do 48 godzin, a dokładny czas zależy od wartości TTL ustawionej w rekordzie. Należy poczekać kilka dni na pełną propagację, a w międzyczasie śledzić status za pomocą naszego narzędzia do sprawdzania propagacji DNS.

Rozwiązanie 3: Dopasuj domenę podpisu DKIM do domeny nadawczej

Otwórz nagłówek „DKIM-Signature” w wiadomości, która nie przeszła weryfikacji, i sprawdź wartość wartość d= z widocznym adresem nadawcy. Jeśli wartości te nie są zgodne, usługa wysyłająca podpisuje wiadomość przy użyciu własnej domeny zamiast Twojej, co powoduje niezgodność i niepowodzenie weryfikacji. Aby to naprawić, należy skonfigurować tę usługę tak, aby podpisywała wiadomości przy użyciu Twojej domeny. Większość platform pocztowych posiada ustawienie „niestandardowy DKIM” lub „uwierzytelnij swoją domenę” przeznaczone właśnie do tego celu, a nasz przewodnik dotyczący jak skonfigurować DKIM opisuje ten proces.

Rozwiązanie 4: Odnowienie klucza, który jest zbyt krótki

Jeśli Twój dostawca nadal stosuje klucz o długości 1024 bitów (lub krótszy), wygeneruj nowy o długości 2048 bitów – jest to aktualny standard wymagany przez Google i innych głównych dostawców. Nową parę kluczy możesz wygenerować w konsoli administracyjnej swojego dostawcy usług e-mail (ESP) lub za pomocą naszego generatora DKIM, opublikować nowy klucz publiczny w systemie DNS i sprawdzić, czy jest on poprawnie rozpoznawany, korzystając z naszego narzędzia do sprawdzania rekordów DKIM.

Rozwiązanie 5: Rozwiązanie problemu z serwerem DNS, z którym nie można się połączyć

Jeśli serwer odbierający nie może połączyć się z Twoim serwerem DNS w celu wyszukania klucza publicznego, weryfikacja DKIM zakończy się niepowodzeniem, niezależnie od tego, jak dobrze skonfigurowano pozostałe elementy. Sprawdź dostępność swojego rekordu za pomocą narzędzia do sprawdzania propagacji DNS. Jeśli serwer DNS Twojego dostawcy usług hostingowych działa wolno lub jest zawodny, rozważ przeniesienie hostingu DNS do dedykowanego dostawcy, takiego jak Cloudflare lub Amazon Route 53.

Rozwiązanie 6: Obsługa wiadomości zmodyfikowanych podczas automatycznego przekazywania

Modyfikacje podczas przekazywania wiadomości powodują naruszenie poprawności DKIM, a nie zawsze istnieje możliwość naprawy tego problemu po stronie nadawcy. Jeśli zarządzasz serwerem przekazującym, włącz podpisywanie ARC (a w usłudze Microsoft 365 dodaj renomowanych nadawców do listy zaufanych podmiotów podpisujących ARC w usłudze Defender), aby legalne przekazywane wiadomości nie były odrzucane. Jeśli nie zarządzasz tym serwerem, jest to oczekiwane zachowanie, a nie błąd konfiguracji: Twoje raporty zbiorcze DMARC będą wykazywać te niepowodzenia, a właściwym posunięciem jest uwzględnienie ich w polityce i dalsze monitorowanie sytuacji, zamiast ścigania wszystkich.

Note: ARC is a temporary fix and not a permanent solution. DKIM2 is being designed to fix forwarding at the protocol level, so this whole category of failure should shrink as it rolls out. Keep any existing ARC setup running to support legacy gateways in the meantime, but there's little reason to invest heavily in new ARC engineering now.

Dlaczego pojawia się komunikat "DKIM-Signature Body Hash Not Verified"?

Błąd „DKIM-signature body hash not verified” oznacza, że skrót treści wiadomości obliczony przez serwer odbiorczy nie zgadza się z wartością zapisaną w tagu „bh=” nagłówka DKIM-Signature. Mówiąc prościej, treść wiadomości e-mail sprawdzona przez odbiorcę nie jest identyczna z treścią, którą podpisał Twój serwer. Coś zmieniło treść wiadomości w trakcie przesyłania.

Warto to dokładnie zrozumieć, ponieważ jest to irytująco powszechne zjawisko i zazwyczaj oznacza, że konfiguracja DKIM jest poza tym poprawna. Sprawdzanie skrótu treści odbywa się przed pełną weryfikacją podpisu, więc gdy skrót treści nie przejdzie pomyślnie, cała ocena DKIM kończy się niepowodzeniem, a odbiorca nawet nie przejdzie do weryfikacji samego podpisu kryptograficznego.

Najczęstsze przyczyny awarii modułów Body Hash

• Brama pocztowa lub filtr dodały treść po podpisaniu DKIM: Zastrzeżenia, stopki prawne, piksele śledzące, bloki rezygnacji z subskrypcji, banery antywirusowe oraz stopki marketingowe wstawione przez bramkę wychodzącą po podpisaniu wiadomości zmieniają treść wiadomości i powodują uszkodzenie skrótu. Jest to najczęstsza przyczyna tego problemu.
• Treść wiadomości została zmodyfikowana przez listę mailingową lub serwer przekazujący: Oprogramowanie listy mailingowej rutynowo dołącza stopki dotyczące rezygnacji z subskrypcji lub zmienia temat wiadomości, a serwery przekazujące mogą usuwać lub dodawać nagłówki. Oba te procesy zmieniają podpisane treści.
• Niezgodność kodowania znaków lub znaków końca linii: Jeśli wiadomość została podpisana przy użyciu jednego kodowania (na przykład UTF-8 z oznaczeniem kolejności bajtów), a serwer odbiorczy interpretuje ją inaczej, lub jeśli gdzieś podczas przesyłania znaki końca linii zmieniają się z CRLF na LF, zawartość na poziomie bajtów przestaje się zgadzać, a weryfikacja skrótu kończy się niepowodzeniem.
• Podpisywanie DKIM odbywa się zbyt wcześnie w procesie wysyłania wiadomości: Jest to główna przyczyna większości powyższych problemów. Jeśli system podpisuje wiadomość, zanim komponent znajdujący się dalej w łańcuchu przetwarzania ją zmodyfikuje, weryfikacja skrótu treści będzie za każdym razem kończyć się niepowodzeniem.
• Nieprawidłowy lub obrócony klucz prywatny: Jeśli klucz podpisujący nie jest już zgodny z kluczem publicznym opublikowanym w DNS, weryfikacja kończy się niepowodzeniem.

Jak zdiagnozować awarię modułu Body Hash

Wykonaj poniższe kroki, aby zawęzić obszar, w którym występuje modyfikacja:

1. Wyślij tę samą wiadomość testową na adresy w serwisach Gmail, Outlook lub Hotmail oraz na jedną skrzynkę wewnętrzną. Treść, linki i trasa przesyłania muszą być identyczne we wszystkich trzech przypadkach.
2. Sprawdź nagłówek „Authentication-Results” na każdym komputerze odbiorczym. Jeśli skróty treści nie są poprawne na wszystkich trzech komputerach, problem leży po stronie nadawcy. Jeśli nie są poprawne tylko na jednym (najczęściej winowajcą jest program Outlook), przyczyną jest raczej struktura MIME lub kodowanie znaków niż konfiguracja podpisu.
3. Sprawdź kolejność przetwarzania wiadomości i upewnij się, czy podpisywanie DKIM odbywa się przed czy po wprowadzeniu jakichkolwiek zmian w treści wiadomości wychodzących.
4. Sprawdź rekord DNS DKIM, upewniając się, że selektor i klucz publiczny są zgodne z danymi zawartymi w nieprawidłowym podpisie, korzystając z naszego narzędzia do wyszukiwania rekordów DKIM.
5. Wyślij wiadomość testową w postaci zwykłego tekstu, bez śledzenia, stopki ani załączników. Jeśli ta wiadomość dotrze tam, gdzie nie dociera Twoja zwykła poczta, oznacza to, że metodą eliminacji zidentyfikowałeś przyczynę problemu.

Jak naprawić błędy związane z hashami ciała

• Podpisz wiadomość na końcu, po każdej zmianie treści: Jest to najczęstsze i najskuteczniejsze rozwiązanie. Zmień kolejność z „napisz, podpisz DKIM, dodaj zastrzeżenie, wyślij” na „napisz, dodaj zastrzeżenie, podpisz DKIM, wyślij”, tak aby podpisywać dokładnie tę wiadomość, którą otrzyma odbiorca.
• Skonfiguruj bramy wychodzące tak, aby nie modyfikowały treści wiadomości: Lub ustaw je tak, aby ponownie podpisywały wiadomości za pomocą DKIM po zakończeniu wprowadzania zmian.
• Ujednolicaj kodowanie do formatu UTF-8 bez znacznika kolejności bajtów i zachowaj spójność znaków końca linii CRLF na całej ścieżce przesyłania. Ma to największe znaczenie w środowiskach Exchange i Microsoft 365.
• Użyj kanonizacji łagodnej (c=relaxed/relaxed): Pozwala to na pominięcie drobnych różnic w spacji i formatowaniu, które w przeciwnym razie spowodowałyby nieprawidłowość podpisu przy ścisłej „prostej” kanonizacji. Nie uratuje to podpisu w przypadku dodania całego zastrzeżenia lub stopki, ale eliminuje błędy spowodowane nieistotnymi zmianami formatowania.

Błędy związane z hashem treści wiadomości w programach Outlook i Microsoft 365

Często powtarzającym się problemem, o którym pełne są fora pomocy technicznej samej firmy Microsoft, jest sytuacja, w której wiadomość przechodzi weryfikację DKIM w serwisach Gmail i Yahoo, ale nie przechodzi jej w programach Outlook lub Hotmail. Zazwyczaj dotyczy to wiadomości zawierających załączniki lub osadzone obrazy i wskazuje raczej na sposób, w jaki system Microsoftu obsługuje strukturę MIME oraz kodowanie znaków, a nie na problem z konfiguracją podpisu.

Najprostszym sposobem potwierdzenia tego jest porównanie nagłówka „Authentication-Results” tej samej wiadomości u obu odbiorców. Wyniki pozytywne i negatywne wyglądają następująco:

Brak

# W Gmailu (przechodzi)

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1;
spf=pass; dmarc=pass

# W programie Outlook (błąd przy tej samej wiadomości)

Authentication-Results: protection.outlook.com;
dkim=fail (body hash did not verify)
header.d=yourdomain.com header.s=selector1;
spf=pass; dmarc=fail (p=none)

Gdy zauważysz błąd DKIM, najszybszym sposobem na zrozumienie sytuacji jest zapoznanie się z nagłówkami uwierzytelniającymi samej wiadomości, zamiast zgadywać, co mogło być przyczyną.

Jak odczytać nagłówek „Authentication-Results”

W Gmailu otwórz wiadomość, kliknij menu z trzema kropkami i wybierz opcję „Pokaż oryginał”. Znajdź nagłówek „Authentication-Results” i poszukaj wyniku „dkim=”. Będzie on brzmiał „pass”, „fail” lub „neutral”, a po nim zazwyczaj pojawia się ciąg znaków opisujący przyczynę, np. „body hash did not verify”, „signature did not verify” lub „key too short”. Ten ciąg znaków wskazuje, z jaką kategorią problemu masz do czynienia, a tym samym, które z powyższych rozwiązań należy zastosować.

Podczas zapoznawania się z nagłówkiem warto zwrócić uwagę na tagi DKIM-Signature:

v= wersja DKIM (np. v=1)

a= algorytm podpisywania (np. a=rsa-sha256)

d= domena podpisująca (sprawdź, czy zgadza się z adresem nadawcy)

s= selektor służący do lokalizowania klucza publicznego w systemie DNS

h= nagłówki zawarte w podpisie

bh= hash treści (wartość, która powoduje błąd „niezweryfikowany hash treści”)

b= sam podpis kryptograficzny

Porównanie wartości d= z widoczną domeną „From” potwierdza zgodność, selektor s= wskazuje, który rekord DNS należy sprawdzić, a niezgodność bh= potwierdza, że treść została zmieniona po podpisaniu.

Jeśli okaże się, że nie rozpoznajesz nadawcy, sprawdź, czy znajduje się on na liście autoryzowanych nadawców, i porównaj go z raportów o błędach DMARC , aby sprawdzić, jakiego rodzaju wiadomości wysyła, oraz sprawdź, czy adres IP nie figuruje na żadnej czarnej liście. 

Jeśli nadawca jest wiarygodny, należy skonfigurować DMARC poprawnie, aby go autoryzować. Jeśli nie jest, to sygnał o fałszowaniu adresu, na który warto zareagować.

Naprawiłem błąd „Podpis DKIM jest nieprawidłowy”. Co dalej?

Aby wzmocnić konfigurację DKIM, wykonaj następujące czynności:

1. Zarejestruj się w naszym usługą Hosted DKIM , aby monitorować wyniki uwierzytelniania DKIM na bieżąco.
2. Włącz funkcje SPF i DMARC, aby zapewnić dodatkowe bezpieczeństwo i dokładniejsze uwierzytelnianie.
3. Aby zapewnić lepszą ochronę, należy okresowo zmieniać klucze DKIM.

Nadal nie mogę naprawić błędu

Jeśli błąd „Podpis DKIM jest nieprawidłowy” nadal występuje, skontaktuj się z dostawcą usług poczty elektronicznej w celu uzyskania pomocy lub skontaktuj się z nami w celu uzyskania fachowej porady dotyczącej wszystkich aspektów uwierzytelniania poczty elektronicznej.

Najczęściej zadawane pytania

Co oznacza komunikat „Nie zweryfikowano skrótu treści podpisu DKIM”? 

Oznacza to, że skrót treści wiadomości obliczony przez serwer odbierający nie zgadza się z wartością „bh=”, którą Twój serwer zapisał podczas podpisywania wiadomości. W praktyce oznacza to, że treść wiadomości e-mail została zmieniona po podpisaniu — najczęściej poprzez dodanie zastrzeżenia, stopki, piksela śledzącego lub modyfikacji wprowadzonej przez bramkę w dalszej części ścieżki wysyłania.

Dlaczego sprawdzanie skrótu treści wiadomości DKIM kończy się niepowodzeniem tylko w programie Outlook, a w Gmailu przebiega pomyślnie? 

Gdy wiadomość przechodzi pomyślnie przez Gmaila, ale nie dociera do Outlooka lub Hotmaila, przyczyną jest zazwyczaj sposób, w jaki system Microsoftu obsługuje strukturę MIME i kodowanie znaków, a nie konfiguracja podpisu. Problem ten pojawia się najczęściej w przypadku wiadomości z załącznikami lub osadzonymi obrazami. Porównaj surowy kod źródłowy w obu odbiorcach, ujednolicaj kodowanie transferowe i stosuj łagodną kanonizację.

Jak skonfigurować podpisywanie DKIM po dodaniu zastrzeżeń? 

Zmień kolejność przetwarzania wychodzących wiadomości tak, aby podpisywanie było ostatnim etapem powodującym zmianę treści. Zamiast najpierw podpisywać wiadomość, a dopiero potem dołączać zastrzeżenie, najpierw dołącz zastrzeżenie, a dopiero potem podpisz wiadomość. Można to osiągnąć, uruchamiając moduł podpisujący DKIM po filtrach treści oraz usługach dołączających zastrzeżenia lub podpisy, tak aby podpisywał on ostateczną wersję wiadomości, którą faktycznie otrzymuje odbiorca.

Jaka jest różnica między komunikatem „nie udało się zweryfikować skrótu treści” a komunikatem „nie udało się zweryfikować podpisu”? 

Komunikat „Body hash did not verify” oznacza, że treść wiadomości uległa zmianie po podpisaniu, więc rozwiązanie polega na poprawieniu treści lub przepływu poczty. Komunikat „Signature did not verify” ma szerszy zakres i często wskazuje na zmianę w podpisanym nagłówku, niezgodność klucza lub problem z DNS lub kluczem. Ciąg znaków „reason” w nagłówku „Authentication-Results” wskazuje, z którą z tych sytuacji mamy do czynienia.

Czy DKIM filtruje wiadomości e-mail? 

DKIM nie filtruje wiadomości e-mail bezpośrednio. Dostarcza sygnał potwierdzający poprawność lub nieprawidłowość, który serwery odbiorcze uwzględniają przy podejmowaniu decyzji dotyczących oceny spamu. Wiadomości z zaufanej domeny, które przejdą weryfikację DKIM, mogą uzyskać niższy wynik oceny spamu, natomiast niepowodzenie weryfikacji DKIM może przyczynić się do oznaczenia wiadomości jako spamu lub umieszczenia jej w kwarantannie.

Czy mogę zignorować błędy DKIM, jeśli dla DMARC ustawiono wartość p=none? 

Gdy ustawiono p=none, wiadomości z błędami są nadal dostarczane, więc błąd DKIM nie spowoduje natychmiastowego zablokowania żadnej wiadomości. Jednak ignorowanie tego faktu podważa sens dążenia do egzekwowania zasad i uniemożliwia zaufanie do własnych danych uwierzytelniających. Lepiej jest usunąć błędy, gdy ustawiono p=none, aby później móc bezpiecznie przejść do p=quarantine i p=reject.

Jak często należy zmieniać klucze DKIM? 

Powszechną praktyką jest rotacja kluczy co sześć miesięcy lub co rok. Regularna rotacja ogranicza szkody w przypadku ewentualnego ujawnienia klucza prywatnego. Istotne jest, aby w ramach rotacji zaktualizować opublikowany klucz publiczny w systemie DNS, ponieważ zaktualizowany klucz, który nie został odzwierciedlony w DNS, sam w sobie spowoduje błędy podpisywania.

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty elektronicznej w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• Wyrównanie SPF: co to jest i dlaczego jest potrzebne? - 28 lipca 2026 r.
• Przewodnik po konfiguracji DMARC dla Office 365 (2026) - 21 lipca 2026 r.
• Jak naprawić błędy „Podpis DKIM jest nieprawidłowy” i „Skrót treści nie został zweryfikowany” – 16 lipca 2026 r.