Jak podzielić rekord DKIM

Konfiguracja uwierzytelniania poczty elektronicznej to jedno z tych zadań, które wydaje się, że powinno zająć pięć minut, dopóki nie natrafisz na przeszkodę. Generujesz swój bezpieczny klucz DKIM o długości 2048 bitów, przechodzisz do strony swojego dostawcy usług DNS, wklejasz go w polu nowego rekordu TXT i klikasz „Zapisz”.

Zamiast komunikatu o pomyślnym zakończeniu na ekranie pojawia się błąd. Usługa AWS Route 53 wyświetla niezrozumiały komunikat o błędzie „CharacterStringTooLong”. Usługa Google Cloud DNS informuje po prostu, że masz „nieprawidłowe dane rekordu”.

Jeśli podczas dodawania rekordu DKIM napotkasz ograniczenie do 255 znaków, nie martw się – Twój klucz działa prawidłowo i nie musisz obniżać poziomu bezpieczeństwa. Wystarczy, że w odpowiedni sposób podzielisz rekord TXT DKIM na kilka ciągów znaków. Podział rekordu DKIM to standardowa i bezpieczna procedura administracyjna, a po opublikowaniu rekordu serwery DNS automatycznie i płynnie połączą jego fragmenty z powrotem w całość.

Przyjrzyjmy się dokładnie, dlaczego tak się dzieje i jak krok po kroku rozwiązać ten problem, korzystając z metod ręcznych lub automatycznego narzędzia do rozdzielania rekordów DNS.

Dlaczego rekordy DKIM należy rozdzielić

Konieczność dzielenia rekordów DKIM wynika z podstawowych zasad funkcjonowania Internetu. Zgodnie z sekcją 3.3.14 dokumentu RFC 1035 długość pojedynczego ciągu znaków w rekordzie DNS typu TXT jest ograniczona do maksymalnie 255 znaków (lub bajtów). Ograniczenie to wynika z faktu, że długość ciągu znaków w standardowym pakiecie DNS jest zapisywana w jednym bajcie, co oznacza, że nie może ona przekraczać 255 znaków.

To ograniczenie strukturalne nabiera szczególnego znaczenia w zależności od długości kluczy kryptograficznych:

• Klucze DKIM o długości 1024 bitów: Te ciągi znaków klucza publicznego są krótkie i zazwyczaj mieszczą się bez żadnych zmian w limicie 255 znaków.
• Klucze DKIM o długości 2048 bitów: Klucze te zapewniają znacznie wyższy poziom bezpieczeństwa, ale generują ciąg znaków klucza publicznego w formacie Base64, który prawie zawsze ma długość od 350 do ponad 500 znaków.

Ponieważ klucz DKIM o długości 2048 bitów z natury rzeczy przekracza limit 255 znaków, nie może zmieścić się w jednym ciągłym ciągu znaków.

To, w jaki sposób ta granica jest traktowana, zależy wyłącznie od dostawcy usług hostingowych DNS. W 2026 roku główne platformy nadal dzielą się na dwie grupy:

• Dostawcy stosujący rygorystyczne zasady: Usługi takie jak AWS Route 53, Google Cloud DNS i Azure DNS ściśle przestrzegają normy RFC 1035 już na poziomie interfejsu użytkownika. Jeśli wkleisz ciąg znaków o długości 300 znaków, natychmiast go odrzucą.
• Dostawcy usług automatycznych: Platformy takie jak Cloudflare, GoDaddy i cPanel często zajmują się tym formatowaniem w tle, dzieląc rekord wewnętrznie, dzięki czemu nie trzeba tego robić ręcznie.

Ważna uwaga: Podział rekordu nie powoduje zmiany ani uszkodzenia podpisu DKIM. Gdy serwer poczty przychodzącej wyszukuje klucz publiczny DKIM Twojej domeny, jego moduł DNS automatycznie łączy (scala) podzielone ciągi znaków z powrotem w jeden ciągły ciąg przed rozpoczęciem procesu uzgadniania kryptograficznego.

Jak podzielić rekord DKIM (krok po kroku)

Aby poprawnie podzielić rekord bez utraty ważności danych kryptograficznych, należy przestrzegać określonych zasad formatowania.

Oto przykład niepodzielonego, surowego rekordu DKIM o długości 2048 bitów – pojedynczego, ciągłego ciągu znaków, który rygorystyczni dostawcy odrzucą – a następnie ten sam klucz poprawnie podzielony:

Wcześniej – jeden ciąg znaków (410 znaków, odrzucony):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDDj8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB

Wynik – jeden rekord TXT, dwa cytowane ciągi znaków podzielone na granicy 255 znaków:

