RFC 7489 – DMARC

RFC 7489 opisuje sposób publikowania polityki DMARC oraz mechanizm raportowania jej wyników.

RFC 7489 i DMARC – czym jest ten standard pocztowy

RFC 7489 opisuje mechanizm DMARC, czyli sposób oceny, czy wiadomość e-mail wysłana z określoną domeną może zostać uznana za zgodną z oczekiwaniami właściciela tej domeny. Rozwiązanie powstało jako uzupełnienie dwóch wcześniejszych mechanizmów: SPF oraz DKIM. Jego zadaniem jest nie tylko sprawdzenie technicznych cech wiadomości, lecz także przekazanie serwerowi odbiorcy informacji, co należy zrobić, gdy kontrola zakończy się niepowodzeniem.

DMARC opiera się na zasadzie powiązania domeny widocznej dla odbiorcy z domeną używaną podczas uwierzytelniania nadawcy. W praktyce oznacza to analizę pola From, które jest prezentowane w programie pocztowym, oraz porównanie go z domeną potwierdzoną przez SPF albo DKIM. Dzięki temu sama obecność poprawnego rekordu SPF lub podpisu DKIM nie wystarcza, jeśli uwierzytelniona domena nie pozostaje w odpowiedniej relacji z domeną widoczną w wiadomości.

Politykę DMARC publikuje się w systemie DNS jako rekord TXT pod nazwą zaczynającą się od _dmarc. Rekord może określać między innymi tryb postępowania z wiadomościami niespełniającymi wymagań, poziom zgodności domen oraz adresy przeznaczone do otrzymywania raportów. Z punktu widzenia administratora jest to deklaracja oczekiwanego sposobu obsługi poczty podszywającej się pod daną domenę.

DMARC w kontekście SPF, DKIM i nagłówków wiadomości

SPF sprawdza, czy adres IP serwera wysyłającego znajduje się w regułach opublikowanych dla domeny użytej w mechanizmie Return-Path, zwanym również adresem koperty nadawcy. DKIM dodaje do wiadomości podpis kryptograficzny, którego poprawność może zostać zweryfikowana na podstawie klucza publicznego opublikowanego w DNS. DMARC tworzy warstwę oceny nad tymi rozwiązaniami i sprawdza dodatkowo zgodność domen.

Wyróżnia się dwa poziomy zgodności. Przy zgodności z SPF domena użyta w adresie koperty musi odpowiadać domenie z pola From albo znajdować się w dozwolonej relacji zależnej od ustawionego trybu dopasowania. Przy zgodności z DKIM sprawdza się domenę wskazaną w parametrze d= podpisu. Wiadomość może przejść kontrolę DMARC, gdy spełniony zostanie warunek zgodności przez SPF lub przez DKIM, pod warunkiem że samo uwierzytelnianie daną metodą również zakończy się powodzeniem.

Znaczenie ma także sposób podpisywania wiadomości przez zewnętrzne systemy wysyłkowe. Jeżeli biuletyn, formularz kontaktowy, system transakcyjny albo platforma do obsługi korespondencji korzysta z własnej domeny podpisu DKIM, powinno zostać sprawdzone, czy domena ta jest prawidłowo powiązana z domeną widoczną w polu From. W przeciwnym razie wiadomość może przejść kontrolę DKIM, ale nie przejść oceny zgodności DMARC.

Do najczęściej stosowanych wartości polityki należą p=none, p=quarantine oraz p=reject. Pierwsza z nich służy głównie do obserwacji i zbierania danych. Druga sugeruje kierowanie wiadomości niespełniających wymagań do dodatkowej kontroli, często związanej z folderem spamu. Trzecia wskazuje, że wiadomość powinna zostać odrzucona. Ostateczne zachowanie zależy od serwera odbiorcy, dlatego rekord DMARC nie stanowi bezwzględnego polecenia realizowanego identycznie w każdej usłudze pocztowej.

RFC 7489 – typowe problemy z wdrożeniem DMARC

Jednym z częstych problemów jest opublikowanie polityki DMARC przed rozpoznaniem wszystkich legalnych źródeł wysyłki. Poczta może być generowana nie tylko przez podstawowy serwer pocztowy, ale również przez formularze na stronie, systemy powiadomień, platformy marketingowe, narzędzia do obsługi zgłoszeń oraz urządzenia wysyłające komunikaty automatyczne. Pominięcie któregoś z tych źródeł może doprowadzić do oznaczania prawidłowej korespondencji jako podejrzanej.

Trudności powoduje również niepełna konfiguracja SPF. Rekord może nie obejmować wszystkich serwerów używanych do wysyłki, może zawierać nieaktualne wpisy albo może przekraczać limit zapytań DNS przewidziany dla tego mechanizmu. Samo dopisanie kolejnych reguł bez uporządkowania istniejącej struktury nie zawsze poprawia sytuację.

