DKIM2: co zmienia i co oznacza dla nadawców

DKIM2, planowany następca standardu DKIM, który podpisuje i weryfikuje e-maile, osiągnął kolejny publiczny etap rozwoju. Grupa robocza IETF pracująca nad nowym standardem opublikowała 17 maja 2026 r. najnowszą wersję projektu specyfikacji i zmierza do formalnego zatwierdzenia w ciągu najbliższych 12-18 miesięcy. Ten artykuł wyjaśnia, co DKIM2 zmienia w podpisywaniu poczty, dlaczego IETF przebudowuje ten standard teraz oraz czego (jeśli czegokolwiek) ta zmiana wymaga od właścicieli domen korzystających dziś z DMARC.

DKIM (DomainKeys Identified Mail) informuje serwer pocztowy odbiorcy, czy wiadomość rzekomo wysłana z Twojej domeny nie została w trakcie transportu zmodyfikowana lub sfałszowana. To jeden z dwóch kryptograficznych mechanizmów, na których opiera się DMARC (drugim jest SPF). DKIM pełni rolę branżowego standardu podpisywania poczty od 2007 r. IETF otwarcie proponuje coś znacznie ambitniejszego niż łatka: pełne przeprojektowanie standardu, które rozwiązuje trzy problemy, których DKIM nigdy nie był w stanie naprawić samodzielnie.

Co znajdziesz w tym przewodniku

• Co robi DKIM i gdzie ma słabe punkty
• Co zmienia DKIM2
• Dlaczego IETF przebudowuje DKIM właśnie teraz?
• Jak wygląda Twój dzisiejszy rekord DKIM?
• Co to oznacza dla Ciebie
• Harmonogram wdrożenia DKIM2
• Podsumowanie

Co robi DKIM i gdzie ma słabe punkty

DKIM (DomainKeys Identified Mail, zdefiniowany w RFC 6376) działa poprzez dołączanie kryptograficznego podpisu do każdego wysyłanego e-maila. Domena nadawcy publikuje klucz publiczny w DNS, a serwer odbiorcy używa tego klucza, aby zweryfikować podpis. Jeśli podpis się zgadza, odbiorca może ufać dwóm rzeczom: że wiadomość została wysłana przez kogoś, kto ma dostęp do klucza prywatnego domeny, oraz że treść i wybrane nagłówki nie zostały zmodyfikowane w trakcie transportu.

Ten mechanizm ma trzy znane słabe punkty, a grupa robocza IETF DKIM udokumentowała wszystkie trzy w dokumencie motywacyjnym DKIM2 (draft-ietf-dkim-dkim2-motivation):

• Ataki typu replay działają przeciwko DKIM. Podpis DKIM jest ważny dla dowolnego odbiorcy. Spamer, który przechwyci jedną podpisaną wiadomość (z przejętego konta lub po zapisaniu się do newslettera z domeny o wysokiej reputacji), może rozesłać ją do milionów odbiorców, a każda kopia nadal przechodzi weryfikację DKIM. Cios w reputację przyjmuje pierwotna domena podpisująca.
• Listy mailingowe i serwery przekazujące psują podpis. Każdy pośrednik, który modyfikuje treść wiadomości, nawet w niewielkim stopniu (prefiks nazwy listy w temacie, stopka, zmiana kodowania transferu treści), unieważnia podpis DKIM. Odbiorca widzi błąd DKIM i często błąd DMARC, mimo że wiadomość jest prawdziwa.
• Zmiany wprowadzane przez pośredników nie zostawiają śladu w logach. Kiedy DKIM zawiedzie na przekazanej wiadomości, odbiorca nie ma żadnej możliwości na poziomie protokołu, aby ocenić, czy błąd spowodował uczciwy serwer przekazujący wprowadzający nieszkodliwą zmianę, czy też wrogi aktor manipulujący treścią.

Te słabe punkty widać w rzeczywistych danych uwierzytelniających. W raporcie branżowym DMARCeye za Q1 2026 wskaźniki błędów DKIM u dużych dostawców skrzynek pocztowych i w korporacyjnych systemach poczty są wysokie: 19,6% w Microsoft, 11,1% w Google, 26,3% w Proofpoint, 22,9% w Mailgun. Najlepsi w klasie nadawcy transakcyjni w tym samym zbiorze danych (Bird, Amazon SES, SendGrid) odnotowują wskaźniki błędów DKIM poniżej 1%. Różnica między tymi dwiema grupami jest operacyjną rzeczywistością, którą DKIM2 ma rozwiązać.

