RFC 7489

RFC 7489 to specyfikacja standardu DMARC, łącząca wyniki SPF i DKIM w jedną politykę.

RFC 7489 jako opis ochrony poczty elektronicznej

RFC 7489 to dokument opisujący mechanizm DMARC, czyli sposób sprawdzania, czy wiadomość elektroniczna rzeczywiście może być uznana za wysłaną w imieniu określonej domeny. Znaczenie tej specyfikacji wiąże się przede wszystkim z ograniczaniem podszywania się pod firmy, sklepy internetowe, instytucje i osoby, których adresy są wykorzystywane w kampaniach phishingowych. DMARC nie jest pojedynczym testem wykonywanym na treści wiadomości. Stanowi warstwę polityki, która korzysta z wyników dwóch innych mechanizmów: SPF oraz DKIM.

W praktyce domena publikująca ustawienia DMARC przekazuje odbiorcom informację, jak postępować z wiadomościami, które nie spełniają wymagań uwierzytelnienia. Możliwe jest między innymi pozostawienie takiej poczty bez dodatkowej ingerencji, oznaczenie jej jako podejrzanej albo odrzucenie. Dzięki temu właściciel domeny może stopniowo przechodzić od obserwowania sytuacji do aktywniejszej ochrony swojej nazwy. RFC 7489 porządkuje również sposób przesyłania raportów, co pozwala analizować, z jakich źródeł wysyłane są wiadomości deklarujące użycie danej domeny.

RFC 7489, SPF i DKIM w jednym procesie weryfikacji

SPF oraz DKIM odpowiadają na różne pytania. SPF sprawdza, czy adres systemu wysyłającego znajduje się w regułach opublikowanych dla domeny użytej w ścieżce przesyłania poczty. DKIM opiera się na podpisie kryptograficznym dołączonym do wiadomości. Odbiorca pobiera klucz publiczny z DNS i sprawdza, czy podpis jest prawidłowy oraz czy istotne elementy wiadomości nie zostały zmienione po podpisaniu.

DMARC dodaje do tych mechanizmów pojęcie zgodności domen. Sam pozytywny wynik SPF albo DKIM nie zawsze wystarcza. Znaczenie ma także to, czy domena zweryfikowana w danym teście odpowiada domenie widocznej dla odbiorcy w polu From. Jeżeli wiadomość została wysłana przez pośrednika, a SPF potwierdził inną domenę, wynik techniczny może być pozytywny, lecz zgodność z adresem nadawcy pozostanie niespełniona. Podobnie podpis DKIM może być poprawny, ale pochodzić z domeny, która nie jest powiązana z widocznym nadawcą.

Polityka DMARC może działać w trybie ścisłym albo łagodniejszym. W wariancie ścisłym wymagana jest pełna zgodność nazw domen. W wariancie łagodniejszym dopuszcza się zgodność organizacyjną, na przykład między domeną główną a jej subdomeną. Wybór poziomu powinien wynikać z rzeczywistego sposobu wysyłania wiadomości, ponieważ zbyt restrykcyjne ustawienie wdrożone bez wcześniejszej analizy może objąć także legalną korespondencję.

RFC 7489 a typowe problemy z uwierzytelnianiem wiadomości

Jednym z częstych problemów jest publikowanie reguł SPF, które nie obejmują wszystkich usług wysyłających pocztę w imieniu domeny. Dotyczy to na przykład formularzy kontaktowych, systemów powiadomień, platform marketingowych oraz narzędzi używanych przez zewnętrznych dostawców. Wiadomość wysłana z pominięciem właściwego źródła może uzyskać negatywny wynik SPF, nawet gdy została wygenerowana legalnie.

W przypadku DKIM kłopoty wynikają zwykle z braku podpisu, nieaktualnego klucza publicznego, błędnej konfiguracji selektora albo modyfikacji wiadomości podczas przekazywania. Zdarza się, że podpis jest ważny przy wysyłce, lecz przestaje być prawidłowy po zmianie nagłówków lub treści przez pośredni system pocztowy. Osobnej uwagi wymaga zgodność domeny w polu From z domeną używaną w podpisie.

Problematyczne bywa także przejście od polityki obserwacyjnej do egzekwowania odrzuceń. Raporty mogą pokazać, że część wiadomości pochodzi z zapomnianych formularzy, dawnych usług albo nieudokumentowanych integracji. Włączenie ostrzejszej polityki bez rozpoznania tych źródeł może spowodować niedostarczenie prawidłowych powiadomień. Z tego powodu raporty DMARC należy czytać jako materiał diagnostyczny, a nie jako prosty wskaźnik, który można zignorować po pierwszym wdrożeniu.

