Rekord DKIM: konfiguracja krok po kroku i częste błędy

Twoje maile twierdzą, że są od Ciebie. DKIM to udowadnia.

Ktoś kiedyś skonfigurował DKIM dla Twojej domeny i temat uznano za zamknięty. Aż klient wspomina, że przypomnienie o płatności trafiło mu do spamu, albo raport DMARC pełen jest wpisów dkim=fail, i nikt nie potrafi powiedzieć, czy ten rekord w ogóle kiedyś działał.

Dobra wiadomość: DKIM jest prosty, rekord to jeden wpis w DNS, a prawie każda awaria wynika z kilku typowych błędów przy kopiowaniu. Poniżej wyjaśniamy DKIM po ludzku i pokazujemy, jak naprawić każdy z nich.

Co właściwie robi DKIM

DKIM (DomainKeys Identified Mail) to podpis cyfrowy dołączany do każdego wysyłanego maila — coś jak lakowa pieczęć na liście. Składa się z trzech elementów:

• Klucz prywatny zostaje na serwerze wysyłkowym i podpisuje każdą wiadomość, tworząc „odcisk” treści i nagłówków, takich jak From, Subject czy Date.
• Klucz publiczny jest opublikowany w DNS Twojej domeny, gdzie każdy może go odczytać.
• Selektor to etykieta, która mówi serwerowi odbiorcy, który klucz pobrać. Jedna domena może mieć kilka kluczy — dla poczty firmowej, programu do faktur, przypomnień dla klientów — a selektory pozwalają je rozróżnić.

Gdy Gmail albo Outlook odbiera Twoją wiadomość, czyta nagłówek DKIM-Signature, wyciąga z niego domenę podpisującą (d=) i selektor (s=), pobiera klucz publiczny z DNS i sprawdza pieczęć. Jeśli się zgadza, wiadomość pochodzi od właściciela domeny i nikt jej po drodze nie zmienił.

DKIM nie określa, które serwery mogą wysyłać w Twoim imieniu (to zadanie SPF), ani nie mówi odbiorcom, co zrobić, gdy weryfikacja zawiedzie (to robi DMARC). Od lutego 2024 Gmail i Yahoo wymagają od masowych nadawców wszystkich trzech.

Budowa rekordu DKIM

Rekord DKIM to rekord TXT opublikowany pod adresem selektor._domainkey.twojadomena.pl. Dla selektora s1 i domeny example.com znajduje się pod s1._domainkey.example.com, a jego wartość wygląda tak:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5x...IDAQAB

• v=DKIM1 — wersja. Zawsze dokładnie taka.
• k=rsa — typ klucza. RSA stosuje praktycznie każdy dostawca.
• p= — klucz publiczny, długi ciąg w base64. Ten fragment psuje się najczęściej.
• t=y (opcjonalnie) — tryb testowy. Usuń go, gdy podpisywanie już działa.

Niektórzy dostawcy każą zamiast tego utworzyć rekord CNAME, który kieruje s1._domainkey.example.com na hosta po ich stronie. To w porządku — trzymają klucz u siebie i mogą go za Ciebie wymieniać. Po prostu utwórz taki typ rekordu, jaki dostałeś.

Konfiguracja DKIM krok po kroku

1. Wygeneruj klucz na platformie wysyłkowej. Platforma tworzy parę kluczy i pokazuje hosta oraz wartość do opublikowania.
2. Skopiuj oba pola dokładnie, najlepiej przyciskami „Kopiuj”.
3. Dodaj rekord u swojego dostawcy DNS (rejestrator, Cloudflare, panel hostingu). Typ: TXT albo CNAME, jeśli tak każe instrukcja. Host: np. s1._domainkey. Wartość: cały ciąg v=DKIM1; ....
4. Poczekaj na propagację DNS — zwykle kilka minut, czasem do 48 godzin.
5. Sprawdź i przetestuj. Zweryfikuj rekord niezależnym narzędziem, a potem wyślij maila na Gmaila, wybierz „Pokaż oryginał” i poszukaj wpisu DKIM: 'PASS' with domain example.com.

Najczęstsze błędy DKIM i jak je naprawić

1. Cudzysłowy i łamanie linii w wartości

Klucz 2048-bitowy ma ponad 255 znaków, czyli więcej niż maksymalna długość pojedynczego ciągu w rekordzie TXT. Dlatego DNS przechowuje go jako kilka fragmentów w cudzysłowach — "v=DKIM1; k=rsa; p=MIIBIjAN..." "...IDAQAB" — a resolwery sklejają je z powrotem. Problem pojawia się, gdy:

• wklejasz cudzysłowy do panelu, który dodaje własne, i w rekordzie zostają dosłowne znaki cudzysłowu;
• kopiujesz klucz z PDF-a lub maila i przenosisz łamania linii albo spacje w środku klucza;
• dzielisz klucz na dwa osobne rekordy TXT zamiast na dwa ciągi w jednym rekordzie.

Rozwiązanie: wklejaj wartość bez cudzysłowów, chyba że dostawca DNS wyraźnie każe inaczej — większość paneli sama dzieli długie wartości. Potem sprawdź opublikowany rekord i porównaj końcówkę p= z oryginałem; to tam widać ucięcie.

2. Zły selektor albo zła nazwa hosta

Selektor w DNS musi być taki sam jak s=, którym podpisuje Twoja platforma. Klucz opublikowany pod default._domainkey, a platforma podpisuje selektorem s1? Serwery odbiorców szukają hosta, który nie istnieje. Sprawdź też pisownię: _domainkey, z podkreślnikiem na początku.

