7 zewnętrznych nadawców, którzy często naruszają zasady DMARC (i jak zweryfikować każdego z nich)

Większość organizacji wysyła wiadomości e-mail z znacznie większej liczby systemów niż tylko z własnego serwera pocztowego. Platformy marketingowe, systemy CRM, systemy obsługi klienta, narzędzia do rozliczeń oraz coraz większa liczba asystentów opartych na sztucznej inteligencji – wszystkie one wysyłają wiadomości, w których w polu „Od” widnieje nazwa Twojej domeny. Każdy z nich jest zewnętrznym nadawcą i w każdym z nich może dojść do nieprawidłowego działania mechanizmów SPF, DKIM i DMARC, a nikt tego nawet nie zauważy.

Błędy mają teraz większe znaczenie. Serwisy Gmail, Yahoo i Outlook.com wymagają od nadawców wysyłających ponad 5 000 wiadomości dziennie uwierzytelnienia za pomocą protokołów SPF, DKIM i DMARC oraz dostosowania ich do domeny nadawcy; w przeciwnym razie mogą one od razu odrzucać masowe wiadomości niezgodne z tymi wymogami. Poniżej tego progu wiadomość, która nie przejdzie weryfikacji DMARC, z większym prawdopodobieństwem trafi do folderu spam, a po przejściu na politykę odrzucania w ogóle nie dotrze do adresata.

W niniejszym przewodniku omówiono siedem kategorii nadawców zewnętrznych, wyjaśniono, w jaki sposób każdy z nich zazwyczaj narusza zasady DMARC, oraz przedstawiono kroki niezbędne do ich uwierzytelnienia. Na zakończenie zamieszczono przykładowe wpisy DNS, metodę weryfikacji oraz plan wdrożenia.

Dlaczego nadawcy zewnętrzni naruszają zasady DMARC

DMARC uznaje się za pozytywny, gdy co najmniej jeden z mechanizmów – SPF lub DKIM – przejdzie pomyślnie weryfikację i jest zgodny z domeną widoczną w polu „Od”. Właśnie ta zgodność jest często pomijana.

• Sprawdzanie zgodności SPF polega na porównaniu domeny w ścieżce zwrotnej, zwanej również nadawcą koperty lub adresem zwrotnym, z domeną „Od”. Dostawcy zazwyczaj korzystają z własnej domeny zwrotnej, więc test SPF kończy się dla nich pomyślnie, ale nie jest zgodny z Twoimi ustawieniami.
• Sprawdzanie zgodności DKIM polega na porównaniu domeny podpisującej w podpisie DKIM (wartość d=) z domeną nadawcy. Dostawcy zazwyczaj domyślnie podpisują wiadomości przy użyciu własnej domeny, więc DKIM jest poprawny, ale nie jest zgodny.
• Błędy konfiguracyjne powodują nieprawidłowe działanie pozostałych elementów. Do najczęstszych należą: ponad 10 zapytań DNS w SPF, więcej niż jeden rekord SPF w domenie, brakujące rekordy DKIM oraz rekordy pozostałe po dostawcach, z których usług już nie korzystasz.

W trybie „luźnego dopasowania” (ustawienie domyślne) subdomena jest dopasowywana do nadrzędnej domeny organizacyjnej. Tryb „ścisłego dopasowania” wymaga dokładnego dopasowania. Ponieważ podpisy DKIM zazwyczaj pozostają nienaruszone podczas przekazywania wiadomości, a podpisy SPF często ulegają utracie, większość zespołów dąży do zapewnienia zgodności DKIM w przypadku każdego zewnętrznego nadawcy.

Siedmiu nadawców w skrócie

1. Programy do sporządzania notatek z posiedzeń oparte na sztucznej inteligencji oraz asystenci spotkań

