Przekazywanie poczty psuje SPF, ponieważ serwer przekazujący przesyła wiadomość dalej z własnego adresu IP, a tego adresu nigdy nie umieszczono w rekordzie SPF pierwotnego nadawcy. Gdy docelowy dostawca skrzynki uruchamia weryfikację SPF, sprawdza domenę zapisaną w nadawcy koperty i zadaje proste pytanie: czy łączący się adres IP ma prawo wysyłać w imieniu tej domeny? Serwer przekazujący go nie ma, więc odpowiedź brzmi: niepowodzenie. To nie jest błąd ani zła konfiguracja. To celowe ograniczenie sposobu działania SPF, opisane w RFC 7208, i dotyka zarówno zwykłych aliasów, jak i list dyskusyjnych.
Dobra wiadomość jest taka, że rozwiązanie jest dobrze poznane. Sender Rewriting Scheme (SRS) naprawia weryfikację SPF, a DKIM wraz z ARC przywracają zgodność DMARC, której sam SRS zapewnić nie potrafi. Oto dokładne wyjaśnienie, dlaczego przekazywanie zawodzi i jak wspinać się po kolejnych szczeblach rozwiązań.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Przyczyna źródłowa: SPF autoryzuje adresy IP, a nie domeny
SPF to lista adresów IP oraz odwołań include, którą domena publikuje w DNS. Rekord taki jak v=spf1 include:_spf.google.com -all mówi światu: "to są serwery uprawnione do wysyłania poczty z moją domeną w nadawcy koperty". Gdy serwer odbiorczy otrzymuje wiadomość, odczytuje domenę z nadawcy koperty (adres SMTP MAIL FROM, nazywany też Return-Path), wyszukuje rekord SPF tej domeny i sprawdza, czy adres IP, który właśnie się połączył, znajduje się w zbiorze autoryzowanych adresów.
Prześledźmy teraz przekazanie wiadomości. Wiadomość zostaje wysłana z newsletter@brand.com do alice@herdomain.com. Alice skonfigurowała alias, który przekazuje wszystko na alice@gmail.com. Jej serwer w domenie herdomain.com przyjmuje pocztę, a następnie wysyła ją dalej na serwery przychodzące Google. Gdy Gmail sprawdza SPF, nadal widzi w nadawcy koperty domenę brand.com, lecz łączący się adres IP należy teraz do herdomain.com. Tego adresu nie ma nigdzie w rekordzie SPF domeny brand.com, bo Brand nie ma pojęcia, że Alice przekazuje swoją pocztę. SPF zawodzi.
Weryfikacja nigdy nie była błędna. Brand faktycznie nie autoryzował serwera Alice. SPF po prostu nie ma mechanizmu, który pozwalałby powiedzieć: "ufam temu punktowi pośredniemu, że przekaże pocztę w moim imieniu". To jest sedno problemu.
Dlaczego listy dyskusyjne są jeszcze gorsze
Lista dyskusyjna, taka jak lista Mailman czy Google Groups, to serwer przekazujący, który dodatkowo edytuje wiadomość. Często przepisuje temat, dodając znacznik [list-name], dołącza stopkę z linkiem wypisania i wysyła wiadomość ponownie z własnego adresu IP. Zmiana adresu IP psuje SPF dokładnie tak samo jak w przypadku aliasu, a zmiana treści psuje na dodatek pierwotny podpis DKIM. Listy dyskusyjne to klasyczny przypadek, w którym obie metody uwierzytelniania zawodzą jednocześnie.
Nadawca koperty a nagłówek From: różnica, która ma znaczenie
Aby zrozumieć każde z opisanych dalej rozwiązań, musisz rozróżnić dwa różne adresy "od".
Nadawca koperty (MAIL FROM / Return-Path) jest używany podczas rozmowy SMTP i to na niego trafiają zwroty. To jest domena, którą sprawdza SPF.
Nagłówek From to adres, który odbiorca faktycznie widzi w swoim programie pocztowym. To jest domena, na której zależy DMARC pod kątem wyświetlania i zgodności.
Te dwa adresy mogą należeć do zupełnie różnych domen i na tym polega cała rzecz. DMARC nie chce po prostu, żeby SPF albo DKIM przeszły. Chce, żeby jeden z nich przeszedł i był zgodny z domeną nagłówka From. Zgodność SPF oznacza, że domena nadawcy koperty pasuje do domeny nagłówka From. Jeśli przepiszesz nadawcę koperty na domenę serwera przekazującego, aby SPF przeszedł, jednocześnie zepsujesz zgodność SPF z pierwotnym From. Zapamiętaj tę myśl, bo to właśnie dlatego SRS jest tylko połową odpowiedzi. Jeśli pojęcie zgodności jest dla Ciebie nowe, nasz przewodnik SPF, DKIM i DMARC wyjaśnione pokazuje, jak te trzy elementy do siebie pasują.
Rozwiązanie 1: SRS naprawia weryfikację SPF
Sender Rewriting Scheme to standardowe rozwiązanie dla serwera przekazującego. Gdy Twój serwer przekazuje wiadomość, SRS przepisuje nadawcę koperty tak, aby należał teraz do domeny przekazującej zamiast do pierwotnego nadawcy. Adres taki jak newsletter@brand.com zamienia się w coś w rodzaju SRS0=hash=tt=brand.com=newsletter@herdomain.com.
Ponieważ nadawca koperty jest teraz adresem w domenie herdomain.com, odbiorca sprawdza rekord SPF domeny herdomain.com zamiast domeny Brand. Adres IP Twojego serwera przekazującego znajduje się w tym rekordzie, więc SPF przechodzi. Zakodowany pierwotny adres zostaje zachowany, aby zwroty można było poprawnie skierować z powrotem.
SRS na Postfixie
Powszechnym podejściem na Postfixie jest PostSRSd. Zainstaluj go, a następnie wskaż go Postfixowi jako usługę kanonicznego przepisywania nadawcy i odbiorcy:
sender_canonical_maps = tcp:localhost:10001
recipient_canonical_maps = tcp:localhost:10002
PostSRSd obsługuje przepisywanie przy wychodzeniu wiadomości oraz odwrotne dekodowanie przy zwrotach. Upewnij się, że domena przekazująca, na którą przepisujesz adresy, ma rekord SPF autoryzujący Twój wychodzący adres IP, w przeciwnym razie po prostu przeniesiesz niepowodzenie zamiast je naprawić. Jeśli Twój rekord robi się duży, miej na oku limit dziesięciu odwołań DNS opisany w naprawa SPF: zbyt wiele odwołań DNS.
SRS na Microsoft 365
Jeśli przekazujesz pocztę przez Microsoft 365, nie konfigurujesz SRS samodzielnie. Microsoft stosuje SRS automatycznie dla poczty przekazywanej przez Exchange Online, przepisując nadawcę koperty (P1) do przestrzeni domeny onmicrosoft.com lub domeny zaakceptowanej, tak aby SPF przeszedł w kolejnym punkcie pośrednim. Twoim zadaniem jest zadbanie o to, aby przekazywanie było skonfigurowane za pomocą wspieranych mechanizmów (przekazywanie skrzynki, reguły przepływu poczty lub przekazywanie na kontakcie pocztowym), a nie regułą po stronie klienta, która wysyła wiadomość ponownie jako nową.
Rozwiązanie 2: dlaczego sam SRS nie spełnia wymagań DMARC
Oto pułapka. SRS sprawia, że SPF przechodzi, ale jednocześnie czyni SPF niezgodnym. Po przepisaniu nadawca koperty to herdomain.com, podczas gdy nagłówek From to nadal brand.com. SPF uwierzytelnia teraz niewłaściwą domenę z punktu widzenia DMARC. Dlatego domena publikująca rygorystyczną politykę DMARC może nadal widzieć, że przekazana wiadomość nie przechodzi DMARC, bo nie zachodzi ani zgodność SPF, ani zgodność DKIM.
SRS rozwiązuje kwestię zwrotów i surowy wynik SPF. Sam z siebie nie przeprowadzi jednak przekazanej wiadomości przez politykę p=reject. Do tego potrzeba, aby własne uwierzytelnianie domeny nagłówka From przetrwało podróż.
Rozwiązanie 3: DKIM i ARC dopełniają obraz
Tym, co faktycznie przeprowadza wiadomość przez przekazanie w nienaruszonym stanie, jest DKIM. Podpis DKIM to kryptograficzny podpis obejmujący wybrane nagłówki i treść, opublikowany dla domeny wysyłającej. Ponieważ podróżuje wewnątrz wiadomości i jest powiązany z domeną From, zwykłe przekazanie aliasem, które nie modyfikuje wiadomości, pozostawia DKIM prawidłowym. DKIM przechodzi, DKIM jest zgodny z domeną From i DMARC przechodzi, mimo że SPF zawiódł. Dokładnie dlatego każdy nadawca powinien podpisywać pocztę za pomocą DKIM; zobacz jak skonfigurować DKIM. Jeśli DKIM przechodzi, ale mimo to nie osiąga zgodności, nasz przewodnik naprawa zgodności DKIM omawia reguły dopasowania domen.
Pozostaje trudny przypadek listy dyskusyjnej, która edytuje treść. Zmiany treści unieważniają pierwotny podpis DKIM, więc teraz zawodzą zarówno SPF, jak i DKIM, i DKIM również nie jest w stanie uratować wiadomości.
Tu wkracza ARC
Authenticated Received Chain (ARC) to odpowiedź na ten ostatni przypadek. Gdy serwer przekazujący lub lista odbiera wiadomość, zapisuje wyniki uwierzytelniania, które zobaczył (pierwotne werdykty SPF, DKIM i DMARC), i pieczętuje je własnym podpisem, dodając nagłówki ARC-Seal, ARC-Message-Signature oraz ARC-Authentication-Results. Kolejny punkt pośredni może następnie odczytać ten łańcuch i rozumować: "SPF i DKIM tutaj zawodzą, ale serwer przekazujący, któremu ufam, poświadcza, że przeszły one, zanim zmodyfikował wiadomość". Odbiorca, który ufa podpisującemu ARC, może uszanować to poświadczenie i doręczyć pocztę mimo zepsutego pierwotnego uwierzytelniania.
ARC nie wymusza doręczenia. Daje końcowemu odbiorcy wiarygodny dowód pozwalający podjąć lepszą decyzję. Wielcy dostawcy, tacy jak Google i Microsoft, zarówno generują, jak i oceniają ARC, dlatego przekazywana poczta z list wysyłana przez duże usługi na ogół i tak dociera, nawet przy rygorystycznym DMARC.
Podsumowanie
Czytelny model myślowy to drabina. SPF z założenia zawodzi przy przekazaniu, bo adres IP serwera pośredniczącego nie jest autoryzowany. SRS naprawia surową weryfikację SPF i utrzymuje działanie zwrotów. DKIM utrzymuje zgodność uwierzytelniania z widoczną domeną From przez proste przekazania, więc to on, a nie SRS, faktycznie spełnia wymagania DMARC. ARC ratuje wiadomości, które są edytowane w drodze, zachowując wcześniejsze werdykty w kolejnych punktach pośrednich. Publikuj SPF i DKIM poprawnie, przesuwaj politykę DMARC w górę w sposób przemyślany, tak jak opisano w polityka DMARC: none, quarantine czy reject, a przekazywanie przestanie być zagadką.
Najczęściej zadawane pytania
Czy SRS naprawia zarówno DMARC, jak i SPF?
Nie. SRS sprawia, że SPF przechodzi, przepisując nadawcę koperty na domenę serwera przekazującego, ale to psuje zgodność SPF z nagłówkiem From, więc DMARC nie przechodzi na podstawie samego SPF. DMARC przetrwa przekazanie dzięki DKIM, który pozostaje zgodny z widoczną domeną From, albo dzięki ARC, gdy wiadomość została zmodyfikowana. Traktuj SRS jako rozwiązanie dla SPF i zwrotów, a DKIM wraz z ARC jako rozwiązanie dla DMARC.
Czy przekazywana poczta zawiedzie, jeśli używam p=reject?
Niekoniecznie. Zwykłe przekazanie aliasem, które nie modyfikuje wiadomości, zachowuje pierwotny podpis DKIM prawidłowym, więc DMARC przechodzi na podstawie DKIM nawet przy p=reject. Listy dyskusyjne, które edytują temat lub treść, psują DKIM i tam to właśnie ARC pozwala ufającemu odbiorcy mimo wszystko doręczyć wiadomość. Ryzyko jest największe dla edytowanej poczty z list wysyłanej do odbiorcy, który nie ocenia ARC.
Dlaczego przy przekazaniu SPF zawodzi, ale DKIM przechodzi?
Bo sprawdzają różne rzeczy. SPF weryfikuje łączący się adres IP względem domeny nadawcy koperty, a przekazywanie zmienia adres IP, więc zawodzi. DKIM weryfikuje kryptograficzny podpis niesiony wewnątrz wiadomości względem domeny From, a przekazanie, które pozostawia wiadomość nienaruszoną, nie narusza tego podpisu, więc nadal się on potwierdza. To codzienny powód, dla którego przy przekazywanej poczcie warto polegać na DKIM.
Czy muszę konfigurować SRS na Microsoft 365?
Nie. Exchange Online stosuje SRS automatycznie dla poczty, którą przekazuje, przepisując nadawcę koperty tak, aby SPF przeszedł w kolejnym punkcie pośrednim. Twoim obowiązkiem jest korzystanie ze wspieranego przekazywania po stronie serwera zamiast reguł po stronie klienta oraz zadbanie o to, aby Twoja domena publikowała prawidłowe SPF i DKIM, żeby wiadomości uwierzytelniały się już na starcie.