Żeby poznać swój selektor, otwórz wysłanego przez siebie maila, wyświetl pełne nagłówki i odczytaj s= w linii DKIM-Signature. Popularne selektory to m.in. google (Google Workspace) oraz selector1 / selector2 (Microsoft 365).

3. Domena dopisana dwa razy

Wiele paneli DNS automatycznie dokleja domenę do tego, co wpiszesz w polu hosta. Wpisujesz s1._domainkey.example.com, a rekord powstaje pod s1._domainkey.example.com.example.com. W panelu wszystko wygląda dobrze, a każde zapytanie kończy się błędem.

Rozwiązanie: wpisz tylko s1._domainkey i sprawdź pełną nazwę narzędziem do wyszukiwania rekordów. W tę samą pułapkę wpadają rekordy SPF — zobacz nasz poradnik o naprawianiu błędów w rekordzie SPF.

4. Klucz 1024 czy 2048 bitów

Klucze 1024-bitowe wciąż są akceptowane przez największych dostawców poczty, ale zalecanym standardem jest dziś 2048 bitów — wybierz go, jeśli masz taką możliwość. Jeśli Twój panel DNS nie przyjmuje długich wartości TXT, zapytaj dostawcę wysyłki o konfigurację opartą na CNAME.

5. Brak rotacji klucza

Klucze nie powinny żyć wiecznie. Bezpieczna rotacja wygląda tak: publikujesz nowy klucz pod nowym selektorem (np. s2), zostawiając stary na miejscu, przełączasz na niego podpisywanie, trzymasz stary rekord jeszcze kilka dni dla wiadomości, które są w drodze, i dopiero wtedy go usuwasz. Nadpisanie klucza w miejscu tworzy okno, w którym podpisy nie przechodzą.

6. Przekierowania i stopki, które psują podpis

DKIM podpisuje treść wiadomości. Jeśli cokolwiek zmieni ją po podpisaniu, odcisk przestaje się zgadzać:

• listy mailingowe dodające stopkę z wypisem albo prefiks [Lista] w temacie;
• bramki bezpieczeństwa, które przepisują linki albo wstawiają baner „Nadawca zewnętrzny”;
• klauzula dopisywana przez Twój własny serwer pocztowy po podpisaniu wiadomości przez platformę.

Zwykłe przekierowanie zazwyczaj nie narusza DKIM — dlatego przy przekazywanej poczcie DKIM jest ważniejszy niż SPF. Problemem jest modyfikacja treści, więc zadbaj, by nic po Twojej stronie nie zmieniało wiadomości po podpisaniu.

7. DKIM przechodzi, ale nie jest zgodny z domeną nadawcy

Raport DMARC pokazuje, że DKIM przeszedł, a mimo to DMARC nie przeszedł. Chodzi o zgodność domen (alignment): DMARC uwzględnia DKIM tylko wtedy, gdy domena podpisująca (d=) pasuje do domeny w widocznym adresie From.

• From faktury@example.com, podpis d=example.com → zgodne.
• From faktury@example.com, podpis d=mail.example.com → zgodne w trybie relaxed (domyślnym).
• From faktury@example.com, podpis d=jakasplatforma.net → DKIM przechodzi, ale nie jest zgodny, więc DMARC go ignoruje.

Zanim ustawisz DMARC na p=quarantine albo p=reject, każda usługa wysyłająca w imieniu Twojej domeny musi mieć zgodny DKIM (albo zgodny SPF). W poradniku DMARC: od p=none do p=reject pokazujemy, jak przejść tę drogę bezpiecznie.

Szybka checklista DKIM

• Rekord pod selektor._domainkey.twojadomena.pl, z domeną wpisaną tylko raz.
• Selektor zgadza się z s= w prawdziwych mailach.
• Wartość zaczyna się od v=DKIM1, ma jeden kompletny klucz p=, bez zbędnych cudzysłowów i spacji, jeden rekord na selektor.
• Klucz 2048-bitowy, jeśli to możliwe; żadnego t=y na produkcji.
• Domena podpisująca d= zgodna z domeną w polu From.
• Każda usługa wysyłająca w imieniu Twojej domeny ma własny, działający selektor.

Jak MailerBit obsługuje DKIM

MailerBit wysyła przypomnienia o płatnościach, zestawienia dla klientów i inne cykliczne maile, w których każdy odbiorca dostaje własne dane — czyli wiadomości, które nie mogą trafić do spamu. Dlatego przed wysłaniem kampanii weryfikujesz własną domenę.

• Ustawienia domeny pokazują dokładnie te rekordy, które trzeba dodać — rekord TXT dla DKIM i CNAME dla Return-Path — z hostem, wartością i przyciskami „Kopiuj”.
• Przycisk „Sprawdź weryfikację” oznacza każdy rekord jako zweryfikowany albo oczekujący.
• Kampanie są podpisywane DKIM dla Twojej własnej domeny, więc podpis jest zgodny z adresem From na potrzeby DMARC.
• Na własnej domenie budujesz własną reputację, nowe domeny przechodzą automatyczne, pięciodniowe rozgrzewanie, a konta z odsetkiem zwrotów powyżej 5% lub zgłoszeń spamu powyżej 0,1% są automatycznie wstrzymywane.

Więcej na stronie o dostarczalności.

Skonfiguruj DKIM raz, a porządnie

DKIM to pięć minut pracy, gdy rekord trafi do DNS poprawnie, i tygodnie zgadywania, gdy coś pójdzie nie tak. Sprawdź swoje selektory w narzędziu do sprawdzania DKIM, popraw to, co wskaże, a jeśli chcesz platformę, która sama wygeneruje rekordy i podpisze każde przypomnienie i zestawienie Twoją domeną, załóż konto w MailerBit.