Asystenci ds. spotkań wysyłają podsumowania, zadania do wykonania, projekty dokumentów do dalszych działań oraz udostępniają linki – często osobom spoza firmy. Niezależnie od tego, czy Twój zespół korzysta z Fathom, czy rozważa alternatyw dla Fathom, zapytaj dostawcę, w jaki sposób uwierzytelniane są jego wiadomości e-mail, zanim podłączysz skrzynkę pocztową lub włączysz wysyłanie z Twojej domeny.

Wiele z tych narzędzi wysyła wiadomości z własnej domeny, a jako nazwę wyświetlaną podaje Twoje imię i nazwisko. Nie ma to wpływu na wyniki DMARC, ponieważ domena w polu „Od” należy do dostawcy. Problemy zaczynają się w przypadku funkcji, które umieszczają Twoją domenę w polu „Od”, a wiadomości są wysyłane z serwerów dostawcy – na przykład w przypadku wiadomości uzupełniających, które sprawiają wrażenie, jakby pochodziły od Ciebie. Wiadomości te zawierają ścieżkę zwrotną dostawcy oraz podpis DKIM, więc testy SPF i DKIM mogą zakończyć się powodzeniem, mimo że nie zachowują zgodności z Twoją domeną. Trzecim przypadkiem są narzędzia wysyłające wiadomości za pośrednictwem Twojej własnej skrzynki pocztowej Google lub Microsoft. Wiadomości te są podpisywane i dostarczane przez Twojego dostawcę poczty, więc są zgodne, o ile podpis DKIM jest tam włączony dla Twojej domeny.

Pytania, które należy zadać sprzedawcy:

• Jaka domena pojawia się w polu „Od” w podsumowaniach, zaproszeniach i przypomnieniach?
• Czy któraś z funkcji wysyła wiadomości e-mail z serwerów dostawcy, używając mojej domeny w polu „Od”?
• Jeśli tak, to czy mogę uwierzytelnić się za pomocą niestandardowego podpisu DKIM i niestandardowej ścieżki zwrotnej w subdomenie?
• Czy można ograniczyć lub wyłączyć wysyłanie wiadomości e-mail do uczestników zewnętrznych?
• Jeśli narzędzie wysyła wiadomości przez moją skrzynkę pocztową, o jakie uprawnienia prosi?

Jak to zweryfikować:

• Jeśli domena nadawcy należy do dostawcy, nie trzeba konfigurować niczego w ramach DMARC. Skup się na tym, kto otrzymuje te wiadomości e-mail.
• Jeśli nadawca wysyła wiadomości z Twojej domeny, dodaj rekordy DKIM i return-path zgodnie z jego dokumentacją, najlepiej w dedykowanej subdomenie.
• Jeśli narzędzie wysyła wiadomości za pośrednictwem Twojej skrzynki pocztowej, upewnij się, że w usłudze Google Workspace lub Microsoft 365 włączono podpisywanie DKIM dla Twojej domeny niestandardowej.
• Przed wdrożeniem należy wysłać rzeczywiste podsumowanie na zewnętrzną skrzynkę pocztową i zapoznać się z nagłówkami uwierzytelniającymi.

2. Platformy marketingowe i platformy do obsługi poczty elektronicznej

Platformy marketingowe generują największą liczbę wiadomości wysyłanych przez podmioty zewnętrzne, co sprawia, że są one najczęstszym źródłem problemów związanych z DMARC. Domyślnie wiele z nich podpisuje wiadomości własnym kluczem DKIM dostawcy i wykorzystuje domenę zwrotną dostawcy jako ścieżkę zwrotną. W rezultacie SPF i DKIM są weryfikowane poprawnie dla domeny dostawcy, ale żadna z tych informacji nie pokrywa się z domeną podaną w polu „Od”, co powoduje niepowodzenie weryfikacji DMARC.

Wielkość wysyłek podnosi poprzeczkę. Serwisy Gmail, Yahoo i Outlook.com wymagają od nadawców wysyłających ponad 5 000 wiadomości dziennie uwierzytelnienia za pomocą protokołów SPF, DKIM i DMARC oraz zgodności z domeną nadawcy, a wiadomości marketingowe muszą ponadto zawierać opcję rezygnacji z subskrypcji jednym kliknięciem i charakteryzować się niskim wskaźnikiem skarg dotyczących spamu. Masowe wiadomości niezgodne z tymi wymogami mogą zostać od razu odrzucone.