W przypadku DKIM spotyka się brak podpisu, błędny klucz publiczny w DNS, niezgodny selektor albo modyfikację treści wiadomości po jej podpisaniu. Zmiany wprowadzane przez pośrednie systemy, takie jak dodawanie stopki lub przetwarzanie załączników, mogą wpływać na weryfikację podpisu. Należy również pamiętać, że podpis DKIM powinien wykorzystywać domenę pozostającą w wymaganej relacji z domeną z pola From.

Raporty DMARC bywają trudne do odczytania, ponieważ mają format XML i mogą zawierać dane zbiorcze z wielu serwerów. Powinno się analizować adresy IP, domeny nadawcze, wyniki SPF i DKIM, tryb zgodności oraz liczbę wiadomości obserwowanych w danym okresie. Pojedynczy wpis nie zawsze oznacza incydent. Może wskazywać na legalny system, który nie został wcześniej uwzględniony w dokumentacji konfiguracji poczty.

Nieprawidłowości mogą wystąpić także po zmianie operatora poczty, domeny wysyłkowej, dostawcy hostingu lub narzędzia używanego do rozsyłania wiadomości. Dlatego każda taka zmiana powinna być powiązana z ponownym sprawdzeniem rekordów DNS, podpisów DKIM i raportów DMARC.

DMARC – praktyczne wskazówki konfiguracji i kontroli

Prace warto rozpocząć od sporządzenia listy wszystkich usług, które wysyłają wiadomości w imieniu domeny. Następnie należy potwierdzić, jakie domeny pojawiają się w polu From, Return-Path oraz w podpisie DKIM. Takie zestawienie ułatwia wykrycie rozbieżności, których nie widać podczas zwykłego wysłania pojedynczej wiadomości testowej.

Pierwszy etap wdrożenia powinien mieć charakter obserwacyjny. Polityka niewymuszająca odrzucania pozwala sprawdzić, czy legalne źródła poczty przechodzą SPF lub DKIM oraz czy zachowana jest zgodność domen. Na podstawie raportów można skorygować rekordy DNS i ustawienia usług wysyłkowych. Dopiero po zebraniu wystarczających danych można rozważyć zaostrzenie polityki.

Warto zachować porządek w DNS. Każda domena używana do wysyłania poczty powinna mieć jasno określone przeznaczenie, a stare rekordy i nieużywane selektory DKIM powinny być usuwane po upewnieniu się, że nie są już potrzebne. Rekordy należy sprawdzać z kilku niezależnych resolverów, ponieważ zmiany mogą być przez pewien czas widoczne w różny sposób z powodu pamięci podręcznej DNS.

Przy analizie wiadomości pomocne jest wyświetlenie pełnych nagłówków. Należy odszukać wyniki uwierzytelniania, wpisy związane z SPF, DKIM i DMARC oraz informacje o domenach użytych podczas kontroli. Sam wygląd adresu nadawcy nie wystarcza do oceny, ponieważ może być wynikiem podszycia się pod znaną nazwę.

Należy także ograniczyć dostęp do kont i urządzeń, z których prowadzona jest wysyłka. DMARC pomaga ograniczyć skutki podszywania się pod domenę, ale nie zastępuje silnych haseł, uwierzytelniania wieloskładnikowego, aktualizacji oprogramowania ani kontroli uprawnień. Jeżeli konto nadawcy zostanie przejęte, wiadomości mogą pochodzić z prawidłowo uwierzytelnionego źródła, a problem wymaga wtedy działań związanych z bezpieczeństwem konta.

RFC 7489 i DMARC – kiedy zgłosić problem do serwisu komputerowego

Zgłoszenie do serwisu może być uzasadnione, gdy wiadomości wysyłane z własnej domeny regularnie trafiają do spamu, są odrzucane mimo poprawnych ustawień albo gdy raporty wskazują na nieznane źródła wysyłki. Warto przekazać pełne nagłówki przykładowych wiadomości, nazwę domeny, informacje o używanych usługach pocztowych oraz aktualne rekordy DNS. Ułatwia to odróżnienie problemu z uwierzytelnianiem od blokady wynikającej z reputacji adresu IP lub treści wiadomości.

Pomoc może być potrzebna także po przeniesieniu poczty do innego dostawcy, zmianie hostingu strony albo uruchomieniu nowego formularza kontaktowego. W takich sytuacjach należy sprawdzić, czy nowa usługa ma możliwość podpisywania wiadomości DKIM, czy korzysta z właściwej domeny oraz czy jej adresy zostały uwzględnione w przyjętym modelu wysyłki.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić analizę konfiguracji komputera i poczty związanej z problemami wynikającymi z rekordów DNS, SPF, DKIM lub DMARC. Przed rozpoczęciem prac powinno się ustalić zakres dostępu, przygotować przykładowe komunikaty o odrzuceniu oraz wskazać, które systemy mają prawo wysyłać wiadomości w imieniu domeny. Pozwala to przeprowadzić diagnostykę w sposób uporządkowany i ograniczyć ryzyko przypadkowego zablokowania prawidłowej korespondencji.