Jak zauważa sam raport za Q1, wysokie wskaźniki błędów u dużych dostawców skrzynek pocztowych prawie zawsze wynikają z błędnej konfiguracji po stronie klienta, a nie z wady samego dostawcy. Poczta wychodząca przez tenant Microsoft 365 lub Google Workspace przechodzi przez serwery przekazujące, listy mailingowe, zewnętrzne przekaźniki i starsze lokalne bramki. Każdy z tych elementów może zerwać podpis DKIM, a klient nawet nie zdaje sobie z tego sprawy.

Rozsądna hipoteza jest taka, że dedykowani nadawcy transakcyjni mają najczystsze wyniki, ponieważ ich cały biznes polega na wysyłaniu jednego rodzaju poczty przez jeden potok podpisujący. Z kolei dostawcy skrzynek pocztowych ogólnego przeznaczenia obsługują znacznie szerszą gamę przepływów pocztowych, których oryginalna specyfikacja DKIM nigdy nie była zaprojektowana, aby utrzymać w nienaruszonym stanie. Głębsza analiza wskaźników zgodności według dostawców usług e-mailowych omawia ten sam wzorzec od strony nadawcy.

Co zmienia DKIM2

DKIM2 zachowuje tę samą podstawową ideę - podpisywanie każdej wychodzącej wiadomości, aby odbiorca mógł zweryfikować, że pochodzi z Twojej domeny - ale przebudowuje sposób działania samego podpisywania. Aktualna wersja specyfikacji (draft-ietf-dkim-dkim2-spec-02, opublikowana 17 maja 2026 r. na ścieżce standardów) wprowadza cztery istotne zmiany.

Każdy serwer w łańcuchu dostarczania podpisuje wiadomość. Kiedy dziś wysyłasz e-mail, podpisuje go tylko Twój serwer wysyłający. Jeśli cokolwiek w środku ścieżki dostarczania dotknie wiadomości - korporacyjny automatyczny serwer przekazujący, lista mailingowa dodająca prefiks do tematu, brama bezpieczeństwa modyfikująca nagłówki - oryginalny podpis się łamie, a skrzynka odbiorcy nie ma żadnej możliwości stwierdzenia, co się zmieniło ani kto to zmienił. DKIM2 to zmienia. Każdy serwer pocztowy, który obsługuje wiadomość, dodaje własny podpis, więc odbiorca otrzymuje weryfikowalny łańcuch pokazujący, które domeny dotknęły wiadomości i w jakiej kolejności. Ideę łańcucha pochodzenia zapowiadał protokół Authenticated Received Chain (ARC, zdefiniowany w RFC 8617), eksperymentalny dodatek, który jest teraz wycofywany na rzecz DKIM2.

Podpis jest powiązany z konkretnymi odbiorcami wiadomości. DKIM podpisuje dziś treść e-maila (treść i wybrany zestaw nagłówków), ale nie obejmuje tego, do kogo wiadomość jest wysyłana. To dlatego spamer, który przechwyci jedną podpisaną wiadomość, może rozesłać ją do milionów innych osób, a każda kopia nadal przechodzi weryfikację podpisu. DKIM2 naprawia to, podpisując także kopertę routingową: adres MAIL FROM (nadawca) oraz adresy RCPT TO (odbiorcy), do których wiadomość została wysłana. Przechwycona wiadomość podpisana przez DKIM2 i wysłana ponownie do innej listy odbiorców natychmiast nie przejdzie weryfikacji, ponieważ adresy odbiorców w kopercie nie pasują już do tego, co podpisał pierwotny sygnatariusz.

Każdy serwer, który modyfikuje wiadomość w trakcie transportu, zostawia pisemny zapis tego, co zmienił. Kiedy lista mailingowa dodaje dziś prefiks "[nazwa-listy]" do Twojego tematu albo dokleja stopkę do treści, cicho łamie oryginalny podpis DKIM, a odbiorca nie ma jak ocenić, czy zmiana była nieszkodliwą edycją, czy wrogą modyfikacją. DKIM2 pozwala modyfikującemu serwerowi dołączyć małą notatkę czytelną dla maszyny opisującą wprowadzone zmiany. Oprogramowanie odbiorcy cofa każdą zarejestrowaną zmianę, rekonstruuje oryginalną wiadomość i weryfikuje pierwotny podpis względem tej rekonstrukcji. Format notatek o zmianach jest opisany w osobnym dokumencie towarzyszącym.

