SPF: kto ma prawo wysyłać
RFC 7208 wychodzi od stwierdzenia: nic w protokole poczty nie uniemożliwia serwerowi podania dowolnego adresu nadawcy. SPF pozwala właścicielowi domeny opublikować w DNS listę serwerów uprawnionych do wysyłania w jego imieniu, a serwerowi odbierającemu – sprawdzić to uprawnienie.
Dwa doprecyzowania zmieniają wszystko:
- SPF sprawdza adres koperty (używany w komunikacji między serwerami, tzw. „MAIL FROM”) i nazwę podawaną przez serwer, a nie adres, który odbiorca widzi w polu „Od”.
- SPF ocenia ostatni serwer, który doręczył wiadomość. Gdy wiadomość jest przekazywana przez inny serwer, nie doręcza jej już serwer uprawniony przez domenę źródłową: weryfikacja może się nie powieść, mimo że wiadomość jest prawidłowa.
Domena publikuje tylko jeden rekord SPF. Muszą się w nim znaleźć wszystkie źródła wysyłki: system pocztowy, program do fakturowania, narzędzie do newsletterów, CRM, kopiarka skanująca do e-maila.
DKIM: wiadomość jest podpisana
Zgodnie z RFC 6376 DKIM pozwala właścicielowi domeny podpisującej przyjąć część odpowiedzialności za wiadomość za pomocą podpisu kryptograficznego. Klucz publiczny znajduje się w DNS. Weryfikacja podpisu potwierdza, że podpisane części nie zmieniły się od chwili podpisania.
Podpis podróżuje razem z wiadomością. Dlatego lepiej niż SPF znosi przekazanie przez serwer pośredniący lub przekierowanie, o ile pośrednik nie zmienia tematu ani treści. Lista dystrybucyjna, która dodaje adnotację na dole wiadomości, unieważnia podpis.
Czego DKIM nie robi, według tego samego RFC: nie szyfruje wiadomości, niepowodzenie weryfikacji nie oznacza obowiązku odrzucenia, a domena podpisująca nie musi być tą widoczną w polu „Od”. To właśnie tę lukę wypełnia DMARC.
DMARC: dopasowanie i polityka
RFC 7489 definiuje DMARC jako sposób, w jaki właściciel domeny może wyrazić politykę na poziomie domeny. Mechanizm opiera się na dopasowaniu (alignment): domena adresu widocznego w polu „Od” musi odpowiadać domenie zweryfikowanej przez SPF lub DKIM. Jeśli żadna z nich nie jest dopasowana, DMARC zwraca wynik negatywny.
Domena publikuje wtedy swoje życzenie:
- none: żadne działanie nie jest wymagane, trwa obserwacja;
- quarantine: traktować wiadomość jako podejrzaną;
- reject: odrzucić wiadomość.
DMARC przewiduje też raporty: raporty zbiorcze, które podsumowują, które serwery wysyłały w imieniu domeny i z jakim wynikiem, oraz raporty o niepowodzeniach, dla poszczególnych wiadomości. To dzięki nim można odkryć zapomniane narzędzie, które wysyła w Państwa imieniu, albo kogoś, kto podszywa się pod Państwa domenę.
| Mechanizm | Co sprawdza | Czego nie bada |
|---|
| SPF | Czy serwer doręczający wiadomość jest uprawniony dla domeny koperty | Wyświetlanego adresu, treści |
| DKIM | Czy podpisana wiadomość nie została zmieniona; domena bierze za nią odpowiedzialność | Wyświetlanego adresu, rzetelności treści |
| DMARC | Czy wyświetlana domena jest dopasowana do SPF lub DKIM; polityka w razie niepowodzenia | Domen podobnych, nazwy wyświetlanej, tekstu |
Czy DMARC blokuje phishing?
Blokuje część przypadków podszywania się pod domenę, ale nie phishing w ogóle. RFC 7489 mówi to wprost: DMARC nie zajmuje się nazwami domen wizualnie podobnymi ani nadużyciem nazwy wyświetlanej, a analiza treści wykracza poza jego zakres. Nie próbuje rozwiązać wszystkich problemów związanych z oszukańczą pocztą.
W praktyce DMARC nie widzi:
- domeny podobnej: oszust bez zarzutu uwierzytelnia własną domenę, która przypomina Państwa domenę;
- podrobionej nazwy wyświetlanej: „Dział księgowości” piszący z niezwiązanego adresu;
- przejętego konta, które prawidłowo podpisuje wiadomości, ponieważ wysyła je prawdziwy serwer;
- wiadomości niezwiązanej z Państwa domeną: fałszywe powiadomienie od przewoźnika przychodzi z domeny, która nie ma nic wspólnego z Państwa domeną;
- domeny bez polityki: jeśli naśladowana domena publikuje „none”, odbiorca nie otrzymuje polecenia odrzucenia.
Te przypadki wymagają innych analiz: podobieństwa domen, reputacji, treści, zachowania. Zob. spam, phishing, malware i przejęte konto.
Przekazywanie i listy dystrybucyjne: ARC
Przekazanie często unieważnia SPF, lista, która modyfikuje wiadomość, unieważnia DKIM, a DMARC zwraca wtedy wynik negatywny dla prawidłowej wiadomości. ARC, opisany w RFC 8617 (status eksperymentalny), pozwala każdemu pośrednikowi poświadczyć stwierdzony przez siebie wynik uwierzytelnienia. Serwer docelowy może zdecydować, czy go uwzględnić.
Ochrona własnej domeny a filtrowanie poczty przychodzącej
To dwa tematy, które często się myli.
- Ochrona domeny wysyłającej: opublikowanie SPF, DKIM i DMARC dla Państwa domeny, aby inni mogli odrzucać wiadomości, które się pod nią podszywają. To Państwo publikują; to odbiorcy stosują.
- Filtrowanie poczty przychodzącej: sprawdzanie rekordów innych domen w otrzymywanej poczcie, a następnie stosowanie wszystkich pozostałych analiz.
Stopniowe wdrażanie
- Inwentaryzacja wszystkiego, co wysyła wiadomości w imieniu domeny.
- Jeden rekord SPF, który je autoryzuje; podpis DKIM dla każdej usługi, która potrafi podpisywać.
- DMARC w trybie „none”, z adresem do odbioru raportów.
- Analiza raportów przez kilka tygodni; korekta zapomnianych źródeł.
- Przejście na „quarantine”, a następnie na „reject”, gdy wszystkie prawidłowe wysyłki są dopasowane.
Przykład, dla ilustracji. Kancelaria publikuje DMARC w trybie „none” i czyta pierwsze raporty. Odkrywa w nich trzy źródła: swój system pocztowy, poprawnie dopasowany; program do fakturowania, który wysyła faktury z domeną kancelarii bez podpisu DKIM; oraz nieznany serwer za granicą, który wysyła w jej imieniu setki wiadomości. Kancelaria poprawia program do fakturowania, czeka na czysty cykl raportów, po czym przechodzi na „quarantine”: odbiorcy stosujący DMARC traktują odtąd wiadomości z nieznanego serwera jako podejrzane.
Przy zmianie systemu pocztowego rekordy te przygotowuje się przed zmianą rekordu MX. Ten moment opisuje przewodnik migracja poczty bez przerwy w działaniu; nie powtarzamy go tutaj.
Najczęściej zadawane pytania
Czy polityka DMARC „none” chroni?
Nie. Pozwala obserwować dzięki raportom. Ochrona zaczyna się od „quarantine” lub „reject”.
Dlaczego prawidłowa wiadomość nie przechodzi weryfikacji DMARC?
Najczęściej z powodu przekazania, listy dystrybucyjnej albo usługi, która wysyła w Państwa imieniu, nie będąc zadeklarowana w SPF ani nie podpisując w DKIM.
Nasz system pocztowy nie podpisuje w DKIM: co zrobić?
Bramka umieszczona na ścieżce wysyłki może podpisywać za niego. Zob. Ochrona poczty, z której Państwo już korzystają.
Gdzie odczytać wynik tych kontroli dla otrzymanej wiadomości?
W nagłówkach wiadomości. W przypadku Klytic MTA zob. Odczyt i eksport decyzji filtra.
Gdzie plasuje się Klytic
Klytic MTA obsługuje oba tematy, przed każdym systemem pocztowym:
- Essential i Advanced: kontrola SPF, DKIM i MX; weryfikacja DMARC, również dla przekazywanych wiadomości dzięki ARC; podpis DKIM wysyłanych wiadomości, nawet jeśli Państwa system pocztowy tego nie robi.
- Advanced: konsola DMARC, z raportami Państwa domen, alertami i wskazówkami dotyczącymi poprawek, aby przeprowadzić stopniowe przejście na „reject”.
DMARC to tylko jedna warstwa: Klytic MTA dodaje wykrywanie domen łudząco podobnych, nazwy wyświetlanej i scenariuszy oszustw, opisane w przewodniku podszywanie się i oszustwo „na prezesa”.
Jeśli korzystają Państwo z Klytic Mail, SPF, DKIM i DMARC są skonfigurowane dla Państwa domeny: to ochrona domeny wysyłającej. Klytic MTA można natomiast wykupić z Klytic Mail lub bez niego.
Źródła
Stan na październik 2026.
- RFC 7208, SPF: właściciel domeny publikuje hosty uprawnione do używania jego domeny w tożsamości „MAIL FROM” lub „HELO”, a odbiorca sprawdza to uprawnienie. rfc-editor.org
- RFC 6376, DKIM: domena przyjmuje odpowiedzialność za wiadomość za pomocą podpisu kryptograficznego; brak szyfrowania, brak obowiązku odrzucenia, możliwa domena podpisująca inna niż wyświetlany autor. rfc-editor.org
- RFC 7489, DMARC: dopasowanie domeny z pola „From” do SPF lub DKIM, polityki none, quarantine i reject, raporty zbiorcze i raporty o niepowodzeniach; domeny wizualnie podobne, nazwa wyświetlana i analiza treści poza zakresem. rfc-editor.org
- RFC 9989 (maj 2026), zastępujący RFC 7489: te same wartości polityki i te same wyłączenia (domeny podobne, nazwa wyświetlana). rfc-editor.org
- RFC 8617, ARC (eksperymentalny): uwierzytelniony łańcuch przekazywania; odbiorca stosujący DMARC może uznać oceny zawarte w ważnym łańcuchu ARC. rfc-editor.org
- Klytic, strona Klytic MTA: kontrole uwierzytelniania, podpis DKIM poczty wychodzącej i konsola DMARC w pakietach Essential i Advanced, opcje, tryby wdrożenia, uruchomienie przez zmianę rekordu MX. klytic.com
