DMARC ustawiaj etapami — natychmiastowe „reject” może blokować dobrą pocztę

|Autor: Redakcja QUASA|5 min czytania| 2
DMARC ustawiaj etapami — natychmiastowe „reject” może blokować dobrą pocztę

Aby ograniczyć podszywanie się pod firmową domenę bez odrzucania legalnej poczty, spisz wszystkie źródła wysyłki, skonfiguruj dla nich SPF i DKIM, a DMARC uruchom z polityką p=none i adresem do raportów. Po usunięciu błędów przejdź przez p=quarantine do p=reject. Instrukcja DMARC Microsoft zaleca taką kolejność, ponieważ odbiorcy mogą odrzucać prawidłowe wiadomości, które przypadkowo nie przechodzą kontroli.

Najważniejsze jest porównanie domeny w widocznym dla odbiorcy polu „Od:” z domeną uwierzytelnioną przez SPF lub DKIM. Sam wynik spf=pass albo dkim=pass nie zapewnia przejścia DMARC: co najmniej jedna z tych metod musi również wykazać zgodność domen. Dlatego przed zaostrzeniem polityki trzeba sprawdzić zarówno wiadomości pracowników, jak i wysyłkę przez zewnętrzne usługi.

Ustal, kto wysyła pocztę z domeny

Do spisu wpisz skrzynki pracowników, formularze na stronie, system fakturowy, CRM, sklep, platformę newsletterową i automatyczne powiadomienia. Przy każdym źródle zanotuj domenę widoczną w polu „Od:”, domenę technicznego adresu MAIL FROM oraz domenę podpisu DKIM, jeśli usługa go stosuje. Uwzględnij też używane subdomeny: osobna domena nadawcza wymaga osobnej kontroli konfiguracji.

Sprawdź przekazywanie wiadomości i listy mailingowe. Przekazanie może sprawić, że SPF przestanie odpowiadać serwerowi dostarczającemu wiadomość, a zmiana jej treści może unieważnić podpis DKIM. Te ścieżki łatwo pominąć, gdy testuje się wyłącznie pocztę wysyłaną bezpośrednio ze skrzynki pracownika.

Połącz uprawnionych nadawców w jednym rekordzie SPF

SPF jest rekordem TXT w DNS domeny używanej jako MAIL FROM. Instrukcja SPF Google Workspace podaje dla wysyłki wyłącznie przez Google wartość „v=spf1 include:_spf.google.com ~all”, a dla wspólnej wysyłki przez Google Workspace i Microsoft 365 — „v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all”. Drugi przykład ma sens tylko wtedy, gdy obie usługi rzeczywiście wysyłają pocztę dla tej samej domeny.

Nie dodawaj kolejnego rekordu SPF za każdym razem, gdy firma uruchamia nową usługę. Dla danej nazwy domenowej połącz uprawnione źródła w jednym rekordzie zaczynającym się od v=spf1; wiele takich rekordów powoduje błąd oceny SPF. Przed dopisaniem następnego mechanizmu sprawdź również limit odwołań DNS, ponieważ instrukcje include mogą prowadzić do dalszych odwołań i wynikowego błędu permerror.

Po zapisaniu zmiany odczytaj publiczny rekord TXT i wyślij próbkę z każdego źródła ze spisu. Wynik SPF zależy od rzeczywistego serwera wysyłającego oraz domeny MAIL FROM, więc poprawnie wyglądający rekord DNS nie zastępuje testu wiadomości odebranej przez inną skrzynkę.

Włącz DKIM dla domeny widocznej w polu „Od:”

DKIM dodaje do wiadomości podpis, którego klucz publiczny odbiorca znajduje w DNS. W Google Workspace wygeneruj klucz dla właściwej domeny, opublikuj wskazany rekord TXT i uruchom podpisywanie. W Microsoft 365 dodaj rekordy DNS wskazane dla własnej domeny i włącz jej podpisywanie; dla zewnętrznej platformy sprawdź osobno możliwość użycia firmowej domeny w podpisie.