Powiadomienia o niedostarczeniu też są podpisywane, więc nie da się ich sfałszować. Jeśli kiedykolwiek otrzymałeś powiadomienie o niedostarczeniu e-maila, którego nigdy nie wysłałeś, widziałeś zjawisko zwane "backscatter": spamer sfałszował Twój adres nadawcy, serwer odbiorcy próbował dostarczyć wiadomość, nie mógł i odbił ją do Ciebie zamiast do spamera. DKIM2 zatrzymuje to, wymagając, aby same powiadomienia o niedostarczeniu były kryptograficznie podpisane przez serwer odbiorcy. Powiadomienie o niedostarczeniu może zostać wysłane tylko z domeny, która pierwotnie odebrała wiadomość, i może dotrzeć tylko do domeny, która pierwotnie ją wysłała.

Dlaczego IETF przebudowuje DKIM właśnie teraz?

Grupa robocza DKIM mówi otwarcie o powodzie: wcześniejsza próba dodania obsługi łańcucha pochodzenia na wierzch DKIM nie osiągnęła poziomu wdrożenia potrzebnego, aby być wiarygodna. ARC, opublikowany w 2019 r. jako RFC 8617, był pierwszą odpowiedzią IETF na problem list mailingowych i serwerów przekazujących. ARC pozwalał pośrednikom poświadczać stan uwierzytelnienia wiadomości w momencie, gdy ją obsługiwali, w teorii umożliwiając dalszym odbiorcom zaufanie łańcuchowi, nawet jeśli sam DKIM zerwał się po drodze.

W praktyce ARC pozostał specyfikacją eksperymentalną o nierównomiernym wdrożeniu. Dokument motywacyjny DKIM2 mówi wprost, że nowy standard jest budowany "na podstawie wniosków wyciągniętych z wdrażania eksperymentu ARC". ARC ma teraz zostać przeklasyfikowany jako Historic w osobnym dokumencie IETF. DKIM2 to skonsolidowana, produkcyjna wersja tej samej idei łańcucha pochodzenia, przeprojektowana tak, aby dało się ją wdrażać jako bazowy zamiennik dla DKIM, a nie opcjonalny dodatek.

Grupa robocza DKIM zajmuje się tym samym pokoleniowym porządkowaniem, którym grupa robocza DMARC zajmuje się przy DMARCbis, planowanej aktualizacji samego DMARC. Oba standardy powstały w erze 2007-2015 uwierzytelniania poczty, oba mają ponad dekadę doświadczeń operacyjnych pokazujących, gdzie oryginalne specyfikacje okazały się niewystarczające, i oba są teraz przepisywane z tym doświadczeniem w ręku.

Jak wygląda Twój dzisiejszy rekord DKIM?

Niezależnie od tego, jak DKIM2 będzie wyglądać, gdy wejdzie w życie, rekord DKIM, który publikujesz dzisiaj, nadal musi być poprawny. Błędnie skonfigurowany rekord DKIM to najczęstszy powód, dla którego poczta od prawdziwego nadawcy nie przechodzi uwierzytelniania, a (zgodnie z danymi za Q1 2026 powyżej) wskaźniki błędów u dużych dostawców skrzynek pocztowych są wyższe, niż większość właścicieli domen sobie wyobraża.

Wpisz swoją domenę poniżej, aby sprawdzić, jak wygląda Twój opublikowany rekord DKIM i czy jest poprawnie skonfigurowany.

Co to oznacza dla Ciebie

To, jak bardzo DKIM2 ma dla Ciebie znaczenie, zależy od tego, jaką rolę pełnisz w ekosystemie e-mailowym.

Jeśli prowadzisz pojedynczą domenę lub małą firmę: nic się dziś dla Ciebie nie zmienia. Twój rekord DKIM nadal działa. Dostawcy skrzynek pocztowych będą weryfikować podpisy DKIM1 jeszcze przez wiele lat po publikacji DKIM2, a od Twojej domeny nie będzie się oczekiwać publikacji rekordów DKIM2, dopóki najwięksi dostawcy nie zasygnalizują, że ich sprawdzają. Skup się na tym, aby aktualny DKIM był poprawny: jeden klucz na każde źródło wysyłki, regularna rotacja kluczy i zgodność z polityką DMARC.

