Jak działa DKIM i jak znaleźć selektor

DKIM (DomainKeys Identified Mail) pozwala domenie złożyć kryptograficzny podpis na wysyłanych wiadomościach. Serwer odbiorcy sprawdza ten podpis kluczem publicznym, który domena publikuje w DNS. Poprawny podpis dowodzi dwóch rzeczy: domena podpisująca wzięła odpowiedzialność za wiadomość, a podpisane części nie zmieniły się po drodze.

Specyfikacją jest RFC 6376 z 2011 roku, zaktualizowany przez RFC 8301 (algorytmy i długości kluczy) oraz RFC 8463 (klucze Ed25519).

Jak przebiega podpisywanie i weryfikacja

Serwer wysyłający — Twój dostawca skrzynek albo usługa wysyłkowa — ma klucz prywatny. Dla każdej wychodzącej wiadomości:

1. wybiera pola nagłówka do podpisania; From musi być wśród nich zawsze;
2. normalizuje nagłówki i treść wybraną metodą kanonikalizacji: simple nie toleruje prawie żadnych zmian, relaxed toleruje zmienione odstępy i na nowo złamane wiersze nagłówków;
3. liczy skrót (hash) treści i zapisuje go w bh=;
4. podpisuje wybrane nagłówki razem z nowym nagłówkiem DKIM-Signature (z pustym jeszcze b=) i zapisuje wynik w b=;
5. dodaje nagłówek DKIM-Signature na początku wiadomości.

Serwer odbiorcy odczytuje z podpisu d= i s=, pobiera klucz publiczny z DNS, ponownie liczy skrót treści i weryfikuje podpis. Wynik zapisuje w nagłówku Authentication-Results, na przykład dkim=pass header.i=@example.com header.s=s2026.

DKIM nie wiąże d= z adresem From: dowolna domena może podpisać dowolną wiadomość. Połączenie obu to zadanie DMARC, który daje wynik pass tylko wtedy, gdy domena podpisująca jest zgodna z domeną z From — zobacz SPF, DKIM i DMARC: czym się różnią i co robią.

Nagłówek DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026;
        h=from:to:subject:date:message-id;
        bh=…; b=…

Tagi, które spotkasz najczęściej (RFC 6376, sekcja 3.5):

Tag	Znaczenie
v=1	Wersja
a=	Algorytm: rsa-sha256 lub ed25519-sha256; rsa-sha1 nie jest już dozwolony
d=	Domena podpisująca — bierze odpowiedzialność za wiadomość; pod nią szuka się klucza
s=	Selektor — wskazuje, którego z kluczy domeny użyto
h=	Podpisane pola nagłówka, rozdzielone dwukropkami
bh=	Skrót treści
b=	Sam podpis
c=	Kanonikalizacja nagłówka i treści; domyślnie simple/simple
t=, x=	Czas złożenia podpisu i opcjonalny termin ważności
i=	Tożsamość, w imieniu której podpisano; ta sama domena co d= lub jej subdomena
l=	Długość podpisanej treści — unikaj go: tekst dopisany za podpisaną częścią nadal przejdzie weryfikację (sekcja 8.2)

Rekord z kluczem publicznym

Serwer weryfikujący składa nazwę DNS z selektora, stałej etykiety _domainkey i domeny (sekcja 3.6.2.1). Dla d=example.com; s=s2026 pyta o rekord TXT:

s2026._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

Tag	Znaczenie
v=DKIM1	Zalecany, ale nieobowiązkowy; jeśli występuje, musi być pierwszy
k=	Typ klucza: rsa (domyślnie) lub ed25519
p=	Klucz publiczny w base64. Puste p= oznacza, że klucz unieważniono
h=	Dozwolone algorytmy skrótu (opcjonalny)
s=	Typ usługi, email lub * (opcjonalny)
t=	Flagi: y = tryb testowy, błędy traktuje się jak brak podpisu; s = i= nie może być subdomeną d=
n=	Notatki dla ludzi

Pod jednym selektorem publikuj dokładnie jeden rekord TXT (sekcja 3.6.2.2). Długi klucz można podzielić na kilka ciągów w tym samym rekordzie; serwer weryfikujący łączy je bez spacji.

Typy i długości kluczy

Klucz	Status
RSA poniżej 1024 bitów	Nieważny: serwery weryfikujące nie mogą uznawać takich podpisów (RFC 8301)
RSA 1024 bity	Minimum; Gmail wymaga co najmniej 1024 bitów dla poczty do prywatnych kont Gmail
RSA 2048 bitów	Zalecany: nadawcy powinni używać co najmniej 2048 bitów (RFC 8301). Klucz nie mieści się w jednym 255-znakowym ciągu TXT, więc się go dzieli
Ed25519	RFC 8463: klucz ma tylko 44 znaki; serwery weryfikujące muszą go obsługiwać, a nadawcy powinni
Podpisy rsa-sha1	Nieważne: nie wolno ich używać ani do podpisywania, ani do weryfikacji (RFC 8301)

