Długość klucza DKIM: Jak wybrać między 1024, 2048 a 4096

Ostatnia aktualizacja:
9 czas czytania: 9 minut
Długość klucza DKIM: Jak wybrać między 1024, 2048 a 4096

Kluczowe wnioski

  • Długość klucza DKIM to liczba bitów klucza podpisującego RSA. Dłuższe klucze są bardziej odporne na fałszerstwa, ale powodują, że publikowane rekordy DNS są większe.
  • 1024-bitowy algorytm RSA został uznany za przestarzały w dokumencie RFC 8301 i nie spełnia minimalnych wymagań NIST, jednak panele hostingowe, takie jak cPanel, nadal generują go domyślnie.
  • 2048-bitowy algorytm RSA stanowi właściwe ustawienie domyślne na rok 2026, spełniające wymagania normy RFC 8301, NIST oraz wytyczne Google i Yahoo dotyczące nadawców masowych.
  • Klucz publiczny o długości 2048 bitów przekracza limit 255 bajtów dla rekordów TXT w systemie DNS, dlatego należy go podzielić na fragmenty; w przeciwnym razie weryfikacja zakończy się niepowodzeniem bez wyświetlenia komunikatu o błędzie.
  • Pominięcie etapu tworzenia fragmentów powoduje cichą awarię DKIM: wiadomość nadal jest wysyłana, logi pozostają czyste, ale odbiorcy odrzucają podpis.
  • Klucze należy zmieniać co 6–12 miesięcy przy użyciu selektora równoległego, a algorytm Ed25519 należy stosować wyłącznie w połączeniu z RSA-2048 w ramach podwójnego podpisywania, nigdy samodzielnie.

Aktualizacja klucza DKIM powinna zwiększyć bezpieczeństwo poczty elektronicznej. W praktyce często prowadzi to jednak do błędów uwierzytelniania spowodowanych nieprawidłową konfiguracją DNS.

Wiele organizacji nadal korzysta z kluczy DKIM o długości 1024 bitów, nie zdając sobie z tego sprawy. Inne przechodzą na klucze 2048-bitowe, aby spełnić aktualne zalecenia dotyczące bezpieczeństwa, by wkrótce odkryć, że dłuższe klucze wiążą się z nowymi wymogami dotyczącymi publikacji. Pojedynczy błąd podczas dodawania klucza publicznego do systemu DNS może spowodować niepowodzenie weryfikacji DKIM, nawet jeśli wysyłanie wiadomości e-mail przebiega normalnie.

Wyzwaniem jest dobór odpowiedniej długości klucza, jego prawidłowe opublikowanie oraz utrzymywanie go w czasie bez zakłócania procesu uwierzytelniania wiadomości e-mail.

W niniejszym przewodniku wyjaśniono, w jaki sposób długość klucza DKIM wpływa na bezpieczeństwo, dostarczalność i zgodność z przepisami w 2026 roku. Dowiesz się, czym różnią się klucze 1024-bitowe, 2048-bitowe, 4096-bitowe i Ed25519, jak sprawdzić aktualną konfigurację, jak uniknąć typowych błędów związanych z publikowaniem rekordów DNS oraz jak bezpiecznie dokonywać rotacji kluczy.

Czym jest długość klucza DKIM?

Długość klucza DKIM to rozmiar, wyrażony w bitach, pary kluczy RSA służącej do podpisywania i weryfikacji wiadomości e-mail zgodnie ze standardem standardu DKIM (RFC 6376). Klucz prywatny podpisuje każdą wiadomość wychodzącą na serwerze pocztowym, a odpowiadający mu klucz publiczny znajduje się w rekordzie TXT systemu DNS, dzięki czemu serwery odbiorcze mogą zweryfikować podpis. 

Im dłuższy klucz, tym trudniej go złamać. Klucz o długości 2048 bitów jest znacznie bardziej odporny na sfałszowanie niż klucz 1024-bitowy. Długość klucza wiąże się jednak z kompromisem, który jednocześnie wpływa na siłę kryptograficzną, rozmiar rekordów DNS oraz kompatybilność z odbiorcami. 

