# Co naprawdę oznacza „dkim=pass”

> Uwierzytelnianie poczty wypadło pomyślnie. To dowód, że domena podpisała wiadomość, a nie że faktura jest prawdziwa ani że rachunek należy do dostawcy.

Canonical: https://vetthisvendor.com/pl/guide/dkim-pass-does-not-mean-genuine
Published: 2026-08-12. Updated: 2026-08-12.
Author: Jose Pollman, VetThisVendor.

Jeśli po otwarciu nagłówków wiadomości widnieje w nich linia w rodzaju
`dkim=pass header.d=supplier.com; spf=pass; dmarc=pass`, a pytanie brzmi, czy to znaczy, że
wiadomość jest bezpieczna: **znaczy to, że wiadomość rzeczywiście przyszła z tej domeny, i
nic ponadto.** Nie mówi nic o tym, czy faktura jest prawdziwa, czy dane rachunku się
zgadzają, ani czy pisał rzeczywiście dostawca.

To nie jest formalność. Najdroższe oszustwa fakturowe w Europie przechodzą wszystkie trzy
sprawdzenia, za każdym razem, ponieważ wychodzą z prawdziwej skrzynki dostawcy. Jeśli masz
przed sobą prośbę o płatność,
[sprawdzanie e-maila od dostawcy](/pl/tools/supplier-email-check) odczyta tę wiadomość i
powie, które z tych rzeczy dało się faktycznie ustalić — i, co równie ważne, których nie.

## O co tak naprawdę pyta każde z trzech sprawdzeń

Zapisuje się je często tak, jakby były jednym werdyktem. To trzy różne pytania i żadne z
nich nie brzmi „czy ten e-mail jest uczciwy”.

**SPF** pyta, czy serwer, który doręczył wiadomość, należy do tych, które właściciel domeny
wskazał jako uprawnione do wysyłki. To pytanie o adres IP. Nie mówi nic o tym, kto napisał
wiadomość ani co się w niej znajduje.

**DKIM** pyta, czy podpis kryptograficzny obejmujący fragmenty wiadomości zgadza się z
kluczem publicznym opublikowanym w DNS tej domeny. Wynik pozytywny oznacza, że ktoś
dysponujący kluczem prywatnym tej domeny podpisał te fragmenty i że od tego czasu nie
zostały zmienione. To najmocniejsze z trzech — i jest wypowiedzią o *domenie*, a nie o
*zamiarach nadawcy*.

**DMARC** pyta, czy SPF albo DKIM wypadły pomyślnie dla domeny zgodnej z adresem w polu
`From:`, który widzi czytający, i mówi serwerom odbierającym, co robić, gdy nie wypadło
pomyślnie żadne z nich. Wiąże pozostałe dwa sprawdzenia z widocznym nadawcą. To realna
wartość i nadal nie jest twierdzeniem o treści.

Zatem `dkim=pass header.d=supplier.com` oznacza: to naprawdę jest domena dostawcy. Czyli
dokładnie to, czego należy się spodziewać, gdy w skrzynce dostawcy siedzi przestępca.

## Oszustwo, które przechodzi każde sprawdzenie

Wersja oszustwa fakturowego, która się udaje, to nie łudząco podobna domena. To
**prawdziwa wiadomość z prawdziwej skrzynki prawdziwego dostawcy**, do której zwykle
dotarto hasłem z niepowiązanego wycieku albo ze strony phishingowej wypełnionej tygodnie
wcześniej.

Wszystko przechodzi uwierzytelnienie, bo wszystko jest prawdziwe:

- wiadomość jest podpisana własną domeną dostawcy, więc DKIM przechodzi;
- wychodzi od jego własnego dostawcy poczty, więc SPF przechodzi;
- adres w polu `From:` się zgadza, więc DMARC przechodzi;
- historia wątku jest prawdziwa, bo to prawdziwy wątek.

Nowe są wyłącznie dane rachunku. Uwierzytelnianie poczty nie ma o danych rachunku żadnego
zdania.

Dlatego „e-mail przeszedł uwierzytelnienie” nigdy nie jest powodem do zapłaty i dlatego
każdy wynik na tej stronie — łącznie z czystym — kończy się tym samym zdaniem o telefonie
pod numer, który miało się już wcześniej. Dłuższy opis jest w poradniku
[dostawca prosi o zmianę rachunku bankowego](/pl/guide/supplier-changed-bank-details).

## Kto napisał linię, którą czytasz

Jest jeszcze druga pułapka i łatwo ją przeoczyć.