„v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDD”
„j8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB”

Podział klucza DKIM o długości 2048 bitów

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…wIDAQAB

Jeden ciąg znaków – 410 znaków, który jest odrzucany przez AWS Route 53 / Google Cloud DNS

↓ podział na granicy 255 znaków

Jeden rekord TXT — dwa ciągi znaków w cudzysłowie

„v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…”

fragment 1 · 255 znaków

„…zrIZtoLuCr64CxqlIOdNKhiwIDAQAB”

część 2 · pozostała część (≈155)

dokładnie jedna spacja między fragmentami, bez spacji wewnątrz żadnego z nich.

Krok 1: Znajdź swój pełny rekord DKIM

Możesz zalogować się do panelu administracyjnego swojego dostawcy usług pocztowych (np. Google Workspace, Microsoft 365, SendGrid lub Mailchimp), aby znaleźć wygenerowany klucz publiczny. Wpis ten zawsze zaczyna się od określonych znaczników i zazwyczaj ma dokładnie taki układ:

v=DKIM1; k=rsa; p=[Bardzo długi ciąg znaków w formacie Base64]

Możesz też skorzystać z naszego bezpłatnego narzędzia do sprawdzania rekordów DKIM, aby w kilka sekund sprawdzić swój rekord:

Aby sprawdzić, czy podział jest rzeczywiście konieczny, skopiuj całą wartość i wklej ją do prostego edytora tekstu, aby sprawdzić jej całkowitą długość. Jeśli liczba znaków przekracza 255, należy ją podzielić.

Krok 2: Podziel wartość klucza na fragmenty po 255 znaków

Masz dwie możliwości podziału rejestru: ręczne obliczenia lub skorzystanie z automatycznego narzędzia.

Metoda ręczna

Otwórz edytor tekstu i odlicz dokładnie 255 znaków od początku zapisu (włącznie z prefiksem „v=DKIM1; k=rsa; p=”). Przerwij ciąg znaków dokładnie na granicy tych 255 znaków.

Każdy fragment należy ująć w osobną parę cudzysłowów („”). Co najważniejsze, należy upewnić się, że wewnątrz fragmentów nie ma żadnych spacji, ale między zamkniętym cudzysłowem pierwszego fragmentu a otwartym cudzysłowem drugiego fragmentu musi znajdować się dokładnie jedna spacja.

Metoda automatyczna (zalecana)

Aby wyeliminować błędy ludzkie, zrezygnuj z ręcznego liczenia znaków i skorzystaj z bezpłatnego narzędzia PowerDMARC do dzielenia rekordów DNS.

• Przejdź do strony narzędzia.

• Wklej pełny, niepodzielony rekord TXT DKIM w polu wprowadzania danych.

• Wybierz format z cudzysłowami (wymagany przez dostawców stosujących rygorystyczne wymagania, takich jak AWS i Google).

• Kliknij „Podziel rekord ”, aby natychmiast wygenerować poprawnie sformatowane ciągi znaków.

• Oto jak powinien wyglądać wynik:

Krok 3: Dodaj rekord typu „Split” do swojej strefy DNS

Częstym błędem popełnianym przez administratorów jest próba utworzenia w panelu DNS dwóch oddzielnych rekordów TXT, po jednym dla każdego fragmentu. Nie należy tego robić, ponieważ spowoduje to całkowite uniemożliwienie uwierzytelniania.

Należy dodać jeden wpis TXT. W panelu zarządzania DNS wklej oba ciągi znaków (w cudzysłowie) do jednego pola „Wartość” lub „Dane ”. W przypadku większości standardowych dostawców należy je oddzielić pojedynczą spacją:

„v=DKIM1; k=rsa; p=CHUNK1” „CHUNK2”

(Uwaga: Jeśli korzystasz z usługi AWS Route 53, pomiń formatowanie z pojedynczą spacją w wierszu i zastosuj metodę podziału wierszy właściwą dla danej platformy, opisaną w sekcji dotyczącej dostawcy poniżej.)

Krok 4: Sprawdź rekord DKIM

Po zapisaniu zmian należy poczekać, aż zmiany w DNS rozprzestrzenią się w sieci. Chociaż zazwyczaj trwa to od 5 do 30 minut, w niektórych przypadkach może to potrwać nawet do 48 godzin, w zależności od ustawień TTL (Time to Live) danej strefy.

Aby upewnić się, że wszystko działa bez zarzutu, skorzystaj z bezpłatnego narzędzia PowerDMARC do sprawdzania rekordów DKIM i upewnij się, że Twój rekord został opublikowany i jest poprawnie rozpoznawany.