Klucz publiczny jest opublikowany w ramach selektora, etykietą (np. selector1._domainkey.example.com), która informuje odbiorcę, którego klucza ma użyć, ponieważ w ramach jednej domeny może działać jednocześnie kilka kluczy. 

Porównanie opcji długości klucza DKIM

Nie wszystkie klucze DKIM są takie same. Niektóre są przestarzałe, inne odpowiadają aktualnemu standardowi, a jeszcze inne rozwiązują jeden problem, powodując jednocześnie inny. Oto porównanie kluczy 1024-bitowych, 2048-bitowych, 4096-bitowych oraz Ed25519 w praktyce.

1024-bitowy RSA

1024-bitowy algorytm RSA był pierwotnym standardem DKIM i obecnie stanowi najsłabszą opcję, jaka jest nadal dozwolona. Standardy już go wyprzedziły. RFC 8301 (2018) określa 1024 bity jako minimalną dopuszczalną długość klucza, ale zaleca co najmniej 2048 bitów do podpisywania. Wymaga również, aby weryfikatorzy traktowali klucze o długości poniżej 1024 bitów jako nieważne. 

NIST SP 800-131A, wersja 2 idzie jeszcze dalej, zabraniając stosowania kluczy RSA o długości poniżej 2048 bitów do generowania podpisów cyfrowych oraz klasyfikując klucze RSA o długości 1024 bitów jako kryptografię przeznaczoną do użytku w starszych systemach. Wytyczne Google dotyczące nadawców nadal dopuszczają klucze DKIM o długości 1024 bitów jako minimalny wymóg dla dostarczania wiadomości w Gmailu, ale zalecają klucze o długości 2048 bitów w celu zapewnienia większego bezpieczeństwa.

Pomimo wszystkich zaleceń klucze 1024-bitowe są nadal powszechnie stosowane. Wiele panele hostingowe i starsze platformy pocztowe nadal generują je domyślnie, przez co organizacje korzystają z 1024-bitowego RSA, nawet o tym nie wiedząc.

Klucz RSA o długości 1024 bitów jest słabszy niż przewidują to aktualne zalecenia kryptograficzne, dlatego też organizacje normalizacyjne i dostawcy usług pocztowych przeszli na rozwiązania oparte na kluczu 2048-bitowym. Jednak organizacje nadal korzystające z protokołu DKIM opartego na kluczu 1024-bitowym zazwyczaj lepiej postąpią, planując i weryfikując kontrolowaną migrację, niż wprowadzając pochopne zmiany, które mogą spowodować błędy uwierzytelniania. 

2048-bitowy RSA

Klucz RSA o długości 2048 bitów stanowi obecnie standard DKIM. Dokument RFC 8301 zaleca stosowanie kluczy RSA o długości co najmniej 2048 bitów do podpisywania, norma NIST SP 800-131A Rev. 2 klasyfikuje klucze RSA o długości 2048 bitów lub większej jako dopuszczalne do generowania podpisów cyfrowych, a wytyczne Google dla nadawców zalecają stosowanie kluczy 2048-bitowych ze względów bezpieczeństwa. Klucz 2048-bitowy spełnia aktualne wymagania branżowe, dostawców usług oraz wymagania dotyczące zgodności.

Większość błędów DKIM związanych z kluczami 2048-bitowymi nie wynika z problemów kryptograficznych. Są to błędy związane z publikacją w systemie DNS. Klucz publiczny o długości 2048 bitów ma długość około 392 znaków w kodowaniu base64, podczas gdy pojedynczy ciąg znaków w rekordzie DNS TXT jest ograniczony do 255 bajtów. Klucza nie da się opublikować jako pojedynczego ciągu znaków. Należy go podzielony na wiele ciągów znaków ujętych w cudzysłowy w ramach tego samego rekordu TXT, które system DNS automatycznie ponownie łączy podczas wyszukiwania.

Jeśli klucz zostanie opublikowany nieprawidłowo, weryfikacja DKIM zakończy się niepowodzeniem , mimo że rekord wydaje się istnieć, a serwer pocztowy nadal normalnie podpisuje wiadomości. 

4096-bitowy RSA