Jak to zweryfikować:

• Wysyłaj wiadomości z dedykowanej subdomeny, takiej jak news.example.com, aby reputacja marketingowa i rekordy DNS były oddzielone od poczty firmowej.
• Przeprowadź uwierzytelnienie domeny na platformie. Zazwyczaj oznacza to dodanie rekordów DKIM, często typu CNAME, tak aby wiadomości były podpisane Twoją domeną, a także niestandardową domeną ścieżki zwrotnej, jeśli jest to możliwe.
• Opublikuj rekord SPF tam, gdzie jest to konieczne. Jeśli ścieżka zwrotna (return-path) jest niestandardową subdomeną, rekord SPF znajduje się w tej subdomenie, co pozwala zachować zwięzłość rekordu głównego.
• Należy skonfigurować politykę DMARC dla subdomeny – albo poprzez dodanie parametru `sp=` w rekordzie nadrzędnym, albo poprzez utworzenie osobnego rekordu – a następnie zapoznać się z raportami zbiorczymi.
• Dodaj nagłówki umożliwiające rezygnację z subskrypcji jednym kliknięciem i obserwuj wskaźniki skarg.

3. Platformy CRM i platformy wspierające działania sprzedażowe

Narzędzia sprzedażowe zazwyczaj wysyłają wiadomości na dwa sposoby. Indywidualne wiadomości e-mail wysyłane za pośrednictwem połączonej skrzynki pocztowej Google lub Microsoft są uwierzytelniane przez dostawcę poczty. Sekwencje masowe oraz opcje „wysyłania za pośrednictwem platformy” korzystają z serwerów należących do samej platformy i wymagają konfiguracji. Częstym źródłem problemów jest sytuacja, w której platforma wysyła wiadomości z osobistych adresów użytkowników w Twojej domenie bez skonfigurowania DKIM lub ścieżki zwrotnej.

Narzędzia te powodują również kumulację wpisów SPF. Każdy wpis wiąże się z wyszukiwaniem w systemie DNS, a standard SPF zezwala na maksymalnie 10 takich operacji na jedną ocenę (RFC 7208). Przekroczenie tego limitu powoduje, że odbiorcy traktują SPF jako błąd stały, co skutkuje niepowodzeniem weryfikacji.

Jak to zweryfikować:

• Wykorzystaj funkcję wysyłania wiadomości powiązaną ze skrzynką pocztową do indywidualnych działań promocyjnych.
• W przypadku wiadomości wysyłanych przez platformę należy uwierzytelnić dedykowaną subdomenę za pomocą niestandardowego podpisu DKIM i ścieżki zwrotnej, a korespondencję marketingową prowadzić w domenie lub subdomenie odrębnej od firmowej poczty elektronicznej.
• Sprawdź, którzy użytkownicy i które platformy mają uprawnienia do wysyłania wiadomości z Twojej domeny.
• Regularnie sprawdzaj liczbę zapytań do serwera SPF. Połącz lub usuń odniesienia do narzędzi, z których już nie korzystasz, i zachowaj ostrożność przy spłaszczaniu list adresów IP, ponieważ spłaszczone listy tracą aktualność, gdy dostawcy zmieniają adresy.

4. Narzędzia pomocy technicznej i obsługi klienta

Zespoły wsparcia technicznego zazwyczaj oczekują, że odpowiedzi będą wysyłane z adresu [email protected]. Oznacza to, że serwery działu pomocy technicznej wysyłają wiadomości z adresem nadawcy zawierającym nazwę Twojej domeny, co wymaga zgodności z protokołami SPF lub DKIM, aby przejść weryfikację DMARC. Wiele konfiguracji pomija ten etap, ponieważ zgłoszenia wydają się działać podczas testów: własne testy dostawcy kończą się powodzeniem, a dostarczenie wiadomości do skrzynek o łagodnych zasadach filtrowania przebiega bez problemów.

