SPF, DKIM i DMARC można wdrożyć bez zatrzymywania legalnej poczty, ale nie przez jedną zmianę DNS wykonaną wieczorem. Bezpieczne wdrożenie jest procesem: ustala właścicieli, odkrywa wszystkie źródła wysyłki, naprawia uwierzytelnianie, obserwuje raporty i dopiero potem stopniowo egzekwuje politykę. Ten przewodnik rozwija podstawy z artykułu SPF, DKIM i DMARC — jak chronić nazwę firmy w poczcie.
DMARC ogranicza bezpośrednie podszywanie się pod kontrolowaną domenę w widocznym polu „Od”. Nie potwierdza prawdziwości treści i nie eliminuje phishingu. Wiadomość z podobnej domeny, z przejętej prawdziwej skrzynki albo z legalnej usługi nadużytej przez przestępcę może przejść wszystkie kontrole.
1. Ustal warunki wstępne i odpowiedzialność
Przed zmianą rekordów wyznacz właściciela biznesowego domeny, osobę techniczną odpowiedzialną za DNS i pocztę oraz właściciela każdego systemu wysyłającego. Ustal, kto analizuje raporty, zatwierdza kolejny etap i zarządza wycofaniem. Dostęp do rejestratora, DNS, bramy i paneli dostawców chroń MFA oraz zapewnij co najmniej dwóm upoważnionym osobom.
Potrzebne są:
- lista firmowych domen i subdomen oraz kontrola nad publicznym DNS;
- skrzynka lub usługa odbierająca raporty zbiorcze DMARC;
- okno obserwacji obejmujące pełny cykl biznesowy;
- procedura zmiany, testu, zatwierdzenia i wycofania;
- kontakty do właścicieli i wsparcia zewnętrznych platform.
Zapisz istniejące rekordy SPF, selektory DKIM, DMARC, wolumeny i problemy z dostarczaniem. Obniżenie TTL ułatwia planowaną zmianę, lecz nie gwarantuje natychmiastowego odświeżenia pamięci podręcznych.
2. Zinwentaryzuj wszystkich nadawców
Nie opieraj inwentaryzacji wyłącznie na ustawieniach głównego Microsoft 365 lub Google Workspace. Domena może być używana przez CRM, newsletter, fakturowanie, HR, helpdesk, sklep, formularz WWW, skaner, monitoring, aplikację chmurową i serwer dostawcy. Uwzględnij wysyłki okresowe: faktury, rozliczenia, kampanie, reset haseł i alerty.
Dla każdego źródła zapisz:
- właścicieli, widoczną domenę
Fromi envelope-from/MAIL FROM; - domenę i selektor DKIM;
- dostawcę, źródłowe IP i przybliżony wolumen;
- środowiska produkcyjne, testowe i zapasowe;
- odbiorców testowych oraz sposób wycofania źródła.
Źródła odkrywaj z konfiguracji, logów bramy, nagłówków prawdziwych wiadomości, umów z dostawcami, rozmów z działami oraz raportów DMARC. Raport ujawniający nieznany adres IP jest początkiem dochodzenia, nie automatycznym dowodem ataku: może to być zapomniana legalna usługa, infrastruktura współdzielona albo rzeczywiste podszycie.
3. Uporządkuj SPF i techniczny return-path
SPF jest sprawdzany dla domeny użytej w transakcji SMTP jako MAIL FROM, widocznej później zwykle w nagłówku Return-Path; przy pustym MAIL FROM, na przykład w części komunikatów o niedostarczeniu, odbiorca może sprawdzać domenę HELO/EHLO. To nie jest automatycznie domena widocznego nagłówka From. Dlatego samo „SPF pass” nie wystarcza do DMARC — domena uwierzytelniona przez SPF musi jeszcze być wyrównana z domeną From.
Jedna nazwa DNS powinna mieć jeden rekord SPF typu TXT zaczynający się od v=spf1. Mechanizmy ip4, ip6, a, mx, include, exists i redirect mają różne skutki. Nie kopiuj rekordu dostawcy bez sprawdzenia, co autoryzuje; include może wciągać zmienne zbiory źródeł.
SPF ogranicza do dziesięciu liczbę mechanizmów i modyfikatorów powodujących zapytania DNS podczas jednej oceny. Dotyczy to między innymi include, a, mx, exists i redirect, także przez zagnieżdżenia; nie jest to liczba wyrazów w rekordzie ani wszystkich pakietów DNS. Przekroczenie może dać permerror. ip4 i ip6 same nie zużywają limitu, ale ręczne „spłaszczanie” dynamicznych zakresów wymaga śledzenia zmian dostawcy.
Najlepiej, aby dostawca pozwalał użyć kontrolowanej przez firmę, wyrównanej subdomeny return-path. Usuń nieużywane źródła, unikaj szerokiego +all, dokumentuj każdy include i testuj rekord przed publikacją. SPF jest zależny od ścieżki: zwykłe przekazanie wiadomości często zmienia serwer wysyłający i może zepsuć SPF, mimo że pierwotna wiadomość była legalna.
4. Włącz DKIM i zarządzaj cyklem kluczy
DKIM podpisuje wybrane nagłówki i treść. Domena podpisująca znajduje się w parametrze d=, a selektor w s=; klucz publiczny jest publikowany pod nazwą selektor._domainkey.domena. Dla DMARC liczy się nie sama poprawność podpisu, lecz również wyrównanie domeny d= z widoczną domeną From.
Każdy istotny dostawca powinien podpisywać domeną klienta, jeśli to obsługuje. Preferuj współczesne klucze i długości wspierane przez dostawcę i odbiorców; klucz prywatny pozostaje w systemie, a DNS zawiera publiczny. Oddziel selektory według dostawcy lub środowiska.
Cykl życia obejmuje wygenerowanie, włączenie, potwierdzenie, rotację, unieważnienie po incydencie i opóźnione usunięcie starego klucza. Rotuj dwoma selektorami: opublikuj nowy klucz, włącz i sprawdź podpisy, odczekaj uzgodniony okres, potem usuń stary rekord. Rejestruj właściciela, dostawcę, daty i algorytm; nie zakładaj, że dostawca rotuje za klienta.
5. Zrozum wyrównanie i warunek DMARC
DMARC ocenia domenę w widocznym nagłówku From. Wiadomość przechodzi DMARC, gdy co najmniej jedna ścieżka spełnia oba warunki:
- SPF uwierzytelnia domenę i ta domena jest wyrównana z
From; lub - DKIM uwierzytelnia podpis i domena
d=jest wyrównana zFrom.
SPF i DKIM nie muszą przejść jednocześnie. Z drugiej strony, oba mogą technicznie przejść, lecz DMARC zawiedzie, jeśli żadna uwierzytelniona domena nie jest wyrównana. Wyrównanie domyślnie jest relaksowane: domeny mogą współdzielić tę samą domenę organizacyjną. Tryb ścisły wymaga dokładniejszej zgodności i powinien być wybierany tylko ze świadomym uzasadnieniem.
6. Zacznij od p=none i raportów zbiorczych
Opublikuj rekord pod _dmarc.domena z v=DMARC1, p=none i kontrolowanym adresem rua. p=none prosi odbiorców o raportowanie bez żądania kwarantanny lub odrzucenia; nie stanowi ochrony egzekwującej. Adres raportowy może otrzymywać duże załączniki XML, więc użyj dedykowanej, monitorowanej skrzynki lub procesora, określ retencję i ogranicz dostęp. Raportowanie do innej domeny może wymagać dodatkowej autoryzacji DNS po stronie odbiorcy raportów.
Raporty zbiorcze pokazują liczby wiadomości pogrupowane przede wszystkim według źródłowego IP i wyniku polityki. Zawierają też domenę From, wyniki i domeny SPF/DKIM, dyspozycję oraz czasem lokalne odstępstwo odbiorcy. Nie są kopią wiadomości, pełnym logiem ani gwarancją raportowania przez każdego odbiorcę.
Normalizuj dane i obserwuj trendy. Dla każdego istotnego wiersza ustal właściciela, oczekiwany wolumen, wynik SPF, podpis DKIM, wyrównanie i decyzję odbiorcy. Pozostań na p=none przez pełny cykl obejmujący rzadkie wysyłki. Sam wysoki procent „pass” nie wystarcza, jeśli niewielka grupa błędów zawiera faktury, reset haseł lub pocztę zarządu.
7. Napraw legalne źródła i dostawców
Najpierw popraw konfigurację u źródła. Ustaw wyrównany return-path, aktywuj DKIM w domenie firmy, usuń stare include i skoryguj widoczny From. Nie autoryzuj całej szerokiej infrastruktury tylko po to, by ukryć jeden błąd. Jeżeli dostawca nie wspiera wyrównania ani DKIM klienta, rozważ dedykowaną subdomenę, zmianę sposobu wysyłki lub dostawcy. Wymagania dotyczące domen, kluczy, logów, powiadamiania o zmianach i zakończenia usługi powinny znaleźć się w umowie.
Przekazywanie może przerwać SPF, bo pośrednik wysyła z innego IP. DKIM częściej przetrwa, ale zmiana treści lub podpisanych nagłówków przez listę czy bramę może unieważnić podpis. ARC może przekazać wcześniejsze wyniki, lecz zależy od zaufania odbiorcy i nie zastępuje DMARC. Testuj rzeczywiste ścieżki; nie twórz globalnego wyjątku.
8. Egzekwuj politykę etapami
Po naprawieniu źródeł przejdź do p=quarantine, początkowo z ograniczonym pct, na przykład 10 lub 25. pct jest żądanym odsetkiem wiadomości niespełniających DMARC, do których odbiorca ma zastosować politykę; nie jest precyzyjnym mechanizmem wdrożeniowym ani gwarancją zachowania każdego odbiorcy. Zwiększaj udział dopiero po analizie raportów i zgłoszeń: 25, 50, 100 procent. Następnie analogicznie przejdź do p=reject.
Polityka domeny organizacyjnej może objąć subdomeny przez sp. Subdomeny używane przez niezależne platformy warto wydzielić i przygotować osobno; nieużywane mogą otrzymać restrykcyjną politykę wcześniej, po potwierdzeniu, że naprawdę nie wysyłają. Nie traktuj sp ani pct jako substytutu inwentaryzacji. Każdy etap powinien mieć datę, kryteria wejścia i wyjścia, właściciela, zatwierdzenie oraz okres obserwacji.
9. Testuj, kontroluj zmianę i przygotuj rollback
Przed każdym etapem wykonaj kontrolowane wysyłki z każdego źródła do kilku niezależnych odbiorców. Sprawdź pełne nagłówki: Authentication-Results, Received-SPF, DKIM-Signature, Return-Path i widoczny From. Przetestuj odpowiedzi, przekazywanie, wiadomości automatyczne, puste MAIL FROM, duże kampanie oraz środowisko zapasowe. Potwierdź nie tylko dostarczenie, ale też właściwe wyrównanie.
Zapis zmiany powinien zawierać rekord przed i po, TTL, zatwierdzenie, testy, kanał zgłoszeń i warunek wycofania. Rollback może oznaczać obniżenie pct, powrót do quarantine lub none, przywrócenie selektora albo zatrzymanie wadliwego nadawcy. Nie usuwaj poprawnych zabezpieczeń z powodu jednego źródła; pamięci DNS opóźniają wdrożenie i wycofanie.
10. Monitoruj po osiągnięciu reject
p=reject nie kończy projektu. Przeglądaj raporty, nowe źródła, wolumeny, błędy SPF, selektory i daty rotacji. Oceniaj pocztę przy zakupie i wycofywaniu usług. Alarmuj o nowym dużym źródle, utracie wyrównania, spadku podpisów i zmianie DNS. Okresowo testuj krytyczne ścieżki oraz dostęp do kont.
DMARC nie chroni domen podobnych, których firma nie kontroluje, i nie zatrzymuje napastnika korzystającego z przejętej prawdziwej skrzynki. Dlatego potrzebne są MFA, ochrona kont, monitoring logowań, szkolenia i bezpieczny proces płatności. Zmianę numeru rachunku bankowego lub pilny przelew potwierdzaj drugim kanałem, używając wcześniej znanego numeru i zasady dwóch osób; pomaga w tym karta weryfikacji zmiany numeru rachunku bankowego.
Jeżeli inwentaryzacja, zależności DNS albo odpowiedzialność nie są jasne, zakres można uporządkować w ramach oceny bezpieczeństwa, a utrzymanie DNS i platform pocztowych w ramach administracji systemami. Szersze zabezpieczenia kont, procesów i reakcji na incydenty obejmuje usługa cybersecurity.