Wskazówka: Jeśli chcesz dokładnie sprawdzić swoją pracę przed rozpoczęciem oczekiwania na propagację DNS, skopiuj gotowy ciąg znaków i wklej go ponownie do narzędzia do dzielenia rekordów DKIM, aby upewnić się, że żaden z segmentów nie przekracza limitu 255 znaków.

W przypadku pomyślnego wyniku otrzymasz pełny, ujednolicony klucz kryptograficzny ze statusem zielonym. Jeśli pojawi się błąd, sprawdź, czy nie występują takie problemy, jak okrojenie (brakujące dane), brak drugiego fragmentu lub błędy składniowe spowodowane niezamkniętymi cudzysłowami.

Podział rekordów DKIM według dostawcy usług DNS

Różne panele sterowania DNS obsługują wieloczęściowe wpisy TXT na różne sposoby. Oto jak przeprowadzić konfigurację na czterech najpopularniejszych platformach:

AWS Route 53

Usługa Amazon Route 53 ściśle egzekwuje ograniczenia i generuje błąd CharacterStringTooLong, jeśli którykolwiek z poszczególnych ciągów znaków nie jest ujęty w cudzysłowy lub przekracza 255 znaków. Ponieważ programy rozpoznające adresy DNS łączą kolejne ciągi znaków bez żadnych spacji między nimi, umieszczenie dosłownej spacji między cudzysłowami w jednym wierszu może przypadkowo uszkodzić klucz kryptograficzny.

• Metoda konsolowa: W polu „Wartość” konsoli Route 53 wprowadź każdy fragment jako osobny ciąg znaków ujęty w cudzysłowy, w osobnym wierszu. Nie pozostawiaj spacji na końcu wiersza. Route 53 domyślnie traktuje kolejne wiersze w jednym polu tekstowym jako odrębne ciągi znaków w ramach jednego rekordu TXT i łączy je podczas wyszukiwania.
• Metoda API/JSON: Jeśli wdrażasz infrastrukturę za pomocą kodu lub interfejsu API AWS, zapisz dane wejściowe w postaci tablicy JSON, w której każdy fragment stanowi oddzielny element tablicy: [„v=DKIM1…”, „…CHUNK2”].

Google Cloud DNS

Usługa Google Cloud DNS wyświetli ogólne ostrzeżenie o „nieprawidłowych danych rekordu”, jeśli spróbujesz przesłać długi ciąg znaków bez odpowiedniego formatowania. Aby rozwiązać ten problem w interfejsie użytkownika Google Cloud Console, nie wklejaj takich ciągów w jednym wierszu. Zamiast tego ujmij każdy fragment w cudzysłowy i użyj przycisku „Dodaj element”, aby utworzyć wiele kolejnych pól danych w ramach tego samego zestawu rekordów zasobów.

Cloudflare

Cloudflare posiada inteligentny system zaplecza, który automatycznie analizuje długie ciągi znaków w plikach TXT podczas zapisywania, dzieląc je na segmenty zgodne ze standardem RFC bez udziału użytkownika. Jednak poleganie na automatycznej analizie może czasami prowadzić do nietypowych sytuacji w przypadku złożonych kluczy. Najlepszą praktyką wdrożeniową pozostaje ręczne wklejenie wstępnie podzielonych, ujętych w cudzysłowy ciągów znaków bezpośrednio do panelu administracyjnego Cloudflare.

cPanel / WHM

Starsze wersje edytora stref cPanel mają sztywny limit długości 255 znaków w standardowych polach tekstowych. Jeśli główny interfejs nie akceptuje klucza o takiej długości, przejdź do zaawansowanego edytora stref DNS. Ten rozszerzony tryb zapewnia elastyczność strukturalną niezbędną do płynnego wprowadzania wieloczęściowych pól danych TXT przed podziałem.

Typowe błędy przy dzieleniu rekordów DKIM

Jeśli wdrożyłeś już swój zapis typu split, ale moduły sprawdzające uwierzytelnianie sygnalizują problem z Twoją domeną, sprawdź, czy nie popełniłeś jednego z tych trzech typowych błędów konfiguracyjnych:

1. Błąd podpisu DKIM po podziale

• Przyczyna: W jednym z fragmentów zaszyfrowanych w formacie Base64 przypadkowo wstawiono spację, zamiast umieścić ją ściśle między zamkniętym a otwartym cudzysłowem.
• Rozwiązanie: Skopiuj surowy klucz do pustego pliku, całkowicie usuń wszystkie wewnętrzne spacje z ciągu znaków wartości p=, a następnie ponownie przeprowadź proces dzielenia.