Obsługa wiadomości przychodzących powoduje kolejny zestaw problemów. Automatyczne przekierowanie skrzynki pocztowej działu wsparcia do działu pomocy technicznej jest proste, ale przekierowanie często powoduje naruszenie zasad SPF, ponieważ adres IP serwera przekierowującego nie jest autoryzowany przez pierwotnego nadawcę. Podpisy DKIM mogą przetrwać przekierowanie, co jest jednym z powodów, dla których zgodność DKIM jest bardziej niezawodna niż zgodność SPF.

Jak to zweryfikować:

• Dodaj rekordy DKIM dostawcy, aby odpowiedzi były podpisane Twoją domeną, a w razie potrzeby dodaj również rekordy SPF lub return-path dostawcy.
• Zamiast reguł automatycznego przekazywania wiadomości ze skrzynek pocztowych należy stosować routing MX lub metodę przekazywania obsługiwanej przez dostawcę.
• Przetestuj odpowiedź na zgłoszenie wysłaną na zewnętrzną skrzynkę pocztową i sprawdź nagłówki, a następnie powtórz tę czynność w przypadku wiadomości automatycznych, takich jak ankiety dotyczące zadowolenia, które czasami pochodzą z innego systemu.
• Usuń rekordy dotyczące narzędzi pomocy technicznej, z których już nie korzystasz.

5. Narzędzia do zarządzania kalendarzem i harmonogramami

Narzędzia do planowania wysyłają zaproszenia, potwierdzenia i przypomnienia, zazwyczaj w imieniu organizatora. Większość z nich wysyła wiadomości z domeny dostawcy, podając Twój adres w polu „Reply-To”, co nie ma wpływu na Twój wskaźnik DMARC. Problemy wynikają z opcji firmowych, które wysyłają wiadomości z Twojej domeny bez uwierzytelnienia, oraz z wiadomości kalendarzowych wysyłanych bez podpisu.

Łatwo przeoczyć przypadek braku podpisu. Jeśli w usłudze Microsoft 365 nie włączono podpisywania DKIM dla Twojej domeny niestandardowej, wychodząca poczta jest podpisywana domyślną domeną dzierżawcy, która nie pokrywa się z Twoją domeną nadawcy. Również w usłudze Google Workspace konieczne jest włączenie podpisu DKIM dla Twojej domeny.

Jak to zweryfikować:

• Sprawdź, jakiej domeny używa narzędzie w polu „Od” dla każdego typu wiadomości.
• Włącz podpisywanie DKIM dla swojej domeny niestandardowej u dostawcy usług pocztowych, aby zaproszenia kalendarzowe i wiadomości wysyłane ze skrzynki pocztowej były spójne.
• Jeśli korzystasz z opcji wysyłania z brandingiem, uwierzytelnij ją za pomocą rekordów DKIM i return-path dostawcy.
• Sprawdź wiadomości e-mail z przypomnieniami i informacjami o odwołaniu osobno od zaproszeń.

6. Platformy rozliczeniowe, fakturowania i płatności

Faktury, pokwitowania i upomnienia o płatnościach należą do najczęściej wykorzystywanych rodzajów wiadomości e-mail. Atakujący podszywają się pod nie, ponieważ odbiorcy szybko reagują na wszelkie sprawy związane z pieniędzmi, a sfałszowana faktura może spowodować przekierowanie płatności. Platformy te często wysyłają wiadomości z własnej domeny, podając nazwę Twojej firmy, i oferują opcję wysyłania wiadomości z adresu [email protected]. Opcja ta działa w ramach protokołu DMARC tylko wtedy, gdy skonfigurowano odpowiednie rekordy DNS.

Firmy często korzystają jednocześnie z kilku narzędzi związanych z rozliczeniami, takich jak oprogramowanie księgowe, system przetwarzania płatności oraz menedżer subskrypcji. Każde z nich stanowi odrębnego nadawcę z własnymi danymi.