Klucz RSA o długości 4096 bitów to maksymalna długość klucza, jaką weryfikuje większość odbiorców. Standard RFC 8301 wymaga, aby weryfikatorzy sprawdzali klucze o długości od 1024 do 4096 bitów, a klucze o większej długości są sprawdzane jedynie opcjonalnie, więc klucz dłuższy niż 4096 bitów może w ogóle nie zostać zweryfikowany. Usługa PowerDMARC Hosted DKIM obsługuje klucze o długości do 4096 bitów.

Dla większości organizacji klucz 4096-bitowy nie jest konieczny. Nie zapewnia on żadnego znaczącego wzrostu bezpieczeństwa w porównaniu z kluczem 2048-bitowym, który już spełnia minimalne wymagania normy NIST SP 800-131A Rev. 2 oraz wytyczne Google dotyczące nadawców, a jednocześnie powoduje powstanie większego rekordu DNS i wiąże się z niewielkim obciążeniem podczas weryfikacji podpisu.

Z 4096-bitowego klucza należy korzystać wyłącznie w środowiskach o wysokim poziomie bezpieczeństwa lub podlegających ścisłym regulacjom, w których wymagają tego wewnętrzne zasady lub audytor.

Ed25519 (Kierunki rozwoju)

Ed25519 to algorytm podpisywania DKIM znormalizowany w standardzie RFC 8463 (2018). Jego największą zaletą jest rozmiar klucza. Klucz publiczny Ed25519 koduje się do ciągu znaków base64 o długości 44 oktetów, co pozwala na umieszczenie całego rekordu klucza DNS w jednym ciągu znaków TXT. W przeciwieństwie do algorytmów RSA-2048 i RSA-4096 nie wymaga on dzielenia rekordu DNS na fragmenty i działa w systemach, które nie obsługują rekordów TXT składających się z wielu ciągów znaków. W normie RFC 8463 opisano również, że Ed25519 zapewnia wysokie bezpieczeństwo kryptograficzne przy użyciu kluczy znacznie krótszych niż w przypadku algorytmu RSA.

Wyzwaniem jest wdrożenie. Dokument RFC 8463 wymaga od weryfikatorów obsługi algorytmu Ed25519-SHA256, ale jedynie zaleca obsługę podpisywania przy jego użyciu. W praktyce obsługa tego algorytmu przez różne platformy pocztowe, serwery MTA i dostawców usług pocztowych nadal nie jest jednolita. Wdrożenie oparte wyłącznie na algorytmie Ed25519 może skutkować lukami w weryfikacji DKIM u odbiorców, którzy nie obsługują tego algorytmu.

Z tego powodu algorytm Ed25519 najlepiej stosować w połączeniu z RSA-2048. Standard RFC 8463 wyraźnie obsługuje podwójne podpisywanie, umożliwiając umieszczenie w wiadomości zarówno podpisu RSA-SHA256, jak i Ed25519-SHA256. Ponieważ selektor może publikować tylko jeden klucz publiczny, każdy podpis musi wykorzystywać inny selektor, przy czym obie podpisy muszą należeć do tej samej domeny podpisywania. Odbiorcy weryfikują podpisy, które obsługują, co zapewnia kompatybilność, a jednocześnie umożliwia organizacjom wdrożenie algorytmu Ed25519.

Długość kluczaPoziom bezpieczeństwaRozmiar rekordu DNSStan zgodności (2026)Zalecane zastosowanie
1024-bitowy RSASłabe, przestarzałeMieści się w jednym ciągu znaków typu TXTPoniżej minimum określonego przez NIST; zgodnie z wytycznymi NIST – wyłącznie do celów zgodności z dotychczasowymi standardami; akceptowane przez Google jako absolutne minimumTylko starsze wersje; zaplanuj kontrolowaną migrację do 2048-bitowego szyfrowania
2048-bitowy RSASolidny; aktualny standard~392 znaki w kodowaniu base64; należy podzielić na kilka ciągów znakówZgodność z normą RFC 8301, wytycznymi NIST oraz zaleceniami GoogleStandardowe rozwiązanie dla niemal wszystkich organizacji
4096-bitowy RSABardzo mocnyWiększy; należy podzielić; większość odbiorców zweryfikuje największyPrzekracza obecne wymaganiaWyłącznie w środowiskach o wysokim poziomie bezpieczeństwa lub podlegających regulacjom
Ed25519Skuteczny algorytm, krótsze klucze niż w systemie RSA44 bajty; mieści jeden ciąg znaków w formacie TXT, bez podziału na fragmentyStandaryzowane w RFC 8463; weryfikatorzy MUSZĄ obsługiwać tę funkcję, a podpisujący POWINNI; obsługa przez odbiorców jest nadal nierównomiernaPodwójny podpis w połączeniu z RSA-2048