2. DNS wyświetla tylko fragment klucza

• Przyczyna: Drugi fragment został zapisany jako całkowicie odrębny, dodatkowy rekord TXT na serwerze Twojej domeny, a nie połączony z pierwszym rekordem.
• Rozwiązanie: Usuń całkowicie dodatkowy rekord. Edytuj główny rekord DKIM TXT tak, aby oba cytowane ciągi znaków znalazły się razem w jednym polu wartości.

3. Po podziale długość zapisu przekracza 255 znaków

• Przyczyna: Punkt podziału został obliczony nieprawidłowo, co spowodowało, że jeden z dwóch fragmentów nieznacznie przekroczył limit 255 znaków (często z powodu błędnego zliczenia przedrostka „v=DKIM1;”).
• Rozwiązanie: Podziel rekord dokładnie na 255. znaku lub pozwól, aby automatyczne narzędzie do dzielenia rekordów DNS zajęło się liczeniem za Ciebie.

Jak podział DKIM wpływa na DMARC

Częstym zmartwieniem menedżerów IT jest to, czy podzielenie klucza publicznego wpływa na sposób przetwarzania przychodzących wiadomości przez system DMARC.

Gdy rekord DKIM zostanie poprawnie podzielony, działa on dokładnie tak samo jak rekord niepodzielony. Ponieważ serwery pocztowe odbierające wiadomości podczas sprawdzania ponownie łączą fragmenty w jeden ciąg znaków, podpisy DKIM są weryfikowane bez żadnych problemów, co nie ma wpływu nazgodność z DMARC.

Jeśli jednak plik dzielony jest uszkodzony lub nieprawidłowo sformatowany, konsekwencje są natychmiastowe:

• Serwer pocztowy, który odbiera wiadomość, nie będzie w stanie odtworzyć Twojego klucza publicznego.
• Uwierzytelnianie DKIM zakończy się niepowodzeniem.
• DMARC będzie zmuszony całkowicie polegać na zgodności z Twoim profilem SPF (Sender Policy Framework).
• Jeśli nie zostanie również zweryfikowana zgodność SPF (lub jeśli polityka DMARC wymaga zgodności obu protokołów), Twoje legalne firmowe wiadomości e-mail będą kierowane do folderów ze spamem lub mogą zostać od razu odrzucone.

Zanim zaczniesz w pełni polegać na egzekwowaniu zasad DMARC, musisz zweryfikować swoje publiczne klucze DKIM po wprowadzeniu jakichkolwiek zmian w systemie DNS.

Podsumowanie

Podział rekordu DKIM stanowi niezbędny krok administracyjny przy zarządzaniu bezpiecznymi kluczami 2048-bitowymi u dostawców DNS stosujących rygorystyczne zasady, takich jak AWS Route 53 czy Google Cloud DNS. Jest to bezpieczna i standardowa procedura, którą łatwo wykonać, gdy tylko pozna się podstawowe zasady formatowania.

Kiedy aktualizujesz swoje dane, pamiętaj o podstawowych zasadach:

• Podziel ciąg znaków w miejscu, gdzie znajduje się granica 255 znaków.
• Każdy fragment należy ująć w podwójne cudzysłowy.
• Wszystkie dane należy umieścić w jednym wpisie TXT (oddzielone spacją w przypadku standardowych dostawców lub w osobnych wierszach w przypadku rygorystycznych interfejsów, takich jak AWS Route 53).

Nie zgaduj, ile znaków zawiera adres, bo możesz narazić się na przerwy w działaniu poczty. Omiń ręczne obliczenia i natychmiast sformatuj swój klucz za pomocą bezpłatnego narzędzia PowerDMARC do dzielenia rekordów DNS – nie musisz się nawet rejestrować.

Najczęściej zadawane pytania

Czym jest narzędzie do dzielenia rekordów DNS?

Narzędzie do dzielenia rekordów DNS służy do rozdzielania długich rekordów DNS typu TXT na poszczególne segmenty o długości 255 znaków. Ten etap formatowania jest niezbędny, aby rekordy mogły być poprawnie zapisane u dostawców usług hostingowych DNS, którzy nie przeprowadzają automatycznego dzielenia ciągów znaków. Treść rekordu pozostaje całkowicie niezmieniona; jest on po prostu sformatowany w postaci uporządkowanych, krótszych bloków, które systemy odbierające ponownie łączą w całość podczas wyszukiwania.

Którzy dostawcy usług DNS wymagają ręcznego podziału rekordów?

