Nagłówek Authentication-Results to oficjalny zapis serwera odbiorczego mówiący o tym, czy Twoja wiadomość przeszła weryfikację SPF, DKIM i DMARC. Każdy dostawca skrzynek pocztowych, który przeprowadza te kontrole, wpisuje ich wynik właśnie do tego jednego nagłówka, więc jego poprawne odczytanie mówi dokładnie, dlaczego wiadomość trafiła do spamu, została poddana kwarantannie albo bez przeszkód dotarła do skrzynki odbiorczej. Gdy już wiesz, gdzie znajduje się każdy werdykt i co oznaczają słowa kwalifikatorów, 200-znakowy ciąg żargonu staje się precyzyjną diagnozą.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Gdzie znaleźć nagłówek i jak jest zbudowany
W Gmailu otwórz wiadomość, kliknij menu z trzema kropkami i wybierz Pokaż oryginał. W Outlooku lub Microsoft 365 otwórz wiadomość, przejdź do Plik, a następnie Właściwości i przeczytaj zawartość pola Nagłówki internetowe. W Yahoo otwórz wiadomość, kliknij Więcej, a następnie Zobacz surową wiadomość. Szukasz wierszy zaczynających się od Authentication-Results:.
Nagłówek jest zdefiniowany w RFC 8601 i zawsze zaczyna się od nazwy hosta serwera, który przeprowadził weryfikację (authserv-id), po której następuje jedna lub więcej par metoda=wynik oddzielonych średnikami. Pojedynczy wynik metody wygląda tak:
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=news.example.com; dkim=pass header.i=@example.com; dmarc=pass (p=REJECT) header.from=example.com
Czytaj go od lewej do prawej. Wartość authserv-id to mx.google.com. Następnie pojawiają się trzy werdykty: SPF przeszła dla domeny koperty, DKIM przeszła dla podpisu należącego do example.com, a DMARC przeszła z opublikowaną polityką domeny pokazaną jako p=REJECT. Ufaj wyłącznie nagłówkowi wpisanemu przez ostatni serwer odbiorczy, który kontrolujesz lub z którego korzystasz. Każdy nagłówek Authentication-Results dodany przez wcześniejszy przeskok może zostać sfałszowany, dlatego dostawcy usuwają go i wstawiają własny.
Odczytywanie prawdziwego nagłówka Gmaila pole po polu
Gmail to nagłówek, który będziesz sprawdzać najczęściej. W pełni uwierzytelniona wiadomość często zawiera coś takiego:
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector1 header.b=Ax3kf9; spf=pass (google.com: domain of bounce@news.example.com designates 198.51.100.7 as permitted sender) smtp.mailfrom=bounce@news.example.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Oto co oznacza każdy token:
dkim=pass- podpis kryptograficzny został pomyślnie zweryfikowany względem klucza publicznego w DNS.header.i=@example.com- tożsamość deklarowana przez podpis DKIM, pobrana ze znacznika i= wewnątrz DKIM-Signature. To domena, którą uwierzytelnił DKIM.header.s=selector1- selektor, który wskazuje, który rekord TXT w DNS zawierał klucz publiczny (selector1._domainkey.example.com).header.b=Ax3kf9- pierwsze bajty samego podpisu, przydatne jedynie do odróżnienia dwóch podpisów od siebie.spf=pass- wysyłający adres IP jest autoryzowany przez rekord SPF domeny koperty.smtp.mailfrom=bounce@news.example.com- nadawca koperty, nazywany też Return-Path lub MAIL FROM. SPF zawsze sprawdza tę domenę, a nie widoczny adres From.dmarc=pass- DMARC zakończyła się powodzeniem, ponieważ co najmniej jedna z metod SPF lub DKIM przeszła i była zgodna z widoczną domeną From.header.from=example.com- domena w nagłówku From, którą widzi człowiek. Zgodność DMARC porównuje ją ze smtp.mailfrom i header.i.(p=REJECT sp=REJECT dis=NONE)- opublikowana polityka domeny (p), polityka dla subdomen (sp) oraz faktycznie zastosowane rozporządzenie (dis).dis=NONEoznacza, że nie podjęto żadnego działania karnego, ponieważ wiadomość przeszła weryfikację.
Różnica między smtp.mailfrom a header.from to najważniejsza idea w tym wszystkim. Wiadomość może mieć spf=pass dla news.example.com, a mimo to nie przejść DMARC, jeśli widoczny adres From to example.com, a te dwie domeny nie są ze sobą zgodne. Zrozumienie tego rozdziału stanowi sedno przewodnika SPF, DKIM i DMARC wyjaśnione.
Warianty Outlook i Yahoo
Microsoft 365 stosuje nieco inny format i dodaje własny werdykt compauth:
Authentication-Results: spf=pass (sender IP is 198.51.100.7) smtp.mailfrom=news.example.com; dkim=pass (signature was verified) header.d=example.com; dmarc=pass action=none header.from=example.com; compauth=pass reason=100
Dwie rzeczy różnią się od Gmaila. Microsoft raportuje domenę DKIM jako header.d= (znacznik d=), a nie jako header.i=; w praktyce obie wskazują domenę podpisującą. Dodaje też compauth, złożony wynik uwierzytelnienia, którego Microsoft używa do wychwytywania podszywania się umykającego pojedynczym kontrolom. compauth=pass reason=100 to stan zdrowy. Wynik compauth=fail reason=000 lub reason=001 zwykle oznacza, że ani DKIM, ani SPF nie były zgodne, a Microsoft potraktował wiadomość jako niejawną próbę podszycia się.
Yahoo ściśle trzyma się układu z RFC 8601:
Authentication-Results: atlas.yahoo.com; dkim=pass header.i=@example.com header.s=s2048; spf=pass smtp.mailfrom=example.com; dmarc=pass(p=REJECT) header.from=example.com
Tokeny mają to samo znaczenie u wszystkich trzech dostawców. Gdy potrafisz odczytać wersję Gmaila, poradzisz sobie z każdą z nich.
Każda wartość wyniku i jej znaczenie
Kwalifikator po każdej metodzie to werdykt. Ta tabela obejmuje każdą wartość zdefiniowaną w dokumentach RFC dotyczących SPF i DMARC.
| Wynik | Znaczenie | Typowa przyczyna |
|---|---|---|
| pass | Kontrola zakończyła się powodzeniem i tożsamość jest autoryzowana | Poprawny rekord SPF lub prawidłowy podpis DKIM |
| fail | Kontrola się odbyła, a nadawca nie jest autoryzowany | Wysyłający adres IP nieobecny w SPF lub twarde odrzucenie -all |
| softfail | SPF ma wątpliwości co do nadawcy, ale nie odrzuca twardo | Rekord kończy się na ~all, a adres IP nie jest wymieniony |
| neutral | SPF wyraźnie nie zajmuje stanowiska | Rekord używa ?all |
| none | Brak polityki do sprawdzenia | Brak rekordu SPF, brak podpisu DKIM lub brak rekordu DMARC |
| policy | Kontrola się odbyła, ale lokalna polityka nadpisała wynik | Obsługa specyficzna dla dostawcy |
| temperror | Tymczasowa awaria, ponowna próba może się powieść | Przekroczenie limitu czasu DNS lub przejściowy błąd wyszukiwania |
| permerror | Trwały błąd w samym rekordzie | Uszkodzona składnia SPF lub ponad 10 zapytań DNS |
Dwie z tych wartości zasługują na szczególną uwagę. softfail oznacza, że Twój rekord SPF kończy się na ~all zamiast -all, więc nieautoryzowana poczta jest przyjmowana, ale oznaczana. permerror w SPF bardzo często oznacza przekroczenie limitu 10 zapytań DNS z RFC 7208, co jest problemem rekordu, a nie nadawcy, i warto to naprawić bezpośrednio. Różnica między temperror a permerror decyduje o tym, czy poczekasz, czy edytujesz swój DNS.
Drzewo decyzyjne jeśli-X-zawiodło-napraw-Y
Przeanalizuj werdykty w tej kolejności. To DMARC decyduje o umieszczeniu w skrzynce odbiorczej, więc zacznij od pytania, dlaczego nie przeszła.
Jeśli dmarc=pass
Nie ma nic do naprawy. Co najmniej jedna z metod SPF lub DKIM przeszła i była zgodna z Twoją domeną From. Gotowe.
Jeśli dmarc=fail, ale spf=pass i dkim=pass
To błąd zgodności (alignment), a nie błąd uwierzytelnienia. SPF przeszła dla domeny koperty, a DKIM się zweryfikował, ale żadna z nich nie odpowiadała widocznej domenie From. Sprawdź, czy smtp.mailfrom i header.i współdzielą domenę organizacyjną z header.from. Napraw tę niezgodną. Zgodność DKIM to zwykle łatwiejsza dźwignia, opisana w przewodniku napraw zgodność DKIM.
Jeśli spf=fail lub spf=softfail
Wysyłający adres IP nie znajduje się w Twoim rekordzie SPF. Dodaj ten adres IP lub mechanizm include dostawcy i upewnij się, że rekord kończy się na -all. Jeśli SPF przechodzi na Twoim własnym serwerze, ale zawodzi po przekazaniu wiadomości dalej, to zachowanie oczekiwane, ponieważ przekazywanie zmienia wysyłający adres IP; zobacz dlaczego przekazywanie poczty psuje SPF. W takim przypadku polegaj na DKIM, aby przeniósł uwierzytelnienie przez przeskok.
Jeśli dkim=fail
Podpis nie został zweryfikowany. Zwykłe przyczyny to bramka pocztowa, która zmodyfikowała treść po podpisaniu, obrócony klucz, który nie pasuje już do rekordu DNS, albo nieprawidłowy selektor. Odczytaj header.s=, aby znaleźć selektor, a następnie potwierdź, że selektor._domainkey.twojadomena.com zwraca aktualny klucz publiczny.
Jeśli spf=permerror lub dkim=permerror
Sam rekord jest uszkodzony. W przypadku SPF prawie zawsze oznacza to zbyt wiele zapytań DNS lub nieprawidłową składnię. W przypadku DKIM zwykle chodzi o źle sformułowany rekord klucza publicznego. To edycja DNS, a nie zmiana po stronie nadawcy.
Jeśli dmarc=none
Nie masz rekordu DMARC, więc odbiorcy nie mogą niczego egzekwować. Opublikuj co najmniej politykę monitorującą, taką jak v=DMARC1; p=none; rua=mailto:dmarc@twojadomena.com, i przechodź w stronę egzekwowania, gdy Twoje uprawnione źródła będą się uwierzytelniać bez zarzutu. Ścieżka od monitorowania do egzekwowania jest opisana w polityka DMARC: none, quarantine czy reject.
Dla wglądu w perspektywie długoterminowej nagłówek Authentication-Results pokazuje jedną wiadomość naraz, natomiast odczytywanie zbiorczych raportów DMARC pokazuje te same werdykty dla każdego źródła wysyłającego pod Twoją domeną.
Najczęściej zadawane pytania
Jaka jest różnica między smtp.mailfrom a header.from?
smtp.mailfrom to nadawca koperty używany podczas transakcji SMTP, nazywany też Return-Path, i to jego sprawdza SPF. header.from to adres, który człowiek widzi w wierszu From, i to względem niego mierzona jest zgodność DMARC. Często są to różne domeny, dlatego wiadomość może przejść SPF, a mimo to nie przejść DMARC.
Co oznacza header.i w wyniku DKIM?
header.i to tożsamość podpisująca pobrana ze znacznika i= wewnątrz nagłówka DKIM-Signature, na przykład @example.com. Mówi Ci, która domena jest właścicielem podpisu, który został zweryfikowany. Niektórzy dostawcy raportują tę samą informację jako header.d, znacznik domeny podpisującej. Aby DMARC uznał zgodność, domena w header.i lub header.d musi odpowiadać Twojej domenie From.
Czy spf=softfail oznacza, że mój e-mail zostanie odrzucony?
Nie. Softfail oznacza, że Twój rekord SPF kończy się na ~all, więc odbiorcy przyjmują wiadomość, ale traktują ją jako podejrzaną. To ostrzeżenie, a nie odrzucenie. Jeśli DMARC jest ustawiona na reject, a wiadomość dodatkowo nie przejdzie zgodności DKIM, to nadal może zostać zablokowana, więc nie traktuj softfail jak siatki bezpieczeństwa.
Czy mogę ufać nagłówkowi Authentication-Results dodanemu przez inny serwer?
Ufaj wyłącznie nagłówkowi wstawionemu przez ostatni serwer odbiorczy, który kontrolujesz lub z którego korzystasz, rozpoznawanemu po jego authserv-id na początku wiersza. Każdy nagłówek Authentication-Results dodany przez wcześniejszy przeskok może zostać sfałszowany przez atakującego, dlatego dostawcy skrzynek pocztowych usuwają niezaufane kopie i dodają własną przed dostarczeniem.