Jak sprawdzić aktualną długość klucza DKIM

Przed zaplanowaniem aktualizacji klucza DKIM należy sprawdzić rozmiar klucza obecnie opublikowanego w systemie DNS.

1. Określ swój selektor DKIM

Otwórz nagłówki podpisanej wiadomości e-mail i znajdź element DKIM-Signature . Wartość pola s= to Twój selektor. Selektor można również znaleźć w ustawieniach konfiguracyjnych DKIM u dostawcy poczty elektronicznej.

2. Sprawdź rekord DKIM

Zapytanie selector._domainkey.twojadomena.com przy użyciu narzędzia do wyszukiwania DKIM lub narzędzia do zapytań DNS w celu pobrania opublikowanego rekordu TXT.

3. Sprawdź klucz publiczny

Znajdź p= w rekordzie. Zawiera on klucz publiczny DKIM. Większość narzędzi do sprawdzania DKIM automatycznie rozpoznaje długość klucza i informuje, czy wynosi ona 1024 bity, 2048 bitów, czy też ma inną długość.

4. Ocena wyniku

Jeśli w domenie nadal stosowany jest klucz 1024-bitowy, należy zaplanować migrację do algorytmu RSA 2048-bitowego. Jeśli klucz 2048-bitowy został już wdrożony i działa poprawnie, zazwyczaj nie ma potrzeby podejmowania natychmiastowych działań.

Narzędzie PowerDMARC DKIM Checker pobiera opublikowany rekord i automatycznie wykrywa selektor dla głównych dostawców, dzięki czemu możesz sprawdzić długość klucza w ciągu kilku sekund, zamiast ręcznie dekodować kod base64. Wypróbuj za darmo 

Problem z fragmentacją DNS przy kluczu 2048-bitowym (i jak go uniknąć)

Jedną z najczęstszych przyczyn błędów DKIM po aktualizacji klucza do 2048 bitów jest nieprawidłowe opublikowanie rekordów DNS.

Problem wynika z ograniczeń rekordu DNS typu TXT . Pojedynczy ciąg znaków w rekordzie TXT może zawierać maksymalnie 255 bajtów, podczas gdy 2048-bitowy klucz publiczny RSA zakodowany w formacie base64 ma zazwyczaj około 392 znaków. W rezultacie klucza nie można opublikować jako pojedynczego ciągu znaków. Jeśli dostawca usług DNS skróci rekord lub odrzuci wpis, weryfikacja DKIM zakończy się niepowodzeniem.

KomponentOgraniczenie
Pojedynczy ciąg znaków w rekordzie TXT serwera DNSMaksymalnie 255 bajtów
Typowy klucz publiczny RSA o długości 2048 bitówOkoło 392 znaków w kodowaniu Base64
Skutki nieprawidłowej publikacjiBłąd weryfikacji DKIM

Aby poprawnie opublikować klucz 2048-bitowy, należy podzielić klucz publiczny na kilka ciągów znaków ujętych w cudzysłowy w ramach tego samego rekordu TXT. System DNS automatycznie łączy te ciągi podczas wyszukiwania.

selector1._domainkey.example.com. IN TXT (

  „v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xN8s9k2”

  „Qp7Yv3RwL0fHmZ2bKct5oXn8eW4uV1aA9dGqB6sT0pJrN3mC2hF7lYxoZ4kP1wIDAQAB”

)