`Authentication-Results:` to nagłówek zapisany przez **serwer pocztowy, który odebrał
wiadomość** — zwykle przez własnego dostawcę poczty. Czytając tam `dkim=pass`, czyta się
cudzy werdykt, zapisany w chwili doręczenia. Zwykle jest wiarygodny, bo zapisał go własny
dostawca.

Ale nagłówki to zwykły tekst. Jeśli blok został przesłany dalej, wklejony do zgłoszenia,
skopiowany ze zrzutu ekranu od kogoś innego albo podany przez tego, kto prosi o zapłatę, to
linia mówiąca `dkim=pass` jest twierdzeniem tego, kto ten tekst wytworzył — a wpisać ją może
każdy. Nagłówka mówiącego, że kryptografia się powiodła, nie chroni żadna kryptografia.

Uczciwe rozróżnienie przebiega między trzema całkiem różnymi sytuacjami:

| Co jest w ręku | Co da się ustalić |
|---|---|
| Pełna oryginalna wiadomość wraz z podpisem | Podpis da się **sprawdzić teraz**, samodzielnie |
| Same nagłówki, z linią `Authentication-Results` | **Zapisany werdykt serwera odbierającego**, przyjęty na wiarę |
| Ani jedno, ani drugie — tylko widoczny e-mail | Wyłącznie to, co publikuje domena: SPF, DMARC, MX |

Narzędzie, które pokazuje drugą z nich i nazywa ją pierwszą, mówi coś, czego nie da się w
żaden sposób sprawdzić. [Sprawdzanie e-maila od dostawcy](/pl/tools/supplier-email-check)
zaznacza, które z tych trzech wykonuje, i nigdy nie awansuje jednego na drugie: `dkim=pass`
siedzące we wklejonym bloku nagłówków jest podawane jako werdykt odbiorcy, dokładnie tymi
słowami.

## Kiedy wynik negatywny znaczy więcej niż pozytywny

Wynik pozytywny to słaba przesłanka. **Wynik negatywny to mocna przesłanka** i warto się
przy nim zatrzymać.

Jeśli weryfikacja DKIM rzeczywiście się wykona i wypadnie niezgodnie — podpis nie pasuje do
treści — to wiadomość zmieniono po podpisaniu albo ta domena nigdy jej nie podpisała. Jeśli
DMARC jest ustawiony na `p=reject`, a wiadomość mimo to nie przeszła, to nie powinna była
zostać doręczona.

Jest tu jedna asymetria warta zapamiętania: *nie dało się sprawdzić* to nie to samo co
*wypadło negatywnie*. Nieosiągalne zapytanie DNS, unieważniony klucz, wygasły podpis albo
podpis obejmujący tylko część treści — każde z nich oznacza, że obliczenia nie dało się
przeprowadzić do końca. To nie jest ustalenie przeciwko nadawcy, a narzędzie, które
przedstawia je jako takie, marnuje jedyny sygnał, na który warto było zareagować.

## Co zrobić z wiadomością, co do której są wątpliwości

1. **Nie odpowiadać na nią.** Jeśli skrzynka jest przejęta, odpowiedź trafia do napastnika,
   a reguła w skrzynce może ukryć ją przed prawdziwym dostawcą.
2. **Zadzwonić do dostawcy** pod numer ze starej faktury, z systemu księgowego albo ze
   strony internetowej, na którą weszło się samodzielnie, wpisując adres.
3. **Sprawdzić identyfikatory osobno** — numer VAT, wpis w rejestrze przedsiębiorców oraz,
   przy polskim dostawcy, czy rachunek jest
   [na białej liście](/pl/guide/polish-white-list).
   [Sprawdzanie faktury](/pl/tools/invoice-checker) robi to wszystko wprost z dokumentu.
4. **Traktować zmianę danych rachunku jako właściwe zdarzenie**, a nie e-mail wokół niej.
   To ona jest warta telefonu, cokolwiek mówią nagłówki.

## Czego to nie powie

Uwierzytelnianie poczty jest kontrolą *kanału*, a nie *twierdzenia*. Nie powie, że towar
zamówiono, że kwota się zgadza, że osoba pisząca nadal tam pracuje ani że rachunek należy
do dostawcy. Polska jest jedynym krajem w UE, który publikuje odpowiedź na to ostatnie
pytanie — i dlatego [biała lista](/pl/guide/polish-white-list) jest warta użycia tam, gdzie
ma zastosowanie.

Wszędzie indziej kontrolą, która to wychwytuje, jest rozmowa głosowa pod numerem, który
miało się już wcześniej.