Wskazówki Gmaila dla nadawców wymagają klucza DKIM o długości co najmniej 1024 bitów przy wysyłce na osobiste konta Gmail i zalecają 2048 bitów, jeśli dostawca domeny na to pozwala. Długość klucza nie rozwiązuje jednak problemu zgodności domen: przy wiadomości z firmowym adresem „Od:” podpis z domeną należącą wyłącznie do dostawcy może przejść kontrolę DKIM, lecz nie pomóc w przejściu DMARC.

W odebranej próbce znajdź nagłówek Authentication-Results. Porównaj dkim=pass i domenę header.d z domeną w polu „Od:”; analogicznie zestaw spf=pass i smtp.mailfrom z tym samym polem. Domyślny łagodny tryb zgodności dopuszcza odpowiednie subdomeny tej samej domeny organizacyjnej. Jeśli zarówno MAIL FROM, jak i podpis DKIM należą do obcej domeny, popraw ustawienia u dostawcy wysyłki.

Użyj raportów DMARC przed zmianą polityki

Warunkowy przykład dla domeny firma.example to rekord TXT o nazwie _dmarc.firma.example i wartości „v=DMARC1; p=none; rua=mailto:[email protected]”. W rzeczywistej konfiguracji zastąp przykładową domenę własną i upewnij się, że skrzynka raportowa odbiera pocztę. Polityka p=none pozwala obserwować wyniki DMARC bez żądania kwarantanny lub odrzucenia z powodu tej polityki; inne filtry odbiorcy nadal mogą wpływać na dostarczenie wiadomości.

Raporty zbiorcze pokazują źródłowe adresy IP, liczbę wiadomości, wyniki uwierzytelniania oraz ocenę zgodności domen. Zestaw je ze spisem nadawców, zanim uznasz nieznany adres IP za próbę podszycia się. Szczególnej uwagi wymaga znana usługa, dla której SPF lub DKIM przechodzi, ale odpowiednia zgodność domen nie przechodzi: rozwiązaniem może być ustawienie firmowej domeny MAIL FROM albo podpisywanie DKIM własną domeną.

Po poprawieniu legalnych źródeł ustaw p=quarantine i obserwuj raporty oraz zgłoszenia o wiadomościach kierowanych do spamu lub kwarantanny. Parametr pct może stopniowo zwiększać udział wiadomości niespełniających DMARC, wobec których odbiorca ma stosować zaostrzoną politykę. Do p=reject przejdź po sprawdzeniu także rzadszych ścieżek wysyłki; zachowaj raportowanie, bo nowa usługa lub zmiana konfiguracji nadawcy może później ujawnić błąd.

Sprawdź wysyłkę w Google Workspace i Microsoft 365

Wyślij do niezależnej skrzynki testowej zwykłą wiadomość pracownika, wiadomość automatyczną i próbkę z każdej zewnętrznej platformy używającej firmowego adresu „Od:”. Osobno przetestuj przekazanie wiadomości. Status „wysłano” w panelu usługi nie pokazuje, jak serwer odbiorcy ocenił SPF, DKIM i DMARC.

  1. Odczytaj publiczne rekordy DNS dla każdej domeny nadawczej: SPF, rekordy potrzebne do DKIM oraz rekord DMARC pod _dmarc.
  2. W nagłówkach odebranych próbek sprawdź spf, dkim i dmarc, a także domeny smtp.mailfrom, header.d oraz adresu „Od:”. Zapisz wyniki osobno dla każdego legalnego źródła.
  3. Porównaj próbki z raportami rua. Jeśli znany nadawca nie przechodzi DMARC, popraw jego MAIL FROM lub podpis DKIM i ponów test.
  4. Po zmianie polityki sprawdź dostarczenie próbek i zgłoszenia użytkowników. Legalną ścieżkę, która nadal zawodzi, napraw przed objęciem jej p=reject.

Przeczytaj także:

Udostępnij:

Zapisz się do naszego newslettera

Otrzymuj najnowsze wiadomości o Web3, AI i kryptowalutach prosto na swoją skrzynkę.

0