Jak to zweryfikować:

• Skorzystaj z funkcji niestandardowej domeny e-mailowej dostępnej na każdej platformie i opublikuj udostępnione przez nią rekordy DKIM, SPF oraz return-path.
• Należy sporządzić listę wszystkich systemów wysyłających korespondencję rozliczeniową oraz sprawdzić, czy każdy z nich przeprowadza uwierzytelnianie i zapewnia zgodność danych.
• Przejdź na politykę egzekwowania, gdy tylko raporty wskażą, że Twoje wiarygodne źródła spełniają wymagania. To właśnie powstrzymuje atakujących przed wysyłaniem faktur, które wyglądają jak Twoje.
• Poinformuj klientów, z jakich adresów pochodzą Twoje faktury.

7. Systemy kadrowe, rekrutacyjne i płacowe

Systemy do zarządzania kandydatami wysyłają kandydatom wiadomości e-mail z adresów typu careers@ lub jobs@, platformy do wdrażania nowych pracowników wysyłają wiadomości powitalne, a narzędzia do obsługi płac wysyłają powiadomienia do pracowników. Często są one wybierane i konfigurowane przez dział kadr bez udziału działu IT, więc nikt nie sprawdza ustawień DNS. W rezultacie oferty pracy trafiają do folderu ze spamem, a kandydaci nie otrzymują zaproszeń na rozmowy kwalifikacyjne.

Również tutaj często dochodzi do podszywania się pod inne podmioty. E-maile z ofertami pracy, które naśladują wizerunek prawdziwych firm, to powszechnie stosowana taktyka, a wdrożona polityka DMARC utrudnia wysyłanie takich wiadomości z Twojej rzeczywistej domeny.

Jak to zweryfikować:

• Należy uwzględnić weryfikację systemu DNS w procesie zakupu oprogramowania kadrowego.
• Należy uwierzytelnić dedykowaną subdomenę przeznaczoną do wysyłania wiadomości rekrutacyjnych, korzystając z rekordów DKIM i return-path dostarczonych przez dostawcę.
• Opublikuj krótką listę oficjalnych adresów związanych z rekrutacją i obsługą płac, aby kandydaci i pracownicy mogli je rozpoznać.
• Sprawdź, czy zaproszenia na rozmowę kwalifikacyjną i e-maile z ofertami pracy docierają do rzeczywistych skrzynek odbiorczych, w tym do skrzynek u dostawców bezpłatnych usług poczty internetowej.

Przykładowe wpisy DNS

Dokładne nazwy i wartości pochodzą ze stron konfiguracyjnych poszczególnych dostawców. Poniższe wzory pokazują, czego można się spodziewać. Nazwy domen są symbolami zastępczymi.

SPF w subdomenie wysyłającej (jeden rekord na domenę)
mail.example.com. TXT „v=spf1 include:_spf.vendor.example ~all”

Rekordy podpisu DKIM, zazwyczaj udostępniane jako rekordy CNAME:
selector1._domainkey.mail.example.com. CNAME selector1.dkim.vendor.example.
selector2._domainkey.mail.example.com. CNAME selector2.dkim.vendor.example.

Niestandardowa domena ścieżki zwrotnej (bounce)
bounce.mail.example.com. CNAME return.vendor.example.

Rekord DMARC, uruchamiany w trybie monitorowania
_dmarc.example.com. TXT „v=DMARC1; p=none; rua=mailto:[email protected]” 

Jak zweryfikować nadawcę przed uruchomieniem serwisu

Wyślij prawdziwą wiadomość z systemu na zewnętrzną skrzynkę pocztową, otwórz źródło oryginalnej wiadomości i sprawdź wyniki uwierzytelnienia. Chcesz, aby weryfikacja SPF lub DKIM zakończyła się powodzeniem, a domena, z której pochodzi wiadomość, była zgodna z domeną nadawcy.

Zgodność: DMARC pozytywny
spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=mail.example.com