Ed25519 nie musi zastępować RSA. Wiadomość może mieć dwa podpisy — RSA i Ed25519 — z tym samym d=, ale różnymi selektorami, bo pod każdym selektorem jest tylko jeden klucz (RFC 8463, sekcja 6). Serwery weryfikujące pomijają podpisy z algorytmami, których nie obsługują (RFC 6376, sekcja 3.3.4), więc tam, gdzie Ed25519 jest nieznany, zadziała podpis RSA.

Dlaczego selektorów nie da się wylistować z DNS

DNS odpowiada na pytania o konkretne nazwy. Nie ma zapytania, które zwróciłoby „wszystkie nazwy pod _domainkey.example.com” — resolwer może zapytać tylko o nazwę, którą już zna.

Selektory mogą mieć dowolne nazwy. RFC 6376 podaje przykłady oparte na lokalizacjach biur, datach, a nawet poszczególnych użytkownikach (sekcja 3.1), a wielu dostawców generuje własne. Narzędzie, które obiecuje „znaleźć wszystkie selektory”, może jedynie wypróbować listę popularnych nazw: pominie wszystkie inne, a trafienie nie dowodzi, że klucz jest używany. Dlatego Sprawdzanie DKIM prosi o podanie selektora. Podpowiada udokumentowane ustawienia domyślne dostawców, ale niczego nie zgaduje.

Jak znaleźć swój selektor

Pewnym źródłem jest wiadomość, którą faktycznie wysłano:

1. Wyślij wiadomość z systemu, który chcesz sprawdzić, na skrzynkę u innego dostawcy.
2. Otwórz pełne źródło wiadomości — w Gmailu służy do tego opcja „Pokaż oryginał”.
3. Znajdź nagłówek DKIM-Signature: s= to selektor, d= to domena. Wiele serwerów powtarza selektor w Authentication-Results jako header.s=.

Możesz też wkleić nagłówki do Analizatora nagłówków e-mail. Pokazuje on każdy podpis z domeną i selektorem obok wyników DKIM z Authentication-Results i działa w całości w Twojej przeglądarce.

Wiadomość często ma więcej niż jeden podpis, np. jeden od usługi wysyłkowej z d= ustawionym na jej własną domenę i drugi z Twoją domeną. Dla DMARC liczy się tylko poprawny podpis, którego d= jest zgodne z domeną z From. Jeśli żaden podpis nie używa Twojej domeny, włącz w tej usłudze podpisywanie DKIM Twoją domeną (często nazywane uwierzytelnianiem domeny).

Udokumentowane ustawienia domyślne dwóch dużych dostawców:

• Google Workspace: domyślny prefiks selektora to google, więc klucz jest pod google._domainkey.example.com. Możesz wybrać inny prefiks, np. gdy ten jest już zajęty.
• Microsoft 365: dwa selektory, selector1 i selector2, publikowane jako rekordy CNAME. Aktywny jest zawsze tylko jeden; rotacja kluczy przełącza na drugi.

W innych usługach selektor znajdziesz na stronie konfiguracji DKIM lub uwierzytelniania domeny w panelu administracyjnym.

Delegowanie przez CNAME

Wielu dostawców prosi, by zamiast rekordu TXT z kluczem opublikować pod nazwą selektora rekord CNAME wskazujący na ich własną strefę DNS. Dostawca trzyma tam klucz i może go zmieniać bez Twojej ingerencji w DNS:

s1._domainkey.example.com.  3600  IN  CNAME  s1.dkim.esp.example.

Serwer weryfikujący podąża za CNAME i odczytuje rekord TXT pod nazwą docelową. Tak działa Microsoft 365: selector1._domainkey i selector2._domainkey wskazują na nazwy w domenie onmicrosoft.com Twojej organizacji albo — dla domen dodanych od maja 2025 roku — w dkim.mail.microsoft. Kopiuj dokładne wartości z panelu dostawcy: Microsoft podkreśla, że wartości w jego dokumentacji są tylko przykładami.

Typowe błędy przy delegowanych selektorach:

• rekord TXT tam, gdzie dostawca prosił o CNAME;
• domena dopisana dwukrotnie przez panel DNS, co daje s1._domainkey.example.com.example.com;
• opublikowany tylko jeden selektor, gdy dostawca wymaga dwóch.

Sprawdź swój DKIM

1. Sprawdź domenę i selektor w narzędziu Sprawdzanie DKIM. Podąża ono za delegowaniem przez CNAME i pokazuje typ i długość klucza, unieważnione klucze, tryb testowy oraz błędy publikacji, takie jak cudzysłowy czy spacje wklejone do klucza.
2. Opublikowany klucz nie dowodzi, że poczta jest podpisywana pasującym kluczem prywatnym. Wyślij wiadomość testową i sprawdź w Analizatorze nagłówków e-mail, czy jest dkim=pass z Twoją domeną.
3. Upewnij się, że d= poprawnego podpisu jest zgodne z domeną z From, i sprawdź w narzędziu Sprawdzanie DMARC, jaka polityka obowiązuje dla poczty, która nie przejdzie weryfikacji.