Poczta, która należy do firmy: SPF, DKIM i DMARC bez czarnej skrzynki

Dlaczego pocztę tak trudno przenieść

Większość firm nie zostaje u dostawcy poczty dlatego, że kocha jego panel. Zostaje, bo przeprowadzka wydaje się ryzykowna.

Są dwa rodzaje uzależnienia. Pierwszy to dane: lata skrzynek, adresów wspólnych, aliasów, kalendarzy, kontaktów, faktur, podpisanych umów i tej jednej starej wiadomości, która nagle robi się ważna, gdy klient o nią zapyta. Skrzynka pocztowa jest w równym stopniu archiwum, co miejscem odbioru wiadomości. IMAP to standardowy protokół, który pozwala programom pocztowym odczytywać i przenosić dane skrzynki między serwerami; jego obecna specyfikacja to RFC 9051. W praktyce eksport nadal wymaga planu, bo skrzynki są duże, etykiety nie zawsze pasują jeden do jednego, a ludzie pracują także w czasie przenosin.

Drugi rodzaj uzależnienia to reputacja. Domena, z której od lat wychodzi zwykła firmowa poczta, ma historię. Zupełnie nowy serwer, błędny wpis DNS albo pośpieszne przełączenie mogą sprawić, że prawdziwa faktura zacznie wyglądać podejrzanie. Dlatego migracja poczty przypomina nie tyle zmianę programu, ile przenoszenie głównych drzwi firmy, gdy klienci dalej do nich pukają.

Serwery odbierające zadają o każdej wiadomości trzy pytania. Czy ten serwer może wysyłać pocztę z tej domeny? Czy wiadomość zmieniła się po drodze? Co zrobić, jeśli odpowiedzi są złe?

SPF: kto może wysyłać

SPF odpowiada na pierwsze pytanie. Właściciel domeny publikuje w DNS wpis z listą serwerów, które mogą wysyłać pocztę dla tej domeny. Gdy serwer odbierający dostaje wiadomość, porównuje serwer wysyłający z tą polityką. RFC 7208 opisuje SPF jako sposób, w jaki domeny upoważniają serwery, a odbiorcy mogą to upoważnienie sprawdzić.

Po ludzku: SPF to lista gości przy wejściu. Jeśli Twoja domena mówi, że pocztę mogą wysyłać tylko te serwery, przypadkowemu serwerowi gdzieś w internecie trudniej udawać Ciebie.

SPF ma ograniczenia. Sprawdza nadawcę technicznego używanego podczas doręczania, a nie adres widoczny dla człowieka w polu Od. Przekazywanie poczty dalej potrafi go zepsuć. Bez SPF odbiorcy mają jednak mniej dowodów, że Twoja wiadomość jest prawdziwa.

DKIM: czy wiadomość zmieniła się po drodze

DKIM odpowiada na drugie pytanie. Serwer wysyłający podpisuje części wiadomości kluczem prywatnym. Klucz publiczny leży w DNS. Serwer odbierający używa go, żeby sprawdzić, czy podpisane części nadal się zgadzają. RFC 6376 opisuje DKIM jako domenowy podpis kryptograficzny dla poczty.

Po ludzku: DKIM to plomba pokazująca naruszenie. Nie szyfruje wiadomości i nie dowodzi, że nadawca jest uczciwy. Dowodzi, że domena wskazana w podpisie wzięła odpowiedzialność za tę wiadomość, a podpisane części nie zostały potem zmienione.

To ma znaczenie przy fakturach, resetowaniu haseł, potwierdzeniach zamówień i zwykłej korespondencji z klientami. Jeśli dostawca kontroluje podpisywanie i klucze, uwierzytelnianie staje się kolejną rzeczą, której trzeba wierzyć, ale trudno ją samodzielnie sprawdzić.

DMARC: co zrobić, gdy testy nie przejdą