Obsługa długich rekordów TXT różni się w zależności od dostawcy usług DNS. Niektóre platformy wymagają od administratorów ręcznego wprowadzenia wielu ciągów znaków ujętych w cudzysłowy, podczas gdy inne automatycznie dzielą i ponownie łączą długie wartości. Przed opublikowaniem klucza DKIM należy zawsze zapoznać się z wymaganiami dostawcy dotyczącymi formatowania rekordów DNS.

Należy pamiętać o następujących kwestiach:

WymógWyjaśnienie
Lokalizacja w SplicieKlucz można podzielić w dowolnym miejscu. System DNS automatycznie łączy te ciągi znaków w jedną wartość.
Długość ciągu znakówŻaden pojedynczy ciąg znaków nie powinien przekraczać limitu 255 bajtów obowiązującego w systemie DNS.
WalidacjaSprawdź opublikowany rekord DKIM po propagacji DNS i upewnij się, że zwracany jest pełny klucz publiczny.
Rozwiązywanie problemówJeśli podpisywanie wiadomości e-mail przebiega pomyślnie, ale odbiorcy zgłaszają błędy weryfikacji DKIM, sprawdź, czy opublikowany klucz publiczny nie jest skrócony lub czy nie ma w nim błędów formatowania.

Po opublikowaniu nowego klucza DKIM sprawdź poprawność wpisu DNS i upewnij się, że serwery odbiorcze mogą bezbłędnie pobrać pełny klucz publiczny.

Kiedy i jak należy zmieniać klucze DKIM

Rotacja kluczy DKIM zmniejsza ryzyko związane z długotrwałym ujawnieniem kluczy i stanowi powszechny wymóg w programach dotyczących bezpieczeństwa i zgodności z przepisami. Chociaż standard DKIM nie określa uniwersalnego harmonogramu rotacji, wiele organizacji dokonuje rotacji kluczy podpisujących co 6–12 miesięcy w ramach rutynowych działań związanych z utrzymaniem bezpieczeństwa.

Bezpieczny proces rotacji DKIM polega na wprowadzeniu nowego selektora przed wycofaniem dotychczasowego. Zapewnia to ciągłą weryfikację DKIM przez cały okres przejściowy.

  1. Krok 1: Wygeneruj nową parę kluczy DKIM i przypisz jej nowy selektor. Wiele organizacji stosuje nazwy selektorów oparte na dacie, aby uprościć śledzenie i audyt. 
  2. Krok 2: Opublikuj nowy klucz publiczny w systemie DNS pod nowym selektorem. Jeśli używasz klucza RSA o długości 2048 bitów, upewnij się, że rekord DNS został opublikowany poprawnie. 
  3. Krok 3: Poczekaj na propagację DNS zgodnie z wartością TTL rekordu. 
  4. Krok 4: Zaktualizuj serwer pocztowy lub dostawcę usług poczty elektronicznej, aby podpisywał wiadomości przy użyciu nowego selektora. 
  5. Krok 5: Utrzymuj poprzedni selektor w stanie aktywnym do momentu, aż wiadomości podpisane starym kluczem przejdą przez standardowe ścieżki dostarczania, a pamięć podręczna DNS wygaśnie. 
  6. Krok 6: Usuń stary selektor i powiązany z nim rekord DNS, gdy przestanie być używany. 

Takie podejście pozwala na współistnienie obu selektorów w trakcie przejścia, zapobiegając niepowodzeniom weryfikacji DKIM spowodowanym opóźnieniami w propagacji DNS lub zapisami w pamięci podręcznej.

Organizacje zarządzające wieloma domenami, selektorami lub usługami pocztowymi mogą mieć trudności z konsekwentnym utrzymywaniem ręcznej rotacji.

Wymagania dotyczące długości klucza DKIM w zależności od platformy i ram zgodności

Wymagania dotyczące długości klucza DKIM różnią się w zależności od dostawców usług poczty elektronicznej, standardów bezpieczeństwa i ram zgodności. Podczas gdy niektóre ramy określają konkretne wymagania kryptograficzne, inne opierają się na bardziej ogólnych wytycznych branżowych i najlepszych praktykach.

Zgodność z przepisami i wymagania wobec dostawców