Jeśli prowadzisz sklep e-commerce i polegasz na docieraniu poczty transakcyjnej do skrzynki odbiorczej, wskaźniki błędów z Q1 2026 powyżej są bardziej palącym problemem. DKIM to metoda uwierzytelniania, która najczęściej zawodzi u dostawców skrzynek pocztowych Twoich klientów, a błędy wynikają ze szczegółów operacyjnych (serwery przekazujące, listy mailingowe, luki w rotacji kluczy), które nie mają nic wspólnego ze standardem DKIM2. Jeśli nie masz jeszcze wdrożonego monitoringu DKIM, darmowy plan DMARCeye obejmuje jedną domenę z pełnym parsowaniem raportów, co wystarcza, aby zobaczyć, czy Twój DKIM podpisuje wiadomości wiarygodnie.

Jeśli jesteś agencją lub MSP zarządzającym domenami klientów: DKIM2 to wielonajemcowe przejście, które prędzej czy później będzie wymagało koordynacji w całym Twoim portfolio. DMARCeye odseparowuje każde konto klienta niezależnie, łącznie z integracją Model Context Protocol, która pozwala zapytać o stan uwierzytelnienia programowo. Twój zespół może monitorować stan DKIM dla wielu domen klientów z jednej konsoli, podczas gdy każdy klient widzi tylko własne dane. Infrastruktura widoczności, którą masz dziś, jest tym, co poprowadzi Cię przez przejście, gdy ono nadejdzie.

Jeśli prowadzisz korporacyjną infrastrukturę pocztową: obserwuj projekt profilu wdrożeniowego (draft-moccia-dkim2-deployment-profile, opublikowany w kwietniu 2026 r.). Projekt profilu wdrożeniowego opisuje, jak DKIM2 może zostać zaimplementowany przez istniejący interfejs milter, który większość serwerów MTA już obsługuje, bez modyfikowania samego rdzenia MTA. Wniosek jest taki, że DKIM2 jest projektowany tak, aby dało się go wpiąć w istniejące stosy pocztowe, a nie wymagać pełnego przepisania. Zrób teraz inwentaryzację kluczy i ustal, które ścieżki wysyłki migrowałbyś jako pierwsze.

Harmonogram wdrożenia DKIM2

DKIM2 nie jest opublikowanym dokumentem RFC i nie jest blisko, aby nim zostać. Główna specyfikacja jest na wersji 02 z 17 maja 2026 r. Dokumenty robocze IETF wygasają po sześciu miesiącach, więc aktualna wersja musi albo awansować, albo zostać opublikowana ponownie przed listopadem 2026 r. Kilka dokumentów uzupełniających (motywacja, specyfikacja DNS, najlepsze bieżące praktyki, profil wdrożeniowy) idzie równolegle.

Nawet przy agresywnym harmonogramie publikacja jako RFC zajmuje zwykle 12-18 miesięcy od stabilnej wersji specyfikacji. Adopcja u dostawców skrzynek pocztowych zajmuje potem kolejne lata: sam DMARC został opublikowany jako RFC 7489 w 2015 r. i wciąż nie jest powszechnie egzekwowany. Realistycznie DKIM2 nie stanie się domyślnym standardem dla poczty wychodzącej wcześniej niż pod koniec lat 2020.

Pracą, którą warto wykonać w 2026 r., jest upewnienie się, że DKIM1 jest poprawnie skonfigurowany dla każdej domeny, na której Ci zależy. Nowa specyfikacja tego nie zmienia.

Podsumowanie

DKIM2 to uczciwa przebudowa podpisywania poczty, która adresuje luki w obronie przed atakami replay, w rozliczalności oraz w obsłudze modyfikacji przez pośredników, które IETF dokumentowało przez prawie 20-letnie życie tego standardu. DKIM2 zachowuje to, co działało w ARC, odrzuca to, co nie działało, i jest projektowany tak, aby dało się go wdrożyć w istniejących stosach pocztowych. Nic z tego nie wymaga niczego od właścicieli domen dzisiaj, ale infrastruktura widoczności, którą wdrożysz teraz, jest tym, co przeprowadzi Cię przez to ostateczne przejście.

Jeśli już prowadzisz monitoring DMARC, to, co możesz zrobić dzisiaj, to zweryfikować, że Twoje podpisy DKIM przechodzą weryfikację wiarygodnie i że Twój rekord jest poprawnie skonfigurowany. DMARCeye parsuje raporty DMARC, które otrzymuje Twoja domena, i pokazuje Ci prostym językiem, gdzie DKIM przechodzi, gdzie zawodzi i co powoduje błędy, bez konieczności samodzielnego czytania surowego XML.