Jakiś SPF przekazuje odpowiedzi, czy wysyłający adres IP został autoryzowany dla ocenianej tożsamości SPF . DMARC zadaje dodatkowe pytanie: czy ta uwierzytelniona tożsamość jest zgodna z domeną w polu From? Jakiś raport zbiorczy może zatem pokazać surową przepustkę SPF i awarię DMARC związaną z SPF bez zaprzeczania sobie.
Zidentyfikuj domenę uwierzytelnioną przez SPF
Referencje: RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
Przeczytaj auth_results/spf/domain i wynik razem. Sprawdź identyfikatory/nagłówek_z, dowolną kopertę z i raportowany zakres. Nie zakładaj, że SPF sprawdził widoczną domenę From. RFC 7208 definiuje POCZTA OD tożsamość, podczas gdy RFC 9989 wykorzystuje tę tożsamość do celów wkładu SPF do DMARC .
W przypadku zerowej ścieżki zwrotnej SPF definiuje tożsamość MAIL FROM za pomocą postmastera w HELO domena. Ten szczególny przypadek nie powinien stać się regułą, że każda niezależna przepustka HELO spełnia wymogi DMARC . Aktualny RFC 9990 pozwolenia na raportowanie m z zakresu SPF ; starsze formaty raportów mogą ujawniać różne pola i wymagać wyraźnej interpretacji.
Zastosuj właściwy tryb wyrównania
Referencje: RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
Ścisłe SPF wyrównanie wymaga, aby uwierzytelniona domena była dokładnie zgodna z domeną autora. Swobodne dopasowanie pozwala na relację zdefiniowaną za pomocą mających zastosowanie reguł domeny organizacyjnej. Nie obliczaj tego po prostu usuwając ustaloną liczbę etykiet: ważny jest sufiks publiczny i szczegóły dotyczące odkrywania zasad.
Wartość SPF w wierszu/policy_evaluated wyraża wynik związany z DMARC, a nie duplikat surowego wyniku SPF . Pierwotna awaria lub błąd nie może stać się pomyślną ścieżką SPF tylko dlatego, że nazwy domen są do siebie podobne. Uwierzytelnianie musi zakończyć się powodzeniem i być wyrównane.
Przerabiaj dwa kontrastujące rzędy
Referencje: RFC 9989 §5.3.5.
Załóż, że obowiązują prawidłowe zasady, zakończone kontrole i niepowiązane domeny organizacyjne dla brand.example i vendor.example . Wiersz syntetyczny A używa nagłówka_od= brand.example , MAIL FROM= vendor.example i surowy SPF =pass. Niepowiązana tożsamość nie jest wyrównana, dlatego oczekiwane jest policy_evaluated/ spf=fail . Dodanie adresu IP dostawcy do SPF brand.example nie zmienia tożsamości faktycznie ocenianej przez tę trasę.
Syntetyczny wiersz B używa nagłówka_od= brand.example i MAIL FROM= bounce.brand.example z surowym SPF =pass. Załóżmy, że odpowiednie odkrycie domeny organizacyjnej umieszcza je razem. Luźne wyrównanie SPF może przejść pomyślnie, podczas gdy ścisłe wyrównanie SPF kończy się niepowodzeniem, ponieważ nazwy są różne. Są to przykładowe urządzenia terenowe, a nie obserwowany ruch uliczny.
Sprawdź wyrównanie w każdym rzędzie DKIM przed stwierdzeniem, że DMARC jako całość poniósł porażkę. Przejście wyrównane Podpis DKIM może zapewnić pomyślną ścieżkę DMARC niezależnie od SPF .
Wybierz naprawę, która zmieni uszkodzoną warstwę
Referencje: RFC 7208 §10.3.
Jeśli surowy SPF zakończy się niepowodzeniem, sprawdź autoryzację i ścieżkę połączenia dla aktualnie ocenianej domeny. Jeśli surowy SPF przejdzie, ale nie zostanie wyrównany, sprawdź obsługiwaną niestandardową konfigurację MAIL FROM lub inną dostosowaną ścieżkę uwierzytelniania. Nie dodawaj adresów IP do niepowiązanych domen Rekord SPF.
Potwierdź zmiany za pomocą kontrolowanej otrzymanej poczty i późniejszych dowodów raportowania, zachowując zarówno surowe, jak i dopasowane wyniki. Przekazywanie może zmienić adres IP połączenia, dlatego przetestuj odpowiednie trasy i unikaj traktowania samego SPF jako gwarancji dostarczenia. Zakończ badanie, uwzględniając ocenioną tożsamość, tryb dopasowania i zademonstrowany wynik.
Zachowaj przypadki testowe od surowego do wyrównanego
Cztery częściowe mapy syntetyczne mają wspólny nagłówek_od= brand.example , zasady p=reject i przedział epoki 1704067200–1704153600. A używa MAIL FROM= vendor.example z nieprzetworzonym przebiegiem SPF i bez podpisów DKIM : wyrównane SPF i DMARC nie powiodą się. B używa MAIL FROM= bounce.brand.example z nieprzetworzonym przebiegiem SPF i bez DKIM : w wyraźnie przyjętej współdzielonej domenie organizacyjnej tryb swobodny przechodzi wyrównanie SPF i DMARC . To samo wejście B w trybie ścisłym zawodzi w obu przypadkach. Czwarty przypadek przywraca niepowiązaną tożsamość SPF A, ale dodaje przekazanie DKIM dla brand.example /selektor billing1: DMARC przechodzi przez DKIM .
Dostarczone ćwiczenie tożsamości lokalnej odtwarza wszystkie cztery wyniki z dostarczonych tożsamości, wyników i trybów dopasowania. Używa jawnej mapy domeny organizacyjnej, a nie implementacji drzewa DNS . Nie testuje również prawdziwego komunikatu o zerowej ścieżce zwrotnej; powyższe wskazówki dotyczące ścieżki zerowej są oparte na specyfikacji. Rzeczywiste zachowanie dostawcy i odbiorcy nadal wymaga potwierdzenia otrzymanej wiadomości.
Utrzymuj ćwiczenie w zakresie
Przykładami są częściowe prognozy pola, a nie raporty zgodne ze schematem lub zmierzony ruch. Kontrole lokalne korzystają z jawnie dostarczonych wyników uwierzytelniania i powiązań organizacyjnych; nie przeprowadzają wykrywania DNS , oceny SPF , weryfikacji kryptograficznej, przyjmowania raportów ani testów dostarczania do odbiorców. Zachowaj oryginalny raport i zaufane dowody wiadomości przed wprowadzeniem zmian w produkcji.