Platforma / DostawcaWymagania dotyczące długości klucza DKIM
Wymagania Google dotyczące nadawców masowychCo najmniej 1024 bity; zalecane 2048 bitów
Wymagania dotyczące nadawców w serwisie YahooZasadniczo zgodne z wymaganiami Google dotyczącymi nadawców
NIST SP 800-131A, wersja 2Klucze RSA o długości poniżej 2048 bitów nie są dopuszczone do generowania podpisów cyfrowych
Środowiska podlegające przepisom ustawy HIPAAZazwyczaj należy stosować się do wytycznych kryptograficznych NIST, zgodnie z którymi 2048-bitowy klucz RSA stanowi praktyczne minimum
Środowiska FedRAMPZgodność z normami kryptograficznymi NIST oraz zatwierdzonymi długościami kluczy
Środowiska zgodne z PCI DSSNie ma konkretnych wymagań dotyczących długości klucza w standardzie DKIM, jednak organizacje zazwyczaj stosują praktyki kryptograficzne zgodne z wytycznymi NIST

Obsługa platform i ustawienia domyślne

PlatformaKwestie związane z długością klucza DKIM
cPanelW niektórych konfiguracjach domyślnie stosuje się klucze DKIM o długości 1024 bitów. Przed uznaniem zgodności należy sprawdzić długość opublikowanego klucza.
Microsoft Exchange 2013/2016Obsługa długości klucza oraz wartości domyślne mogą się różnić w zależności od metody wdrożenia i implementacji DKIM.
Google WorkspaceObsługuje natywnie klucze DKIM o długości 2048 bitów.
Microsoft 365Obsługuje natywnie klucze DKIM o długości 2048 bitów.
Nowoczesne platformy poczty elektronicznej w chmurzeZasadniczo obsługuje wdrażanie DKIM z kluczem 2048-bitowym bez konieczności dodatkowej konfiguracji.

Wśród głównych dostawców usług pocztowych, systemów zabezpieczeń i środowisk korporacyjnych długość klucza RSA wynosząca 2048 bitów pozostaje zalecaną długością klucza DKIM. Spełnia ona aktualne wytyczne dotyczące bezpieczeństwa, szerokie wymagania dotyczące kompatybilności oraz oczekiwania w zakresie zgodności z przepisami, pozwalając jednocześnie uniknąć trudności związanych z wdrażaniem dłuższych kluczy RSA.

Jak wygenerować klucz DKIM o długości 2048 bitów

Parę kluczy DKIM o długości 2048 bitów można wygenerować za pomocą narzędzia do generowania kluczy DKIM lub bezpośrednio z wiersza poleceń.

Metoda 1: Skorzystaj z generatora kluczy DKIM

Generator DKIM firmy PowerDMARC tworzy parę kluczy DKIM o długości 2048 bitów i udostępnia klucz publiczny w formacie dostosowanym do systemu DNS wraz z odpowiadającym mu kluczem prywatnym dla serwera pocztowego lub platformy pocztowej użytkownika.

Metoda 2: Wygenerowanie pary kluczy za pomocą OpenSSL

# Wygeneruj klucz prywatny o długości 2048 bitów

openssl genrsa -out dkim_private.key 2048

# Wyodrębnij pasujący klucz publiczny

openssl rsa -in dkim_private.key -pubout -out dkim_public.key

Po wygenerowaniu pary kluczy należy postępować zgodnie z poniższymi zaleceniami:

ZalecenieSzczegóły
Użyj selektora opisowegoSelektory oparte na dacie, takie jak 20260101 lub jan2026, ułatwiają zarządzanie kluczami i śledzenie ich rotacji.
Chroń klucz prywatnyKlucz prywatny należy przechowywać wyłącznie w systemie odpowiedzialnym za podpisywanie DKIM. Nie wolno go nigdy publikować w systemie DNS ani udostępniać publicznie.
Opublikuj klucz publiczny w systemie DNSDodaj klucz publiczny do odpowiedniego rekordu TXT o nazwie selector._domainkey.
Sprawdź formatowanie DNSW przypadku korzystania z klucza RSA o długości 2048 bitów należy upewnić się, że klucz publiczny został poprawnie opublikowany i jest zgodny z ograniczeniami długości rekordów TXT w systemie DNS.
Przeprowadź test przed wdrożeniemNależy sprawdzić, czy rekord DKIM jest publicznie dostępny oraz czy wiadomości podpisane przy użyciu nowego selektora przechodzą weryfikację DKIM.