DMARC łączy SPF i DKIM z domeną widoczną w polu Od i mówi serwerom odbierającym, czego chce właściciel domeny, gdy testy się nie powiodą. Polityka DMARC może prosić o brak działania, odłożenie podejrzanej poczty do kwarantanny albo jej odrzucenie. DMARC po raz pierwszy opisano w RFC 7489 jako politykę i raportowanie oparte na zgodności SPF oraz DKIM. Ten dokument jest już nieaktualny, a zastąpiły go trzy specyfikacje ze ścieżki standardów: RFC 9989 opisuje samą politykę, RFC 9990 raporty zbiorcze, a RFC 9991 raporty o niepowodzeniach. Przed zmianą polityki produkcyjnej sprawdź aktualne specyfikacje.

Po ludzku: DMARC to firmowy regulamin. Mówi: jeśli wiadomość twierdzi, że jest z naszej domeny, ale uwierzytelnienie się nie zgadza, potraktuj ją tak i daj znać, co zobaczyłeś.

Raportowanie zamienia opowieści o uwierzytelnianiu w dowody. Widać, kto wysyła z Twojej domeny, co przechodzi, co odpada i kiedy można bezpiecznie zaostrzyć politykę.

Wdrożenie DMARC krok po kroku

RFC 9989 (rozdział 5.1) opisuje ścieżkę wdrożenia, jakiej oczekuje się od właściciela domeny. To sekwencja, nie jeden rekord publikowany raz na zawsze:

Najpierw opublikuj SPF i DKIM i upewnij się, że oba dają wynik pozytywny dla Twoich prawdziwych strumieni poczty.
Załóż skrzynkę na raporty zbiorcze, a potem opublikuj rekord DMARC z p=none i tagiem rua wskazującym tę skrzynkę. RFC 9989 nazywa to „trybem monitorowania” (Monitoring Mode): odbiorcy nic nie zmieniają w obsłudze Twojej poczty, ale zaczynają wysyłać raporty o tym, co widzieli — RFC zaleca odbiorcom robić to co najmniej raz na dobę.
Zbieraj i czytaj raporty. Uzasadnienie samego RFC: zaczynanie od p=none „wykorzystuje funkcję raportowania zbiorczego DMARC, a właściciel domeny używa raportów do audytu konfiguracji uwierzytelniania swoich strumieni poczty” — dzięki temu wyłapiesz zapomnianą usługę wysyłkową, zanim zaczniesz blokować pocztę.
Napraw to, co pokazują raporty, na przykład zewnętrzny serwis wysyłający pocztę w Twoim imieniu bez poprawnego dopasowania SPF lub DKIM.
Przejdź do egzekwowania (p=quarantine albo p=reject) dopiero, gdy masz pewność, że każdy prawdziwy strumień się uwierzytelnia. RFC otwarcie mówi, że to może potrwać: „może minąć wiele miesięcy konsumowania raportów zbiorczych DMARC, zanim właściciel domeny osiągnie pewność, że poprawnie uwierzytelnia całą swoją pocztę”.

Rekord w trybie monitorowania, wzięty wprost z przykładu w RFC 9989, załącznik B.2.1:

_dmarc  IN TXT ( "v=DMARC1; p=none; "
                 "rua=mailto:dmarc-feedback@example.com" )

Dwie uwagi o składni, przydatne przed edycją rekordu produkcyjnego: tagi oddziela się średnikiem ;, a nieznane tagi lub błędy składni na końcu rekordu są ignorowane, a nie odrzucają cały rekord — literówka w jednym tagu niekoniecznie unieważni resztę, ale też nie zrobi tego, co zamierzałeś.