Warto pamiętać, że DMARC nie szyfruje poczty i nie zastępuje zabezpieczeń kont użytkowników. Nie usuwa również wszystkich możliwości manipulowania treścią wiadomości. Jego głównym zadaniem jest poprawa wiarygodności domeny nadawcy oraz wskazanie odbiorcom, jak reagować na niespełnienie określonych warunków.

RFC 7489 w praktycznej konfiguracji domeny

Prace nad DMARC warto rozpocząć od spisu wszystkich miejsc, z których wysyłane są wiadomości w imieniu danej domeny. Należy uwzględnić zarówno pocztę wysyłaną przez użytkowników, jak i automatyczne komunikaty, takie jak potwierdzenia rejestracji, informacje o zmianie hasła, odpowiedzi z formularzy czy powiadomienia o statusie zamówienia. Pominięcie jednego źródła może później utrudnić ocenę raportów.

Następnie sprawdza się rekordy DNS związane z SPF, DKIM i DMARC. Rekord SPF powinien wskazywać aktualne źródła, a nie zawierać przypadkowo dodawanych wpisów z przeszłości. Dla DKIM potrzebny jest działający podpis oraz odpowiadający mu klucz publiczny. W DMARC istotne są między innymi polityka dla wiadomości niespełniających wymagań, ustawienia zgodności domen oraz adresy przeznaczone do odbierania raportów.

Bezpiecznym podejściem jest etap obserwacji. Najpierw analizuje się raporty i ustala, które wiadomości są prawidłowe, a które wskazują na nadużycie lub błąd konfiguracji. Dopiero po uporządkowaniu źródeł można rozważyć zaostrzenie reakcji odbiorców. Raporty zbiorcze przedstawiają dane statystyczne dotyczące prób wysyłki, wyników SPF i DKIM oraz zastosowanej polityki. Ich interpretacja wymaga porównania z rzeczywistymi procesami używanymi w organizacji.

Istotne jest również kontrolowanie zmian. Dodanie nowego narzędzia do wysyłki wiadomości powinno być poprzedzone sprawdzeniem, czy jego domena lub adres wysyłający są zgodne z istniejącymi regułami. Po zmianie warto zweryfikować podpisy, widoczną domenę nadawcy i wyniki testów z kilku niezależnych skrzynek odbiorczych. Pozwala to wykryć różnice między konfiguracją opublikowaną w DNS a faktycznym zachowaniem poczty.

RFC 7489 i moment zgłoszenia problemu do serwisu

Do serwisu warto zgłosić się wtedy, gdy wiadomości z własnej domeny regularnie trafiają do spamu, nie docierają do odbiorców albo otrzymuje się powiadomienia o niezgodności SPF, DKIM lub DMARC. Pomoc może być przydatna również wtedy, gdy pojawiają się wiadomości podszywające się pod daną domenę, a raporty wskazują nieznane źródła wysyłki. W takiej sytuacji potrzebne jest uporządkowanie informacji o domenie, urządzeniach, programach pocztowych i używanych usługach.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się wsparciem przy problemach z komputerami i pocztą używaną na tych urządzeniach, w tym przy porządkowaniu podstawowych ustawień wpływających na wysyłanie oraz odbieranie wiadomości. Przed zgłoszeniem warto przygotować nazwę domeny, przykładowe komunikaty o odrzuceniu, daty występowania problemu oraz informację, czy trudność dotyczy wszystkich odbiorców, czy tylko wybranych usług pocztowych.

Nie należy usuwać istniejących rekordów DNS ani zmieniać polityki pochopnie, zwłaszcza gdy poczta jest wykorzystywana do obsługi zamówień, kontaktu z klientami lub wysyłania automatycznych powiadomień. Przydatne jest zachowanie przykładowych nagłówków wiadomości, ponieważ zawierają one wyniki kontroli przeprowadzonych przez serwer odbiorcy. Na ich podstawie można odróżnić problem z uwierzytelnianiem domeny od błędu programu pocztowego, filtra antyspamowego, przekierowania lub konfiguracji konta.

RFC 7489 najlepiej traktować jako część szerszego porządku bezpieczeństwa poczty. Poprawna konfiguracja SPF, DKIM i DMARC ogranicza ryzyko podszywania się pod domenę, lecz wymaga okresowego przeglądu. Zmiany dostawców, formularzy, systemów powiadomień i sposobów wysyłki mogą wpływać na wyniki weryfikacji, dlatego ustawienia powinny być sprawdzane także po modernizacji środowiska pocztowego.