Po opublikowaniu klucza i zakończeniu propagacji w systemie DNS zaktualizuj swoją platformę pocztową, aby rozpocząć podpisywanie wiadomości przy użyciu nowego selektora.

Właściwe zarządzanie długością klucza DKIM w 2026 roku 

Prawidłowo wygenerowany, opublikowany i utrzymywany klucz 2048-bitowy zapewnia lepszą ochronę przed fałszerstwem, nie powodując przy tym problemów z dostarczalnością. Nieprawidłowo opublikowany klucz może jednak uniemożliwić weryfikację DKIM, niezależnie od jego siły kryptograficznej.

Przed wprowadzeniem jakichkolwiek zmian sprawdź aktualną konfigurację DKIM. Jeśli nadal korzystasz z klucza 1024-bitowego, zaplanuj kontrolowaną migrację do klucza RSA 2048-bitowego. Jeśli korzystasz już z klucza 2048-bitowego, sprawdź poprawność konfiguracji rekordów DNS, wdroż proces rotacji kluczy i regularnie monitoruj wyniki uwierzytelniania.

Skuteczne uwierzytelnianie wiadomości e-mail to coś więcej niż tylko wybór odpowiedniej długości klucza. Zależy ono od prawidłowego zarządzania całym cyklem życia DKIM — od wygenerowania klucza i opublikowania go w systemie DNS po rotację kluczy i bieżącą weryfikację.

Najczęściej zadawane pytania

Czy Google będzie wymagać 2048-bitowego DKIM w 2026 roku?

Zasady Google dotyczące nadawców masowych dopuszczają klucze o długości co najmniej 1024 bitów, ale zdecydowanie zalecają stosowanie kluczy o długości 2048 bitów. Ponieważ NIST nie zezwala na stosowanie kluczy RSA o długości 1024 bitów do generowania podpisów cyfrowych, klucze o długości 2048 bitów stanowią praktyczny standard, niezależnie od ograniczeń narzuconych przez Google.

Co się stanie, jeśli użyję klucza DKIM o długości 1024 bitów?

Twoja poczta nadal będzie przechodzić uwierzytelnianie u odbiorców akceptujących klucze 1024-bitowe, w tym w serwisie Gmail. Nie spełnia ona jednak minimalnego wymogu NIST wynoszącego 2048 bitów, może nie przejść audytów zgodności i może zostać złamana przez atakujących dysponujących odpowiednimi zasobami. 

Jak podzielić klucz DKIM o długości 2048 bitów w systemie DNS?

Klucz publiczny o długości 2048 bitów (~392 znaki) przekracza limit długości ciągu znaków w rekordzie TXT wynoszący 255 bajtów, dlatego należy go podzielić na ciągi znaków ujęte w cudzysłowy w ramach tego samego rekordu TXT. System DNS automatycznie je połączy. Po opublikowaniu należy sprawdzić poprawność za pomocą narzędzia do sprawdzania DKIM.

Czy Gmail i Outlook obsługują algorytm Ed25519 DKIM?

W 2026 r. obsługa tego standardu ulega poprawie, ale nie jest jeszcze spójna wśród odbiorców i dostawców usług internetowych (ESP). Nie należy podpisywać wiadomości wyłącznie za pomocą algorytmu Ed25519. Należy stosować podwójne podpisywanie przy użyciu algorytmów RSA-2048 i Ed25519, tak aby odbiorcy, którzy nie obsługują algorytmu Ed25519, mogli skorzystać z algorytmu RSA.

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

Powszechnie uznaje się, że optymalnym rozwiązaniem jest przeprowadzanie tej operacji co 6–12 miesięcy. Należy stosować metodę selektora równoległego, dzięki czemu stary klucz pozostaje ważny do momentu wprowadzenia nowego, co pozwala na ciągłe podpisywanie wiadomości podczas wymiany kluczy