Jeśli trafiłeś na starsze poradniki wspominające tag pct, który miał stopniowo zwiększać udział poczty objętej surowszą polityką (wartość procentowa), ten tag istniał w pierwotnym RFC 7489 i został usunięty w RFC 9989. Część jego zastosowań przejmuje tag t (testowy): przy t=y odbiorcy proszeni są o zastosowanie polityki o jeden poziom łagodniejszej niż opublikowana — rekord z reject jest traktowany jak quarantine, a quarantine jak none — dzięki czemu możesz obserwować raporty, zanim przejdziesz na pełne egzekwowanie.

SPF: `~all` kontra `-all` i limit 10 członów

Ostatni mechanizm w rekordzie SPF to zwykle all, a jego kwalifikator decyduje, co się dzieje z pocztą z serwerów spoza listy. Według RFC 7208:

~all (softfail): „słabe stwierdzenie… że serwer prawdopodobnie nie jest upoważniony” (rozdział 2.6.5). Odbiorcy „nie powinni (SHOULD NOT) odrzucać wiadomości wyłącznie na podstawie tego wyniku” (rozdział 8.5) — softfail to sygnał do baczniejszej kontroli, nie do blokady.
-all (fail): „jednoznaczne stwierdzenie, że klient nie jest upoważniony do używania tej domeny” (rozdział 2.6.4). Odbiorca odrzucający pocztę przy fail ma używać kodu SMTP 550 (rozdział 8.4).

Ostrożne podejście to zacząć od ~all, dopóki nie upewnisz się, że każdy prawdziwy nadawca jest na liście, a potem przejść na -all — ta sama logika „najpierw monitoruj, potem egzekwuj”, co przy wdrożeniu DMARC powyżej.

SPF ogranicza też, ile pracy DNS może wywołać jedno sprawdzenie, przy czym liczy nie zapytania, lecz człony rekordu: sprawdzenie może użyć najwyżej 10 członów odpytujących DNS, czyli mechanizmów include, a, mx, ptr, exists oraz modyfikatora redirect. Po przekroczeniu limitu sprawdzenie kończy się błędem permerror (rozdział 4.6.4). Pojedynczy człon może wywołać więcej niż jedno zapytanie, więc faktyczna liczba zapytań bywa większa niż dziesięć. Rekord SPF zbudowany z kilku wpisów include: (typowe, gdy korzystasz z więcej niż jednej usługi wysyłkowej) może przekroczyć ten limit, a nikt się o tym nie dowie, dopóki poczta nie zacznie odpadać.

Co zmienia własny serwer

Własna firmowa poczta oznacza, że domena, dane skrzynek, polityka DNS i kopie zapasowe są pod Twoją kontrolą.

Mailcow na infrastrukturze, którą kontrolujesz, trzyma skrzynki tam, gdzie zdecydujesz. Domena zostaje Twoja, a archiwum pozostaje przenośne przez standardowe protokoły pocztowe. Ustawienia są jawne, a nie schowane za etykietą „dostarczalność”. Klucz DKIM generuje Mailcow, a SPF, DKIM i DMARC to rekordy DNS, które Twoja firma publikuje u dostawcy domeny. Mailcow podpowiada ich treść; faktyczne zmiany wykonujesz Ty albo operator Twojej strefy DNS, a w podłączonej strefie Cloudflare panel publikuje je po Twojej akceptacji. Jeśli dostawca serwera przestanie pasować, serwer i dane można przenieść.

Poczta wymaga opieki. Wpisy DNS muszą być poprawne, klucze trzeba w razie potrzeby wymieniać, kopie sprawdzać, a reputację nadawcy obserwować. Ta powtarzalna praca należy do Ciebie: aktualizacje uruchamiasz sam i sam sprawdzasz rekordy.

Firmowa poczta powinna być nudna w najlepszym sensie: klienci mogą do Ciebie napisać, faktury docierają, stare wiadomości da się znaleźć, a żaden dostawca nie ma jedynej używalnej kopii archiwum.

principale.dev instaluje takie narzędzia open source na serwerze, który należy do Ciebie. Każda instalacja jest darmowa. Zobacz, jak to działa.