Kluczowe wnioski
- Metody uwierzytelniania wiadomości e-mail pozwalają sprawdzić, czy wiadomość rzeczywiście pochodzi z danej domeny i nie została sfałszowana.
- SPF, DKIM i DMARC to trzy podstawowe mechanizmy. Każdy z nich sprawdza coś innego, a najlepiej sprawdzają się w połączeniu.
- Razem zapobiegają podszywaniu się, chronią Twoje wiadomości przed trafieniem do folderu spamowego oraz zabezpieczają Twoją markę w serwisach Gmail, Outlook i Yahoo.
- Standardy ARC, MTA-STS, TLS-RPT i BIMI rozszerzają tę ochronę na wiadomości przekazywane dalej, szyfrowany transfer danych oraz logo marek.
- Bez nich każdy może sfałszować Twoją domenę, a Ty nie masz żadnego wglądu w to, w jaki sposób jest ona wykorzystywana.
- Raporty DMARC pozwalają znacznie szybciej zidentyfikować nieautoryzowanych nadawców i błędy niż ręczne sprawdzanie DNS lub nagłówków.
Metody uwierzytelniania wiadomości e-mail to protokoły – przede wszystkim SPF, DKIM i DMARC – które pozwalają serwerom odbiorczym zweryfikować, czy wiadomość rzeczywiście pochodzi z Twojej domeny. Bez nich każdy może sfałszować Twój adres nadawcy, a Twoje legalne wiadomości z większym prawdopodobieństwem trafią do folderu ze spamem.
Prawidłowo skonfigurowane metody te chronią Twoją markę przed podszywaniem się, zapewniają, że legalne wiadomości e-mail trafiają do skrzynki odbiorczej, oraz pokazują dokładnie, w jaki sposób wykorzystywana jest Twoja domena. Ponieważ firmy takie jak Google, Yahoo, Microsoft i Apple wprowadzają obecnie wymóg uwierzytelniania nadawców wysyłających masowo, konfiguracja ta nie jest już opcjonalna. Niniejszy przewodnik omawia główne metody uwierzytelniania wiadomości e-mail, sposób działania każdej z nich, wpływ na dostarczalność oraz sposoby ich wdrożenia.
Dla zespołów zarządzających wieloma domenami lub usługami wysyłkowymi trudnością nie jest jednorazowe opublikowanie rekordów, ale utrzymanie widoczności w sytuacji, gdy każde nowe oprogramowanie CRM, platforma marketingowa, system pomocy technicznej lub domena regionalna zmienia obrazu SPF, DKIM i DMARC podlegające zmianom.
Czym jest uwierzytelnianie wiadomości e-mail?
Uwierzytelnianie wiadomości e-mail to zbiór metod służących do weryfikacji, czy wiadomość rzeczywiście pochodzi z domeny, którą podaje, i czy nie została sfałszowana podczas przesyłania. Metody te, przede wszystkim SPF, DKIM i DMARC, są publikowane w systemie DNS w postaci rekordów TXT. Gdy serwer odbiorczy sprawdza przychodzącą wiadomość, odwołuje się do tych rekordy DNS w celu potwierdzenia własności domeny i podjęcia decyzji, czy wiadomość należy dostarczyć, przekierować do folderu spamu, czy też odrzucić.
Warto wiedzieć
Uwierzytelnianie jest często mylone z trzema pokrewnymi pojęciami. Uwierzytelnianie pozwala zweryfikować, kto wysłał wiadomość. Autoryzacja określa, jakie działania może podjąć nadawca. Szyfrowanie chroni treść podczas przesyłania. Reputacja nadawcy odzwierciedla historię wysyłek danej domeny oraz wskaźniki skarg. Wszystkie cztery czynniki mają wpływ na dostarczalność, choć to właśnie uwierzytelnianie stanowi fundament, na którym opierają się pozostałe trzy.
Podstawowe metody uwierzytelniania wiadomości e-mail: SPF, DKIM i DMARC
Oto metody, dzięki którym uwierzytelnianie wiadomości e-mail działa – każda z nich odpowiada za inny etap weryfikacji.
SPF, DKIM i DMARC można traktować jako trzy warstwy weryfikacji tożsamości. SPF potwierdza, że serwer wysyłający ma uprawnienia do wysyłania wiadomości w imieniu Twojej domeny. DKIM potwierdza, że treść wiadomości nie została zmieniona podczas przesyłania. DMARC sprawdza, czy wyniki tych weryfikacji są zgodne z widocznym adresem nadawcy, i określa, jakie działania powinni podjąć dostawcy usług, gdy tak nie jest.
| Protokół | Co weryfikuje | Dlaczego to ma znaczenie | Główne ograniczenia |
|---|---|---|---|
| SPF | Czy adres IP nadawcy jest autoryzowany | Ogranicza fałszowanie tożsamości i nadużycia ze strony nadawców | Limit 10 wyszukiwań DNS; przerywa przekazywanie |
| DKIM | Czy wiadomość została zmieniona podczas przesyłania | Zapewnia integralność wiadomości | Nie weryfikuje widocznego adresu nadawcy |
| DMARC | Czy SPF lub DKIM są zgodne z domeną „From” | Umożliwia egzekwowanie zasad i generowanie raportów | Do działania wymagane jest SPF lub DKIM |
| BIMI | Wyświetlanie logo marki w przypadku wiadomości zweryfikowanych | Zwiększa zaufanie do marki i rozpoznawalność w skrzynce odbiorczej | Wymagane jest ustawienie DMARC na p=quarantine lub p=reject |
| MTA-STS | Wymuszone zabezpieczenie transportu TLS | Zapobiega atakom polegającym na obniżeniu poziomu bezpieczeństwa oraz przechwyceniu danych | Wymaga umieszczenia pliku zasad HTTPS na serwerze |
| TLS-RPT | Raportowanie błędów dostarczania TLS | Zapewnia wgląd w problemy związane z warstwą transportową | Rawne raporty w formacie JSON trudno jest przetworzyć ręcznie |
| ARC | Łańcuch uwierzytelniania dla przekazywanej poczty | Zachowuje uwierzytelnienie podczas przekazywania | Działa tylko wtedy, gdy serwer odbiorczy obsługuje ARC |
SPF (Sender Policy Framework)

