Podszywanie się pod firmową domenę może prowadzić do wyłudzeń, przejęcia płatności, utraty zaufania klientów i problemów z dostarczaniem prawidłowych wiadomości. Rekordy SPF, DKIM i DMARC pozwalają serwerom odbiorców zweryfikować, czy wiadomość została wysłana z uprawnionego źródła i czy nadawca rzeczywiście może posługiwać się daną domeną.
SPF wskazuje dozwolone źródła wysyłki, DKIM podpisuje wiadomości kryptograficznie, a DMARC sprawdza zgodność domen i określa sposób postępowania z wiadomościami, które nie przejdą weryfikacji. Najlepszą ochronę daje poprawne wdrożenie wszystkich trzech mechanizmów.
Konfiguracja nie polega na skopiowaniu jednego uniwersalnego rekordu. Trzeba najpierw ustalić wszystkie systemy wysyłające pocztę w imieniu domeny: Microsoft 365, Google Workspace, serwer hostingowy, program ERP, CRM, sklep internetowy, newsletter, formularze strony, system księgowy, helpdesk, urządzenia wielofunkcyjne i aplikacje branżowe.
Dlaczego zwykła poczta e-mail wymaga dodatkowego uwierzytelnienia?
Podstawowy protokół SMTP nie gwarantuje sam z siebie, że adres widoczny w polu „Od” rzeczywiście należy do nadawcy. Przestępca może próbować wysłać wiadomość wyglądającą jak korespondencja prezesa, księgowości, kontrahenta albo banku.
Podszywanie się pod domenę
Fałszywa wiadomość może posługiwać się adresem przypominającym prawidłową korespondencję firmy.
Zmiana numeru rachunku
Atakujący próbuje przekonać odbiorcę, że płatność powinna trafić na inne konto bankowe.
Wyłudzenie danych logowania
Link prowadzi do fałszywej strony Microsoft 365, Google, banku albo systemu firmowego.
Problemy z dostarczalnością
Brak uwierzytelnienia może zwiększać ryzyko trafiania prawidłowej poczty do spamu lub jej odrzucania.
SPF, DKIM i DMARC – czym się różnią?
Sprawdza, czy serwer wysyłający wiadomość jest uprawniony do wysyłania poczty dla domeny użytej w adresie koperty SMTP.
Dodaje do wiadomości podpis kryptograficzny. Serwer odbiorcy weryfikuje go przy użyciu klucza publicznego opublikowanego w DNS.
Sprawdza wynik SPF lub DKIM oraz ich zgodność z domeną widoczną w polu „Od”, a następnie stosuje politykę właściciela domeny.
SPF nie zastępuje DKIM ani DMARC. Microsoft wskazuje, że mechanizmy te są współzależnymi elementami ochrony. Pełna konfiguracja ogranicza spoofing znacznie skuteczniej niż pojedynczy rekord SPF.
Jak działa rekord SPF?
SPF jest rekordem TXT publikowanym w DNS domeny. Wskazuje serwery i usługi, które mogą wysyłać pocztę w jej imieniu. System odbiorcy porównuje źródło wiadomości z opublikowaną polityką.
v=spf1 include:spf.protection.outlook.com -all
Powyższy zapis jest przykładem dla domeny wysyłającej pocztę wyłącznie przez Microsoft 365. Nie należy kopiować go bez analizy. Jeżeli firma korzysta również ze sklepu, newslettera, hostingu lub programu ERP, dodatkowe źródła mogą wymagać prawidłowego uwzględnienia.
v=spf1include:ip4: / ip6:~all-allNajczęstsze błędy SPF
Dla jednej domeny lub subdomeny powinien istnieć jeden prawidłowo złożony rekord SPF. Dodanie drugiego, osobnego wpisu nie rozszerza pierwszego — może spowodować błąd permerror.
Sprawdź, czy ktoś może podszywać się pod Twoją domenę
Rawcom może zinwentaryzować źródła wysyłki, sprawdzić DNS, nagłówki wiadomości oraz obecną konfigurację Microsoft 365 lub Google Workspace.
Jak działa DKIM?
DKIM podpisuje wychodzącą wiadomość przy użyciu klucza prywatnego znajdującego się po stronie systemu pocztowego. W DNS publikowany jest odpowiadający mu klucz publiczny. Serwer odbiorcy może dzięki temu sprawdzić podpis i wykryć istotne zmiany wiadomości po jej wysłaniu.
Rekord DKIM jest publikowany pod nazwą zawierającą selektor, na przykład selector1._domainkey. Konkretna nazwa i wartość zależą od dostawcy poczty. W Microsoft 365 zazwyczaj publikuje się wskazane rekordy CNAME, natomiast w Google Workspace administrator generuje klucz i dodaje odpowiedni rekord TXT.
Co może powodować błąd DKIM?
Brak rekordu DNS
Podpisywanie zostało włączone w panelu, ale wymagany rekord nie został opublikowany albo jeszcze się nie rozpropagował.
Nieprawidłowy selektor
System szuka klucza pod inną nazwą niż ta, która została wpisana w DNS.
Wiadomość zmieniona po podpisaniu
Bramka, lista mailingowa lub inny pośrednik może zmodyfikować treść i unieważnić podpis.
Brak podpisu z właściwej domeny
Zewnętrzna aplikacja wysyła wiadomości, ale nie podpisuje ich domeną zgodną z adresem widocznym dla odbiorcy.
Jak działa DMARC?
DMARC wykorzystuje wyniki SPF i DKIM, ale dodaje kluczowy warunek: przynajmniej jeden z tych mechanizmów musi przejść weryfikację z zachowaniem zgodności domeny z adresem widocznym w polu „Od”. To właśnie nazywa się alignmentem, czyli dopasowaniem domen.
v=DMARC1; p=none; rua=mailto:dmarc@twojadomena.pl; pct=100
To przykład polityki obserwacyjnej. Rekord DMARC publikuje się jako TXT pod adresem _dmarc.twojadomena.pl. Adres raportowy powinien istnieć lub być obsługiwany przez właściwą usługę analizującą raporty.
p=nonep=quarantinep=reject
Nie zaczynaj bez analizy od p=reject. Zbyt szybkie zaostrzenie polityki może zablokować prawidłowe wiadomości ze sklepu, CRM, systemu fakturującego, newslettera albo urządzenia wysyłającego skany.
Jak wygląda bezpieczne wdrożenie DMARC?
Inwentaryzacja wysyłki
Tworzymy listę wszystkich systemów, adresów IP i dostawców wysyłających pocztę w imieniu domeny oraz jej subdomen.
Porządkowanie SPF
Łączymy dozwolone źródła w jeden rekord, usuwamy nieaktualne wpisy i kontrolujemy limit zapytań DNS.
Uruchomienie DKIM
Publikujemy rekordy wskazane przez dostawcę i sprawdzamy podpis na rzeczywistych wiadomościach.
DMARC w trybie obserwacji
Wdrażamy p=none, włączamy raportowanie i analizujemy legalne oraz podejrzane źródła wysyłki.
Naprawa alignmentu
Konfigurujemy zewnętrzne systemy tak, aby SPF lub DKIM były zgodne z domeną widoczną w polu „Od”.
Stopniowe zaostrzenie
Po testach przechodzimy do p=quarantine, a następnie — jeżeli raporty to potwierdzają — do p=reject.
Stały monitoring
Kontrolujemy raporty, nowe źródła, zmiany dostawców, wygasające usługi i problemy z dostarczalnością.
SPF, DKIM i DMARC w Microsoft 365
Dla domen wysyłających pocztę przez Exchange Online należy opublikować odpowiedni SPF, przygotować rekordy DKIM wskazane dla konkretnej domeny i włączyć podpisywanie, a następnie wdrożyć DMARC. Microsoft zaleca stopniowe dochodzenie do polityki p=reject po wcześniejszym sprawdzeniu legalnych źródeł.
Microsoft 365 to nie tylko rekordy DNS
Bezpieczeństwo poczty obejmuje również uwierzytelnianie wieloskładnikowe, ochronę kont administratorów, zasady antyphishingowe, kontrolę przekazywania wiadomości, analizę logowań i właściwe licencje zabezpieczeń. Rawcom jest dystrybutorem oprogramowania Microsoft i może pomóc w administracji środowiskiem Microsoft 365.
SPF, DKIM i DMARC w Google Workspace
Google Workspace również wymaga wskazania prawidłowych źródeł w SPF, wygenerowania klucza DKIM w konsoli administratora i opublikowania go w DNS. Po potwierdzeniu, że poczta jest podpisywana, można wdrażać DMARC i analizować raporty.
Jeżeli domena korzysta jednocześnie z Google Workspace i zewnętrznych systemów, rekord SPF musi obejmować wszystkie legalne źródła, a aplikacje powinny — jeśli to możliwe — podpisywać pocztę DKIM zgodnie z domeną nadawcy.
Microsoft 365 lub Google Workspace zgłasza błędy uwierzytelnienia?
Prześlij nazwę domeny, opis używanych systemów wysyłkowych i przykład niedostarczonej wiadomości lub komunikatu zwrotnego. Rawcom sprawdzi konfigurację techniczną.
Jak czytać wynik uwierzytelnienia wiadomości?
W nagłówkach wiadomości można znaleźć sekcję Authentication-Results. Pokazuje ona między innymi wyniki spf, dkim i dmarc. W Microsoft 365 może pojawić się również wynik uwierzytelnienia złożonego compauth.
spf=passdkim=passdmarc=passpermerrordmarc=failCzy poprawne SPF, DKIM i DMARC gwarantują dostarczenie wiadomości?
Nie. Uwierzytelnienie jest bardzo ważnym elementem, ale filtry antyspamowe analizują również reputację domeny i adresu IP, historię wysyłki, treść, linki, załączniki, reakcje odbiorców i skalę kampanii. Wiadomość może przejść SPF, DKIM i DMARC, a mimo to trafić do spamu.
Problemy z dostarczalnością mogą wynikać również z wysyłania dużej liczby wiadomości bez rozgrzewania domeny, nieaktualnych list odbiorców, wysokiego odsetka zwrotów, zainfekowanego konta albo używania tej samej domeny do poczty pracowników i ryzykownych kampanii marketingowych.
SPF, DKIM i DMARC nie zastępują ochrony kont
Mechanizmy uwierzytelnienia domeny ograniczają podszywanie się, ale nie chronią przed wysyłką z prawidłowego konta, które zostało przejęte. Dlatego potrzebne są dodatkowe zabezpieczenia.
MFA
Uwierzytelnianie wieloskładnikowe utrudnia wykorzystanie samego skradzionego hasła.
Ochrona antyphishingowa
Filtrowanie wiadomości, linków i załączników pomaga wykrywać próby oszustwa docierające do pracowników.
Ochrona urządzeń
Komputery powinny być aktualne, monitorowane i zabezpieczone przed złośliwym oprogramowaniem.
Procedury płatności
Zmiana rachunku bankowego powinna być potwierdzana innym kanałem niż wiadomość e-mail.
Ochrona stacji roboczych ESET
Rawcom jest oficjalnym partnerem ESET w sieci DAGMA Bezpieczeństwo IT. Ochrona urządzeń uzupełnia zabezpieczenia poczty, ale nie zastępuje prawidłowej konfiguracji Microsoft 365, Google Workspace ani rekordów SPF, DKIM i DMARC.
Najczęstsze błędy przy zabezpieczaniu poczty
Najczęstsze pytania
Czy rekord SPF chroni domenę przed podszywaniem się?
SPF pomaga zweryfikować źródło wysyłki, ale sam nie zapewnia pełnej ochrony adresu widocznego w polu „Od”. Należy wdrożyć również DKIM i DMARC.
Czy można mieć dwa rekordy SPF?
Nie należy publikować kilku rekordów SPF dla tej samej domeny. Dozwolone źródła trzeba połączyć w jednym poprawnym rekordzie, z uwzględnieniem limitu zapytań DNS.
Czy od razu ustawić DMARC na p=reject?
Zwykle nie. Najpierw należy zinwentaryzować źródła, skonfigurować SPF i DKIM, uruchomić raporty przy p=none oraz usunąć błędy. Politykę należy zaostrzać stopniowo.
Czy DMARC może zablokować prawidłową pocztę?
Tak, jeżeli legalny system wysyłający nie został poprawnie skonfigurowany albo jego domena nie spełnia alignmentu. Dlatego przed p=quarantine lub p=reject potrzebne są testy i raporty.
Czy konfiguracja działa od razu po zmianie DNS?
Zmiany DNS wymagają propagacji. Czas zależy od wartości TTL, operatora DNS i pamięci podręcznej serwerów. Po zmianie należy sprawdzić publiczne rekordy oraz nagłówki testowych wiadomości.
Czy trzeba zabezpieczać domenę, która nie wysyła poczty?
Taką domenę lub subdomenę również warto objąć restrykcyjną polityką, aby jasno wskazać, że nie jest legalnym źródłem wiadomości. Konfigurację trzeba dobrać do pozostałych usług działających w domenie.
Czy SPF, DKIM i DMARC zatrzymają phishing przychodzący?
Pomagają systemom pocztowym oceniać nadawcę, ale nie zatrzymają wszystkich oszustw, zwłaszcza wysyłanych z podobnych domen lub przejętych kont. Potrzebne są filtry, MFA, ochrona urządzeń i szkolenie pracowników.
Czy Rawcom może skonfigurować rekordy za firmę?
Tak, jeżeli firma zapewni dostęp administracyjny do DNS i systemu pocztowego oraz przekaże informacje o wszystkich źródłach wysyłki. Zakres może obejmować audyt, wdrożenie, testy i monitoring.
Powiązane poradniki i usługi
Zabezpiecz pocztę i reputację firmowej domeny
Podaj nazwę domeny, używany system pocztowy oraz listę programów wysyłających wiadomości. Rawcom sprawdzi zakres prac potrzebnych do wdrożenia SPF, DKIM i DMARC.