Zatwierdzono, ale brak zgodności: błąd DMARC
spf=pass smtp.mailfrom=bounces.vendor.example
dkim=pass header.d=vendor.example
dmarc=fail header.from=example.com 

W drugim przykładzie obie weryfikacje zakończyły się powodzeniem, ale dotyczyły domeny dostawcy. Żadna z nich nie pasuje do example.com, więc weryfikacja DMARC zakończyła się niepowodzeniem. Jest to cecha charakterystyczna dla nieuwierzytelnionego nadawcy zewnętrznego.

Plan wdrożenia

1. Zrób spis nadawców. Zapytaj dział finansowy o subskrypcje SaaS, przejrzyj listę aplikacji korzystających z logowania jednokrotnego, zapoznaj się z wpisami SPF oraz sprawdź logi poczty.
2. Opublikuj rekord DMARC z wartością p=none i adresem raportującym. Raporty zbiorcze pokazują wszystkie systemy wysyłające wiadomości w imieniu Twojej domeny, w tym te, o których nikt już nie pamiętał.
3. Należy uwierzytelnić każdego legalnego nadawcę. Należy stosować niestandardowe ustawienia DKIM i ścieżki zwrotnej oraz preferować subdomeny w przypadku systemów o dużej przepustowości lub wysokim ryzyku.
4. Przejdź do etapu egzekwowania. Gdy raporty wykażą przepływ legalnej poczty, należy przejść do kwarantanny, a następnie do odrzucania, obserwując raporty na każdym etapie.
5. Niech to stanie się rutyną. Dodaj weryfikację uwierzytelniania e-mailowego do procesu wdrażania dostawców i usuwaj rekordy DNS po wycofaniu narzędzia z użytku.

FAQ

Jaka jest różnica między pozytywnym wynikiem testu SPF lub DKIM a pozytywnym wynikiem testu DMARC?

SPF i DKIM mogą zostać uznane za prawidłowe dla dowolnej domeny, w tym dla domeny dostawcy. DMARC wprowadza dodatkowy wymóg, zgodnie z którym domena uznana za prawidłową musi być zgodna z domeną podaną w polu „Od”.

Czy muszę dodać każdego dostawcę do mojego rekordu SPF?

Nie zawsze. Jeśli dostawca korzysta z niestandardowej ścieżki zwrotnej w Twojej subdomenie i podpisuje wiadomości za pomocą dostosowanego DKIM, DMARC może przejść pomyślnie bez ingerencji w główny rekord SPF. Mniejsza liczba elementów „include” pomaga również utrzymać się poniżej limitu 10 wyszukiwań.

Czy powinienem korzystać z subdomen dla nadawców zewnętrznych?

Często tak. Subdomena oddziela reputację od rekordów DNS i ułatwia śledzenie oraz kontrolowanie każdego źródła. Należy pamiętać, że subdomeny dziedziczą politykę DMARC, chyba że ustawisz opcję sp= lub opublikujesz oddzielny rekord.

Ile czasu zajmuje osiągnięcie poziomu p=odrzucenie?

To zależy od liczby nadawców i tego, jak szybko uda się je naprawić. Wiele organizacji potrzebuje na to od kilku tygodni do kilku miesięcy, kierując się zbiorczymi raportami.

Co zrobić, jeśli dostawca nie może podpisać certyfikatu przy użyciu mojej domeny?

W takim razie DMARC musiałby przejść proces dostosowania do SPF przy użyciu niestandardowej ścieżki zwrotnej. Jeśli żadne z tych rozwiązań nie jest możliwe, dostawca powinien wysyłać wiadomości ze swojej własnej domeny, a nie z Twojej.

Czy standard DMARC ma zastosowanie do wiadomości wysyłanych za pośrednictwem Google Workspace lub Microsoft 365?

Tak. Upewnij się, że podpis DKIM jest tam włączony dla Twojej domeny niestandardowej, w przeciwnym razie wiadomości mogą być podpisywane przy użyciu domyślnej domeny, która nie jest zgodna.