ARK. B31Parametr monitoringuBezpieczeństwo · lista 87 parametrów

Rekord DKIM

ważność średniamierzonysposób dkim

Podpis kryptograficzny poczty. Potwierdza, że wiadomość naprawdę wyszła z serwera klienta i nie zmieniono jej po drodze.

Wdrożony 01.10 (badanie profilem). Z zewnątrz da się wykryć tylko OBECNOŚĆ przy trafionym selektorze (38 typowych) — brak trafienia nie dowodzi braku DKIM, więc parametr nie otwiera ustalenia; domena bez MX = nie dotyczy.

ARK. 1

WIKI

artykuł z 16.09.2026 · źródeł 8

Rekord DKIM to parametr monitoringu stron internetowych, który sprawdza, czy w DNS opublikowany jest klucz publiczny DKIM, czyli rekord TXT pod nazwą selektor._domainkey.domena. Wynikiem jest klucz znaleziony albo brak rozstrzygnięcia. DKIM (DomainKeys Identified Mail) pozwala domenie przyjąć odpowiedzialność za wiadomość przez podpis kryptograficzny, który odbiorca weryfikuje kluczem pobranym z DNS ^[1].

Jak działa

Serwer nadawcy podpisuje treść i wybrane pola nagłówka kluczem prywatnym i dodaje do wiadomości pole DKIM-Signature ^[1]. Pole zawiera m.in. algorytm (a=), skrót treści (bh=), podpis (b=), domenę podpisującą (d=), selektor (s=) i listę podpisanych pól (h=) ^[1]. Selektor dzieli przestrzeń kluczy domeny, więc jedna domena może mieć wiele kluczy. Dla d=example.com i s=foo.bar odbiorca pyta DNS o rekord foo.bar._domainkey.example.com ^[1].

RYS. 1.1Podpis i pobranie klucza

Gdy rekordu klucza nie ma, weryfikator musi zwrócić PERMFAIL, a gdy DNS nie odpowiada, może zwrócić TEMPFAIL i spróbować później ^[1]. Pusta wartość p= oznacza klucz unieważniony ^[1]. Flaga t=y w rekordzie oznacza, że domena testuje DKIM, a weryfikator nie może traktować jej wiadomości inaczej niż niepodpisanych, nawet gdy podpis się nie zgadza ^[1].

RYS. 1.2Od nagłówka do wyniku

Z zewnątrz, bez dostępu do poczty, selektor jest nieznany: zapisuje go tylko pole s= podpisu w wiadomości ^[1]. RFC 6376 nie narzuca nazw selektorów i zauważa, że część domen nadaje je tak, by osoby z zewnątrz nie mogły zbierać z nich danych, np. jako losowe wartości ^[1]. Da się sprawdzić selektory typowe dla dostawców: Google Workspace domyślnie używa prefiksu google ^[7], a Microsoft 365 nazw selector1._domainkey i selector2._domainkey publikowanych jako CNAME ^[8]. Trafienie potwierdza obecność klucza. Brak trafienia nie dowodzi braku DKIM, bo domena może podpisywać pod innym selektorem. Pewny odczyt daje dopiero nagłówek odebranej wiadomości.

Standardy i specyfikacje

RFC 6376 definiuje podpis, selektory, rekord _domainkey i kroki weryfikacji ^[1]. Relację podpisu z domeną nadawcy widoczną w polu From opisuje artykuł DMARC.
RFC 8301 zakazuje algorytmu rsa-sha1 przy podpisywaniu i weryfikacji. Podpisujący muszą używać kluczy RSA o długości co najmniej 1024 bitów, a powinni 2048 bitów; podpisów z kluczami krótszymi niż 1024 bity weryfikator nie może uznać za ważne ^[3].
RFC 8463 dodaje algorytm ed25519-sha256 i typ klucza k=ed25519. Klucz publiczny w base64 ma 44 oktety, więc zwykle mieści się w jednym 255-bajtowym ciągu TXT ^[2]. Weryfikatorzy muszą obsługiwać ten algorytm, a podpisujący mogą dodać kilka podpisów starym i nowym algorytmem pod różnymi selektorami ^[2].
Google od 1 lutego 2024 r. wymaga od wszystkich nadawców do kont Gmail SPF lub DKIM, a od wysyłających ponad 5000 wiadomości dziennie SPF i DKIM oraz DMARC. Klucz DKIM musi mieć co najmniej 1024 bity, zalecane jest 2048 ^[5]. Yahoo wymaga od nadawców masowych SPF i DKIM, a w zaleceniach podaje podpisywanie każdej wiadomości kluczem co najmniej 1024-bitowym ^[6].

Zagrożenia i skutki

Brak podpisu. RFC 6376 zaleca, by odbiorca nie odrzucał wiadomości wyłącznie z powodu braku podpisu albo podpisu, którego nie da się zweryfikować ^[1]. U dużych dostawców brak uwierzytelnienia może jednak skończyć się oznaczeniem jako spam albo odrzuceniem z błędem 5.7.26 ^[5].