Sender Policy Framework stanowi pierwszą warstwę ochrony. SPF zapobiega fałszowaniu adresów, określając autoryzowane adresy IP, z których można wysyłać wiadomości e-mail z danej domeny. Sprawdza on tożsamość nadawcy wyłącznie na podstawie pola MAIL FROM i nie bierze pod uwagę adresu „Od”, który widzi odbiorca, ponieważ SPF skupia się na kopercie wiadomości, czyli polu Return-Path, a nie na widocznym nagłówku. Adres IP zgodny z listą przechodzi weryfikację; każdy inny zostaje odrzucony.
DKIM (DomainKeys Identified Mail)
Podczas gdy SPF weryfikuje serwer wysyłający, DKIM sprawdza, czy treść nie została zmodyfikowana podczas przesyłania. Dodaje on podpis cyfrowy przy użyciu kluczy kryptograficznych: serwer nadawcy podpisuje każdą wiadomość kluczem prywatnym, generując podpis DKIM dołączany do nagłówków, a serwer odbiorczy pobiera pasujący klucz publiczny z DNS w celu weryfikacji. Jeśli podpis się zgadza, a treść nie została zmodyfikowana, weryfikacja DKIM przebiega pomyślnie, potwierdzając, że wiadomość rzeczywiście pochodzi z deklarowanej domeny i nie została zmieniona w trakcie przesyłania.
DMARC (Domain-based Message Authentication, Reporting and Conformance - uwierzytelnianie, raportowanie i zgodność wiadomości w oparciu o domenę)
DMARC to protokół, który łączy wszystkie te elementy. Sprawdza on, czy przychodząca wiadomość e-mail spełnia wymagania SPF lub DKIM oraz czy domena użyta w tych sprawdzaniach jest zgodna z adresem nadawcy. Właśnie ten wymóg zgodności sprawia, że DMARC skutecznie wykrywa sfałszowane wiadomości, które przedostają się przez systemy oparte wyłącznie na SPF lub DKIM, a także określa działania, jakie system odbiorczy powinien podjąć w przypadku niepowodzenia.
Opcje polityki DMARC są wykonywane w ściśle określonej kolejności:
- p=none: tylko monitorowanie. Nie ma to wpływu na komunikaty, a użytkownik otrzymuje zbiorcze raporty dotyczące wyników uwierzytelniania dla wszystkich nadawców. Jest to zalecany punkt wyjścia.
- p = kwarantanna: nieudane wiadomości trafiają do folderu spam lub wiadomości niechciane. Użyj tej opcji, gdy upewnisz się, że wszystkie wiadomości od zaufanych nadawców są prawidłowo dostarczane.
- p=odrzucenie: nieprawidłowe wiadomości są blokowane na serwerze odbiorczym. Jest to najsilniejszy poziom zabezpieczeń, który w pełni chroni Twoją domenę przed spoofingiem.
DMARC generuje również dwa rodzaje raportów: raporty zbiorcze RUA, podsumowujące wyniki dla wszystkich nadawców, oraz raporty analityczne RUF, zawierające szczegółowe informacje na poziomie poszczególnych wiadomości dotyczące niepowodzeń; oba rodzaje raportów są dostarczane w formacie XML na adresy podane w rekordzie DMARC.
Dodatkowe metody: ARC, MTA-STS, TLS-RPT oraz BIMI
To podstawowe trio zaspokaja większość potrzeb. Cztery dodatkowe protokoły rozszerzają ochronę o konkretne scenariusze: przekazywanie danych, szyfrowany transport, widoczność transportu oraz wyświetlanie marki.
ARC (autentyczny łańcuch odbiorczy)
Jeśli przekazujesz wiadomości e-mail za pośrednictwem list mailingowych, systemów zgłoszeń lub innych pośredników, przekazane wiadomości mogą czasami nie przejść weryfikacji SPF lub DKIM. ARC rozwiązuje ten problem, zachowując oryginalne wyniki uwierzytelniania na każdym etapie przesyłania. Gdy wiadomość przechodzi przez zaufanego pośrednika, ARC rejestruje wyniki na każdym etapie i tworzy łańcuch podpisany kryptograficznie, który serwer docelowy weryfikuje w celu potwierdzenia, że wiadomość e-mail została pierwotnie uwierzytelniona, nawet jeśli przekazanie spowodowało zniszczenie oryginalnego podpisu. Jest to częsta przyczyna błędów DMARC.
MTA-STS (Mail Transfer Agent Strict Transport Security)
MTA-STS wymaga szyfrowanych połączeń SMTP między serwerami pocztowymi, uniemożliwiając atakującym przechwytywanie lub przekształcanie ruchu do postaci zwykłego tekstu w atakach typu „man-in-the-middle”. Po skonfigurowaniu informuje serwery wysyłające, że muszą używać TLS w celu dostarczenia poczty do Twojej domeny oraz odmówić dostarczenia, jeśli nie uda się nawiązać bezpiecznego połączenia.
Usługi MTA-STS i TLS-RPT w modelu hostowanym upraszczają wdrażanie, eliminując konieczność ręcznego hostowania plików zasad i analizowania raportów transportowych, co stanowi wsparcie dla organizacji z branży finansowej, opieki zdrowotnej oraz sektora publicznego, dla których szyfrowany transfer danych stanowi wymóg zgodności z przepisami.
TLS-RPT (raportowanie TLS w protokole SMTP)
TLS-RPT zapewnia właścicielom domen wgląd w problemy z dostarczaniem wiadomości związane z szyfrowaniem TLS, wskazując, kiedy nie udało się bezpiecznie dostarczyć wiadomości. W połączeniu z protokołem MTA-STS pomaga zespołom szybciej wykrywać ataki typu „downgrade”, błędne konfiguracje zasad oraz awarie certyfikatów. Bez tego rozwiązania awarie szyfrowania zachodzą w sposób niewidoczny, bez żadnego sygnału wskazującego, że nie udało się nawiązać bezpiecznego połączenia.
BIMI (wskaźniki marki służące do identyfikacji wiadomości)
BIMI wyświetla zweryfikowane logo marki w skrzynce odbiorczej adresata obok uwierzytelnionych wiadomości, stanowiąc wizualny dowód autentyczności. Aby funkcja ta działała, Twoja domena musi posiadać polityka DMARC o wartości co najmniej p=quarantine. Logo zwiększa rozpoznawalność marki, pomagając odbiorcom natychmiast zidentyfikować autentyczną wiadomość, co może podnieść wskaźniki otwarć. BIMI jest również celem fałszowania logo , gdy domeny nie są odpowiednio zabezpieczone.
Do wyświetlenia niebieskiego znacznika w Gmailu wymagany jest certyfikat Verified Mark Certificate (VMC), a usługa BIMI hostowana z obsługą VMC ogranicza konieczność ręcznej konfiguracji. Jeśli chcesz skonfigurować tę usługę, zapoznaj się z tym przewodnikiem dotyczącym jak opublikować rekord BIMI przedstawia wszystkie niezbędne kroki.
Jak działa uwierzytelnianie wiadomości e-mail
Uwierzytelnianie przebiega jako sekwencja automatycznych kontroli między serwerem wysyłającym a serwerem odbierającym. Cały proces od początku do końca wygląda następująco.
- Nadawca wysyła wiadomość. Twój serwer pocztowy wysyła wiadomość e-mail w imieniu Twojej domeny.
- Serwer odbierający wysyła zapytanie do systemu DNS. Wyszukuje rekordy DNS domeny wysyłającej w celu znalezienia konfiguracji SPF, DKIM i DMARC.
- Sprawdzenie SPF. Serwer sprawdza, czy adres IP nadawcy znajduje się na liście autoryzowanych adresów w rekordzie SPF domeny. Zgodność oznacza pozytywny wynik.
- Sprawdzenie DKIM. Serwer pobiera publiczny klucz DKIM z serwera DNS i weryfikuje podpis kryptograficzny w nagłówkach wiadomości. Prawidłowy podpis na niezmodyfikowanej treści powoduje pomyślne przejście weryfikacji.
- Sprawdzanie zgodności z DMARC i polityki. DMARC sprawdza, czy domena, która przeszła weryfikację SPF lub DKIM, jest zgodna z widoczną domeną nadawcy. Jeśli nie, stosuje politykę domeny: brak, kwarantanna lub odrzucenie.
- Ostateczna decyzja dotycząca dostarczenia wiadomości. Dostawca dostarcza, poddaje kwarantannie lub odrzuca wiadomość, a następnie wysyła zbiorcze raporty DMARC do właściciela domeny.
Dlaczego uwierzytelnianie wiadomości e-mail ma znaczenie?
Pominięcie uwierzytelniania stwarza realne ryzyko biznesowe w pięciu obszarach, które często się na siebie nakładają. Słabe uwierzytelnianie rzadko powoduje tylko jeden, odosobniony problem.
Chroni reputację Twojej marki
Uwierzytelnianie uniemożliwia oszustom wykorzystywanie Twojej domeny do wysyłania fałszywych wiadomości. Gdy atakujący podszywają się pod Twoją domenę, odbiorcy kojarzą próbę phishingu z Twoją marką, mimo że nie masz z tym nic wspólnego. Zapobieganie takim sytuacjom ma kluczowe znaczenie dla utrzymania zaufania klientów.
Zapobiega phishingowi i spoofingowi
SPF, DKIM i DMARC współdziałają w celu weryfikacji tożsamości nadawcy, zanim wiadomość dotrze do odbiorcy, co znacznie utrudnia podszywanie się pod zaufaną markę. Bez tych kontroli osoby atakujące mogą swobodnie fałszować adresy nadawców i przeprowadzać kampanie typu „business email compromise”. Różnica między phishingu a spoofingu ma tutaj znaczenie, ponieważ uwierzytelnianie przeciwdziała spoofingowi, który sprawia, że phishing wydaje się przekonujący.
Poprawia dostarczalność wiadomości e-mail
Uwierzytelnione wiadomości e-mail rzadziej są oznaczane jako spam przez dostawców takich jak Gmail czy Outlook, dzięki czemu prawidłowe wiadomości trafiają do skrzynki odbiorczej. Wielu dostawców wymaga obecnie DKIM i DMARC jako warunek pomyślnej dostawy, a spełnienie tych standardów zwiększa wskaźniki trafiania do skrzynki odbiorczej.
Spełnia wymagania dotyczące zgodności
Google, Yahoo, Microsoft i Apple wymagają stosowania protokołów SPF, DKIM i DMARC w przypadku domen wysyłających ponad 5 000 wiadomości e-mail dziennie, przy czym Google będzie ściśle egzekwować te wymagania od listopada 2025 r., odrzucając wiadomości niezgodne z tymi standardami.
W branżach podlegających regulacjom, takich jak finanse, opieka zdrowotna, edukacja, handel detaliczny i sektor publiczny, uwierzytelnianie wspiera również szeroko zakrojone programy dotyczące zgodności z przepisami i zarządzania ryzykiem. Wymogi stawiane przez Google, Microsoft, standard PCI DSS, programy zgodne z RODO oraz regionalne przepisy rządowe w coraz większym stopniu traktują protokoły SPF, DKIM i DMARC jako niezbędne mechanizmy kontroli, a nie jedynie jako najlepsze praktyki.
Zapewnia widoczność i kontrolę
W szczególności DMARC dostarcza raportów dotyczących sposobu, w jaki Twoja domena jest wykorzystywana do wysyłania wiadomości e-mail. Raporty te ujawniają nieautoryzowanych nadawców, niepowodzenia w uwierzytelnianiu oraz próby podszywania się – są to dane, na podstawie których podejmujesz działania. Bez uwierzytelniania nie masz wglądu w wydajność ani bezpieczeństwo poczty elektronicznej w całej swojej infrastrukturze wysyłkowej.
Stanowi strategiczną przewagę
Dostawcy usług poczty elektronicznej coraz częściej wynagradzają prawidłowo uwierzytelnionych nadawców. Organizacje, które odpowiednio to realizują, budują większe zaufanie odbiorców, odnotowują mniej problemów z dostarczaniem wiadomości oraz chronią swoją infrastrukturę wysyłkową przed nadużyciami, co daje im przewagę nad konkurentami, którzy tego nie robią.
Jak wdrożyć uwierzytelnianie wiadomości e-mail
Wdrożenie sprowadza się do skonfigurowania rekordów DNS, których serwery odbiorcze używają do weryfikacji każdej wiadomości wysyłanej z Twojej domeny. Wykonaj pięć kroków po kolei, zaczynając od utworzenia pierwszego rekordu TXT, aż do pełnego wdrożenia.
- Przeprowadź audyt swojej infrastruktury wysyłkowej. Zidentyfikuj wszystkie źródła wysyłające wiadomości w imieniu Twojej domeny: główne serwery pocztowe, systemy automatyzacji marketingu, CRM, dział pomocy technicznej, dział rozliczeń oraz wszelkich dostawców usług transakcyjnych. Większość niepowodzeń związanych z uwierzytelnianiem wynika z przeoczenia któregoś z nadawców, więc ten krok decyduje o tym, jak czyste jest wdrożenie.
- Opublikuj swój rekord SPF. Utwórz pojedynczy rekord TXT zawierający listę wszystkich autoryzowanych adresów IP i usług wysyłających. Każda pozycja na liście wlicza się do limitu 10 wyszukiwań, a przekroczenie tego limitu powoduje niepowodzenie weryfikacji SPF dla wszystkich wiadomości.
- Skonfiguruj podpisywanieDKIM. Wygeneruj parę kluczy za pośrednictwem dostawcy usług lub serwera pocztowego. Klucz prywatny pozostaje na serwerze wysyłającym i służy do podpisywania wychodzących wiadomości; klucz publiczny jest umieszczany w systemie DNS jako rekord TXT, dzięki czemu odbiorcy mogą zweryfikować każdy podpis.
- Dodaj swój rekord DMARC. Opublikuj rekord DMARC typu TXT, zaczynając od polityki p=none przeznaczonej wyłącznie do monitorowania, abyś mógł obserwować wyniki przed jej egzekwowaniem. Podstawowy rekord ma postać: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1.
- Przeprowadź testy i sprawdź poprawność. Wyślij wiadomość testową z każdego źródła zidentyfikowanego w kroku pierwszym i sprawdź nagłówek „Authentication-Results” pod kątem wyników weryfikacji SPF, DKIM i DMARC.
Częsty błąd
Wklejanie przykładowego rekordu SPF lub DMARC bezpośrednio do systemu DNS. Powyższe przykłady to szablony, a nie gotowe rekordy do wdrożenia. Wiersz SPF zawierający usługi, z których nie korzystasz, marnuje limity 10 zapytań, a rekord DMARC wskazujący na skrzynkę raportową, której nikt nie posiada, oznacza, że zagregowane dane nigdzie nie trafiają. Przed opublikowaniem dostosuj oba rekordy do własnych nadawców i adresów raportowych.
W przypadku rekordów, których rozmiar przekracza limit wyszukiwania w miarę rozbudowywania się platform SaaS, należy zastosować narzędzie do spłaszczania SPF automatycznie utrzymuje je w dopuszczalnych granicach. Gdy rekordy zostaną opublikowane, należy skorzystać z analizatora domen , aby w ciągu kilku sekund zweryfikować pełną konfigurację SPF, DKIM i DMARC.
| Zadanie | Protokół | Wymagane | Narzędzie |
|---|---|---|---|
| Przeprowadź audyt wszystkich źródeł wysyłania wiadomości e-mail | Wszystkie | Tak | Raporty ręczne lub raporty DMARC |
| Opublikuj rekord SPF typu TXT w systemie DNS | SPF | Tak | Generator SPF lub PowerSPF |
| Skonfiguruj podpis DKIM i opublikuj klucz | DKIM | Tak | Generator DKIM lub usługa DKIM w chmurze |
| Opublikuj rekord DMARC z wartością p=none | DMARC | Tak | Generator DMARC |
| Przejrzyj raporty DMARC i usuń błędy | DMARC | Tak | Pulpit nawigacyjny PowerDMARC |
| Przenieś wiadomości DMARC do kwarantanny, a następnie odrzuć je | DMARC | Zalecane | Kreator egzekwowania |
| Wdrożenie protokołów MTA-STS i TLS-RPT | MTA-STS / TLS-RPT | Zalecane | Hostowana usługa MTA-STS / TLS-RPT |
| Skonfiguruj BIMI za pomocą VMC lub CMC | BIMI | Opcjonalnie | Wsparcie w zakresie PowerBIMI / VMC |
Typowe problemy z uwierzytelnianiem i sposoby ich rozwiązywania
Problemy pojawiają się zazwyczaj w momencie zmiany środowiska wysyłkowego. Nowe narzędzia SaaS, regionalni nadawcy, usługi przekazywania wiadomości oraz zmiany w systemie DNS mają wpływ na protokoły SPF, DKIM i DMARC, a także na bezpieczeństwo transportu. Poniżej przedstawiono najczęstsze scenariusze wraz z rozwiązaniami.
| Niepowodzenie | Jak to naprawić |
|---|---|
| Liczba wyszukiwań DNS przekracza 10 | Wykorzystaj funkcję wyrównywania SPF lub automatyczne zarządzanie, aby nie przekroczyć limitu bez naruszania dotychczasowych rekordów |
| Nadawca zewnętrzny nieujęty w rekordzie SPF | Sprawdzić źródła wysyłania i dodać mechanizm dołączania brakującej usługi |
| Brak selektora DKIM lub jest on nieaktualny | Wymieniaj i monitoruj klucze DKIM; dopasuj selektor podpisu do selektora w DNS |
| Błąd zgodności z DMARC | Należy dopasować domenę „Return-Path” w polu SPF lub domenę podpisującą DKIM do widocznej domeny „From” |
| Przekazane wiadomości e-mail nie przechodzą uwierzytelnienia | Wdrażaj ARC tam, gdzie jest to obsługiwane, aby zachować wyniki podczas przekazywania danych przez pośredników |
| Błędy dostarczania TLS | Wprowadź protokół MTA-STS, aby zapewnić dostarczanie wiadomości w postaci zaszyfrowanej, oraz monitoruj protokół TLS-RPT w celu wykrywania awarii |
| SPF lub DKIM przechodzi pomyślnie, ale DMARC kończy się niepowodzeniem | Uwierzytelniona domena nie pokrywa się z domeną nadawcy; sprawdź tryb dopasowania i domenę podpisującą |
Najlepsze praktyki uwierzytelniania poczty elektronicznej
Opublikowanie tych danych to dopiero pierwszy krok. Utrzymanie wysokiego poziomu uwierzytelniania na dłuższą metę wymaga kilku stałych nawyków.
Zacznij od monitorowania, a następnie egzekwuj
Zacznij od ustawienia p=none, aby gromadzić dane bez wpływu na dostarczanie wiadomości. Przeanalizuj raporty, aby zidentyfikować wszystkich wiarygodnych nadawców, napraw błędy konfiguracji, a następnie, w miarę wzrostu pewności, stopniowo przechodź do ustawień p=quarantine i p=reject.
Należy dbać o to, by dane dotyczące SPF były aktualne i mieściły się w wyznaczonych granicach
Należy aktualizować rekord SPF za każdym razem, gdy dodaje się lub usuwa usługę wysyłkową, ponieważ nieaktualny rekord powoduje odrzucanie prawidłowych wiadomości. W miarę rozbudowywania infrastruktury należy zwracać uwagę na limit 10 zapytań, ponieważ jego przekroczenie powoduje odrzucenie całego sprawdzenie SPF dla każdej wiadomości. Organizacje korzystające z wielu platform SaaS powinny na bieżąco monitorować złożoność rekordów SPF oraz stosować zautomatyzowane zarządzanie lub upraszczanie rekordów, aby zapobiegać błędom w miarę wzrostu liczby nadawców.
Regularnie zmieniaj klucze DKIM
Rotacja kluczy DKIM zmniejsza ryzyko naruszenia bezpieczeństwa kluczy. Zaleca się przeprowadzanie rotacji co 6–12 miesięcy, a także natychmiast w przypadku podejrzenia, że klucz prywatny został ujawniony.
Najczęściej zadawane pytania
Czy potrzebuję SPF, DKIM i DMARC, jeśli korzystam z usług dostawcy poczty elektronicznej?
Tak. Większość dostawców usług e-mailowych (ESP) korzysta z tej samej infrastruktury wysyłkowej dla wielu klientów, więc ich domyślna konfiguracja może nie zapewniać pełnej autoryzacji Twojej domeny. To Ty publikujesz własne rekordy SPF, DKIM i DMARC; dostawca usług e-mailowych pomaga w konfiguracji podpisywania DKIM.
Który protokół powinienem skonfigurować jako pierwszy?
Najpierw SPF, potem DKIM, a na końcu DMARC z parametrem p=none. DMARC działa w oparciu o wyniki SPF lub DKIM, więc opublikowanie go jako pierwszego bez wdrożenia pozostałych dwóch mechanizmów nie daje żadnego punktu odniesienia.
Jaka jest różnica między uwierzytelnianiem a szyfrowaniem?
Uwierzytelnianie pozwala sprawdzić, kto wysłał wiadomość i czy została ona zmieniona. Szyfrowanie chroni treść podczas przesyłania. Protokoły MTA-STS i TLS-RPT zajmują się szyfrowaniem, natomiast protokoły SPF, DKIM i DMARC – weryfikacją tożsamości.
Dlaczego moje przekazane wiadomości e-mail nie przechodzą uwierzytelnienia?
Przekazywanie wiadomości za pośrednictwem list mailingowych lub systemów zgłoszeń może spowodować uszkodzenie oryginalnego podpisu SPF lub DKIM. Technologia ARC zachowuje oryginalne wyniki na każdym etapie przesyłania, dzięki czemu serwer odbiorczy obsługujący ARC może nadal ufać tej wiadomości.
Po jakim czasie uwierzytelnienie zacznie obowiązywać?
Zmiany w systemie DNS są propagowane w ciągu od kilku minut do kilku godzin, w zależności od wartości TTL. Zgromadzenie miarodajnych danych z raportów DMARC ze wszystkich źródeł wysyłających zajmuje od kilku dni do kilku tygodni.
Czy mogę przejść od razu do etapu „p=reject”?
Zdecydowanie odradza się takie postępowanie. Bez okresu monitorowania przy ustawieniu p=none nie można stwierdzić, którzy wiarygodni nadawcy mają problemy z dostarczaniem wiadomości, a pochopne odrzucanie wiadomości może spowodować zablokowanie własnych faktur i wiadomości transakcyjnych.
- Metody uwierzytelniania wiadomości e-mail: w jaki sposób SPF, DKIM i DMARC chronią Twoją domenę – 9 sierpnia 2026 r.
- Czym jest polityka DMARC? Brak, Kwarantanna i Odrzucenie – 27 lipca 2026 r.
- Zgodność z Dmarc: co to jest, dlaczego ma znaczenie i jak ją sprawdzić – 21 lipca 2026 r.