Kilku głównych dostawców rozwiązań dla przedsiębiorstw ściśle egzekwuje limit 255 znaków na poziomie interfejsu, co wymaga wstępnego sformatowania długich wartości tekstowych przed zapisaniem:

• AWS Route 53: Wyświetla komunikat o błędzie „CharacterStringTooLong”, chyba że długie ciągi znaków zostaną podzielone na oddzielne bloki ujęte w cudzysłowy.
• Google Cloud DNS: Całkowicie odrzuca długie ciągłe ciągi znaków, co powoduje wyświetlenie ostrzeżenia o „nieprawidłowych danych rekordu”.
• Azure DNS: Wymaga ręcznego podziału i rozdzielenia pól tekstowych podczas wprowadzania ciągów znaków bezpośrednio za pośrednictwem pulpitu nawigacyjnego portalu Azure lub interfejsu Azure CLI.
• DigitalOcean: Nie dzieli automatycznie długich ciągów danych w polach TXT w swoim standardowym panelu sterowania.

Dlaczego muszę podzielić mój rekord DKIM?

Głównym powodem podziału rekordu TXT jest wdrożenie wysoce bezpiecznego klucza publicznego DKIM o długości 2048 bitów. Podczas gdy klucze 1024-bitowe są wystarczająco krótkie, aby zmieścić się w jednym ciągu znaków, klucz 2048-bitowy z natury zawiera od 350 do ponad 500 znaków danych kryptograficznych w formacie base64. Ponieważ sekcja 3.3.14 standardu RFC 1035 ogranicza długość pojedynczego ciągłego ciągu znaków do dokładnie 255 bajtów, te długie klucze muszą zostać podzielone na odrębne segmenty, aby zmieścić się w standardowej architekturze przechowywania danych DNS.

Czy podzielenie mojego rekordu spowoduje zmianę zawartych w nim danych lub uniemożliwi sprawdzenie poprawności adresu e-mail?

Nie. Podział długiego rekordu TXT nie powoduje uszkodzenia ani zmiany jego wartości kryptograficznej. Gdy przychodzący serwer pocztowy żąda ustawień uwierzytelniania Twojej domeny, jego moduł rozpoznający DNS automatycznie odczytuje poszczególne segmenty i łączy je z powrotem w jedną ciągłą wartość bez żadnych separatorów. Formatowanie w postaci segmentów ma charakter wyłącznie techniczny i dotyczy przechowywania danych w tle; rzeczywista treść pozostaje niezmieniona.

Jaka jest różnica między formatami wyjściowymi „Quoted” i „Plain”?

• Format z cudzysłowami (zalecany): Każdy segment o długości 255 znaków należy ująć w osobną parę cudzysłowów („chunk1” „chunk2”), rozdzielając je spacją w jednym wierszu lub wpisując w kolejnych polach/wierszach danych. Taki układ jest wymagany przez rygorystyczne interfejsy, takie jak AWS Route 53 i Google Cloud DNS, aby zapobiec uszkodzeniu klucza.
• Format zwykły: dzieli długie wiersze na oddzielne bloki bez dodawania cudzysłowów ani dodatkowych spacji czy znaków interpunkcyjnych. Układ ten jest przeznaczony dla nowoczesnych paneli sterowania, które obsługują surowe strumienie ciągów wielowierszowych, lub dla środowisk systemowych z samodzielnie hostowanym serwerem BIND (Berkeley Internet Name Domain).

Czy korzystanie z tego narzędzia w przypadku poufnych kluczy lub prywatnych danych jest bezpieczne?

Tak. Narzędzie PowerDMARC DNS Record Splitter działa w całości w lokalnej przeglądarce internetowej przy użyciu skryptów po stronie klienta. Wprowadzone ciągi tekstowe nigdy nie opuszczają urządzenia, żadne dane nie są przesyłane przez Internet do zewnętrznych serwerów przetwarzających, a także nie są wymagane żadne logi śledzenia ani obowiązkowe rejestracje. Ponadto należy pamiętać, że narzędzie to jest przeznaczone wyłącznie do konfiguracji publicznych, takich jak publiczne klucze DKIM, włączenia SPF, zasady DMARC lub rekordy weryfikacji domeny, które są już publicznie dostępne w Internecie. Prywatnych kluczy podpisujących nie należy nigdy wklejać do żadnego narzędzia online.

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty e-mail 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)

• Jak podzielić rekord DKIM - 5 czerwca 2026 r.
• compauth=fail: Wyjaśnienie uwierzytelniania kompozytowego Microsoftu - 1 czerwca 2026 r.
• Czy program Windows Defender wystarczy do zapewnienia bezpieczeństwa w małej firmie? - 14 maja 2026 r.