Krótki klucz. Według M3AAWG złamanie 512-bitowego klucza DKIM zajęło w 2012 r. około 72 godzin i kosztowało około 75 dolarów w chmurze, a klucze 1024-bitowe są na granicy możliwości ataku dla komputerów ogólnego przeznaczenia ^[4]. Publikacja kluczy RSA od 1024 bitów wzwyż wymaga z kolei, by serwery DNS obsługiwały długie rekordy TXT, czyli EDNS0 albo zapytania przez TCP ^[4].

Brak rotacji. M3AAWG zaleca wymianę kluczy co najmniej co sześć miesięcy, bo ogranicza to czas, przez który wykradziony lub złamany klucz nadaje się do użycia ^[4]. RFC 6376 opisuje wymianę przez nowy selektor: oba klucze są publikowane jednocześnie, a stary znika po okresie przejściowym. Ponowne użycie selektora z nowym kluczem uniemożliwia odróżnienie wiadomości z nieaktualnym kluczem od sfałszowanej ^[1].

Powtórzenie wiadomości. Spamer może wysłać wiadomość przez serwer, który ją podpisze, a potem rozesłać ją do wielu odbiorców, korzystając z reputacji domeny podpisującej ^[1].

Przykłady

Odczyt	Znaczenie
TXT pod `google._domainkey` z niepustym `p=`	klucz opublikowany pod selektorem dostawcy ^[7]
CNAME `selector1._domainkey` do dostawcy	klucz utrzymywany przez Microsoft 365 ^[8]
rekord z pustym `p=`	klucz unieważniony ^[1]
rekord z `k=ed25519`	klucz Ed25519 ^[2]
brak rekordu pod typowymi selektorami	brak rozstrzygnięcia, selektor może być inny ^[1]
pole `s=` w nagłówku odebranej wiadomości	pewny selektor do sprawdzenia ^[1]

TAB. 1.1Przypisy8

[1] RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures · IETF
[2] RFC 8463 — A New Cryptographic Signature Method for DKIM (Ed25519) · IETF
[3] RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM · IETF
[4] M3AAWG DKIM Key Rotation Best Common Practices (2019) · M3AAWG
[5] Email sender guidelines · Google Workspace Admin Help
[6] Sender Best Practices · Yahoo
[7] Set up DKIM · Google Workspace
[8] How to use DKIM for email in your custom domain · Microsoft Learn

ARK. 2

STATS

wyniki z systemu · tylko liczby zbiorcze

TAB. 2.1Odczyty per strona—

Ten parametr nie zapisuje odczytu per strona — przebieg zostawia tylko ustalenia, więc liczby sprawdzonych stron i wyników „ok” system nie ma. Pojawią się po wdrożeniu zapisu przebiegów per strona per parametr.

TAB. 2.4Przebiegi z tym sposobem sprawdzenia—

Harmonogram nie zapisał jeszcze przebiegu ze sposobem „dkim”. Zapis przebiegów z n8n działa od 2026-09-14.

ARK. 3

CARD

karta z kodu CREATO_PING, odczyt 01.10.2026

Jak ten parametr trafia do ClickUpa: wynik sondy to linia w subtasku 2. Pomiar, a usterka, którą otwiera — linia w subtasku 1. Podsumowanie (z identyfikatorem CWE i kategorią OWASP), skąd liczy się wskaźnik zagrożenia i status strony. Projekcja z bazy skanera odświeża oba subtaski co godzinę. Do 22.09 każde ustalenie dostawało własny subtask i status ze starego słownika (PODATNA, WARNING…) — te słowa zostały jeszcze w części opisów pomiaru niżej jako język wewnętrzny sond.

RYS. 3.1Droga parametru przez system: Rekord DKIM

TAB. 3.1Pomiarpliki: 8

Obszar i ważność	Bezpieczeństwo · średnia (B31)
Workflow i częstotliwość	skaner_badanie działa na LAB247Skaner 2.0, badanie kohorty: premium co 12 h, reszta co 24–48 h · Od 2026-10-01 zestawy kohort (premium_pelny, tani_ciezki, tani_lekki) mają tury higiena, serwer, sklep, kasa i strony (wyciek ścieżek B41, CMS po EOL B44, kluczowe podstrony S08, odnośniki kontaktowe D10); nocny pomiar wydajności (trend, waga, od 01.10 też metryki pasma W01–W04 i W07) tylko premium — u reszty prośba o pomiar zagłodziłaby nocny plan. Sklep: strona bez WooCommerce = „nie dotyczy”.
Sonda i helper	sposób dkim · CREATO_PING/helpers/higiena_check.py
Testy	Tylko badanie kohort: tura „higiena” zestawów premium_pelny (premium co 12 h), tani_ciezki (dostęp co 24 h, priorytet co 48 h) i tani_lekki (bez priorytetu co 48 h), gdy sonda http dała ok. W rytmach monitoringu (p3, p4) tego testu nie ma. Wywołanie przez parasol `helpers/security_testy.py` ze wspólnym terminem strony 60 s (`skaner/proby.toml` → limit_strony_s); test po terminie = nie_dalo_sie_sprawdzic z przyczyną limit_czasu. Nazwa z listy stron bez przedrostka www.; zapytanie MX przez resolver systemowy (dnspython, limit 8 s — TIMEOUT_S, higiena_check.py:41). NXDOMAIN albo brak odpowiedzi MX = ok z ma_poczte=false; brak serwerów nazw albo timeout MX = nie_dalo_sie_sprawdzic. Przy MX: zapytania TXT o <selektor>._domainkey.<domena> dla 38 selektorów z DKIM_SELEKTORY (higiena_check.py:48–51: default, google, selector1, selector2, k1–k3, s1, s2, mandrill, sendgrid, amazonses, ovh, protonmail…), do 8 naraz. Trafienie = rekord TXT zawierający podciąg „p=” albo „k=”. Wynik zawsze ok: lista trafionych selektorów, a przy braku trafienia uwaga, że to NIE dowód braku DKIM. Lista ustaleń jest pusta z założenia.
Typ wyniku	odczyt bez ustalenia: ok z listą trafionych selektorów (albo z uwagą, że żaden typowy selektor nie trafił), ok z ma_poczte=false („domena bez MX — DKIM nie dotyczy”) albo nie_dalo_sie_sprawdzic (`zrodlo_nie_odpowiada`)
Jednostka	liczba trafionych selektorów z 38 sprawdzanych; wynik jakościowy
Próg i reguła	Brak progu i brak reguły porażki — parametr tylko informuje. Limit 8,0 s na zapytanie DNS (TIMEOUT_S); timeout zapytania o pojedynczy selektor liczy się jak brak rekordu.
Gdzie leżą pokrętła	CREATO_PING/helpers/higiena_check.py → DKIM_SELEKTORY, TIMEOUT_S, dkimCREATO_PING/skaner/scenariusze/premium_pelny.toml, tani_ciezki.toml, tani_lekki.toml → tura „higiena”CREATO_PING/skaner/proby.toml → [parasol] limit_strony_s (60 s)
Retencja odczytów	Surowy pomiar jako NIEZMIENNY wiersz tabeli `odczyty` w bazie skanera (wejście, wyjście, dowody, sha karty sondy i helpera, commit kodu) — trigger odrzuca każdą zmianę. Okno retencji z kohorty: 90 dni premium, 30 dni reszta; poza oknem zostają odczyty z werdyktem problemu, akcją albo etykietą, bo replay reguł ich potrzebuje (`skaner/retencja.py`). Ustalenia ani sprawy nie ma; panel klienta LAB247 czyta najnowszy odczyt na żądanie (`GET /latest-readings`), bez kopii w bazie serwisu.
Znane rozbieżności	Rekord z pustym p= (klucz odwołany wg RFC 6376) liczy się jako trafienie, bo wystarczy podciąg „p=”. Timeout albo błąd zapytania o selektor wygląda jak brak rekordu — wynik nie odróżnia „nie ma” od „nie odpowiedział”. Domena bez MX dostaje „nie dotyczy”, a opis parametru mówi o poczcie wychodzącej — wysyłać i podpisywać pocztę może także domena bez MX. DKIM odcina przedrostek www., a SPF i DMARC (dns_integrity_check) pytają nazwę z listy stron bez zmian — dla strony zapisanej z www. parametry poczty patrzą na różne nazwy. kandydaci do pętli: kod a opis parametru albo specyfikacja
Karta przepisana z	CREATO_PING/helpers/higiena_check.py · CREATO_PING/helpers/security_testy.py · CREATO_PING/skaner/scenariusze/premium_pelny.toml · CREATO_PING/skaner/scenariusze/tani_ciezki.toml · CREATO_PING/skaner/scenariusze/tani_lekki.toml · CREATO_PING/skaner/kohorty.toml · CREATO_PING/skaner/proby.toml · CREATO_PING/skaner/latest_readings.py · odczyt 01.10.2026

TAB. 3.2Co oznacza failtypów Findingów: 0

Parametr z założenia nie otwiera ustalenia ani usterki: z zewnątrz widać tylko obecność klucza pod zgadniętym selektorem, a brak trafienia nie dowodzi braku DKIM. Odczyt zostaje w bazie skanera z listą selektorów i uwagą; panel klienta LAB247 czyta go na żądanie (`GET /latest-readings`, domena bez MX = „nie dotyczy”). Wskaźnik strony się nie zmienia.

Parametr nie otwiera osobnego Findingu — wynik zostaje znacznikiem w odczycie.

ARK. 4

LOOP

bez pętli

RYS. 4.1Pętla parametru — sześć etapów

TAB. 4.1Trafność, 30 dnialarmy · prawdziwe · fałszywe · bez rozstrzygnięcia

Trafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.

TAB. 4.2Pętle—

Ten parametr nie przeszedł jeszcze żadnej pętli. Kolejność po pierwszych pięciu grupach ustali miara trafności.