Jak skonfigurować MTA-STS: przewodnik krok po kroku z plikiem polityki i rekordami DNS

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) zmusza serwery, które wysyłają do Ciebie pocztę, do korzystania z TLS oraz do weryfikacji certyfikatu Twojego MX przed dostarczeniem wiadomości. Bez tego aktywny atakujący może usunąć szyfrowanie podczas uzgadniania połączenia SMTP i odczytać lub przekierować Twoją pocztę przychodzącą. Konfiguracja polega na opublikowaniu trzech elementów, które muszą być ze sobą zgodne: rekordu TXT _mta-sts, pliku polityki serwowanego przez HTTPS pod stałą ścieżką oraz dyrektyw mx, mode i max_age wewnątrz tego pliku. Ten przewodnik omawia wszystkie trzy, a następnie pokazuje, jak zweryfikować każdy element, zanim przełączysz się z trybu testowego na tryb wymuszania.

Co właściwie robi MTA-STS

SMTP zaprojektowano bez obowiązkowego szyfrowania. Gdy serwer wysyłający łączy się z Twoim MX, wydaje polecenie STARTTLS, aby uaktualnić sesję z tekstu jawnego do TLS. Problem w tym, że STARTTLS działa oportunistycznie: jeśli polecenie zostanie usunięte z połączenia lub certyfikat jest nieprawidłowy, większość nadawców po cichu wraca do tekstu jawnego i dostarcza wiadomość mimo wszystko. To właśnie ta rezygnacja jest luką, którą wykorzystuje atak typu man-in-the-middle.

MTA-STS zamyka tę lukę, pozwalając Ci opublikować politykę, która mówi: "dla mojej domeny TLS jest wymagany, a oto nazwy hostów MX, których certyfikatom powinieneś ufać". Serwer wysyłający, który obsługuje MTA-STS, pobiera Twoją politykę, buforuje ją i odmawia dostarczenia poczty przez połączenie nieszyfrowane lub nieuwierzytelnione. Google, Microsoft i Yahoo respektują te polityki w poczcie wychodzącej, więc zasięg jest realny, mimo że nie każdy nadawca jeszcze w tym uczestniczy.

Warto jasno określić zakres. MTA-STS chroni pocztę przychodzącą do Twojej domeny (pocztę, którą inni wysyłają do Ciebie). Nie robi nic dla wiadomości, które wysyłasz na zewnątrz, i nie jest mechanizmem uwierzytelniania takim jak SPF czy DKIM. Działa obok SPF, DKIM i DMARC, a nie zamiast nich.

Trzy współpracujące elementy

Kompletne wdrożenie ma dokładnie trzy komponenty i wszystkie trzy muszą być spójne:

1. Rekord DNS TXT pod adresem _mta-sts.<twojadomena>, który ogłasza politykę oraz identyfikator wersji.
2. Punkt końcowy HTTPS pod adresem https://mta-sts.<twojadomena>/.well-known/mta-sts.txt, który serwuje plik polityki.
3. Sama zawartość pliku polityki: dyrektywy version, mode, mx i max_age.

Rekord TXT informuje nadawców, że polityka istnieje i kiedy ostatnio się zmieniła. Plik mówi im, co ta polityka zawiera. Jeśli rekord wskazuje na politykę, której host HTTPS nie może udostępnić, nadawcy traktują to tak, jakby polityki w ogóle nie było, dlatego uruchomienie obu elementów ma znaczenie.

Krok 1: Opublikuj rekord TXT _mta-sts

Utwórz rekord TXT w subdomenie _mta-sts w Twojej domenie:

_mta-sts.example.com. IN TXT "v=STSv1; id=20260703000000Z"

Znacznik v=STSv1 jest stały. id to nieprzejrzysty ciąg znaków, który kontrolujesz, a jego jedynym zadaniem jest sygnalizowanie zmiany. Za każdym razem, gdy edytujesz plik polityki, zmień id na nową, unikalną wartość (znacznik czasu w formacie 20260703000000Z to powszechna konwencja). Nadawcy porównują zbuforowane id z bieżącym, aby zdecydować, czy pobrać plik ponownie. Jeśli nigdy nie zmienisz id, buforujący nadawcy będą używać starej polityki, dopóki ich bufor nie wygaśnie.

Krok 2: Serwuj plik polityki przez HTTPS

Polityka znajduje się pod jednym dokładnym adresem URL, w subdomenie o nazwie mta-sts:

https://mta-sts.example.com/.well-known/mta-sts.txt

Trzy wymagania są tu bezwzględne. Host musi odpowiadać przez HTTPS na porcie 443, certyfikat musi być prawidłowy i pasować do mta-sts.example.com, a plik musi być serwowany jako text/plain. Zwykłe przekierowanie HTTP nie wystarczy, a certyfikat samopodpisany lub wygasły unieważnia całą politykę. Możesz hostować to na małej statycznej stronie, w sieci CDN, w magazynie obiektowym z własną domeną lub u dedykowanego dostawcy MTA-STS. Liczy się zaufany certyfikat i stabilna ścieżka.

Będziesz też potrzebować rekordu DNS dla hosta mta-sts (rekordu A/AAAA lub CNAME wskazującego na miejsce, gdzie serwujesz plik). Jest to odrębny element od rekordu TXT _mta-sts i łatwo o nim zapomnieć.

Krok 3: Napisz dyrektywy pliku polityki

Plik to krótka lista wierszy klucz-wartość z zakończeniami LF lub CRLF:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mail.example.com
max_age: 604800

Oto, co kontroluje każda dyrektywa:

• version to zawsze STSv1.
• mode to testing, enforce lub none. W trybie testing nadawcy respektują politykę na potrzeby raportowania, ale nadal dostarczają pocztę, jeśli TLS zawiedzie, co pozwala bezpiecznie ją zweryfikować. W trybie enforce nadawcy odmawiają dostarczenia, gdy polityka nie jest spełniona. none wycofuje politykę.
• mx wymienia każdą nazwę hosta MX uprawnioną do odbierania Twojej poczty. Podawaj po jednej w wierszu. Symbole wieloznaczne takie jak *.mail.example.com dopasowują pojedynczą etykietę, więc używaj ich, gdy Twój dostawca stosuje nazwy MX zależne od regionu. Każda nazwa hosta w Twoich faktycznych rekordach MX musi być tu uwzględniona, w przeciwnym razie tryb enforce odrzuci prawidłową pocztę.
• max_age to czas, w sekundach, przez jaki nadawcy mogą buforować politykę. Typowe wartości mieszczą się w zakresie od 86400 (jeden dzień) do 604800 (jeden tydzień). Zacznij od niskiej wartości podczas testów, aby błędy szybko znikały, a następnie podnieś ją, gdy przejdziesz do trybu enforce.

Sprawdź swoją listę mx z aktualnymi rekordami MX. Jeśli Twoja poczta działa na Google Workspace, Microsoft 365 lub u innego dostawcy, skopiuj dokładne nazwy hostów MX ze swojej strefy zamiast zgadywać, ponieważ brakujący wpis staje się awarią dostarczania w chwili, gdy włączysz tryb enforce.

Zweryfikuj każdy element przed włączeniem trybu enforce

Nie przechodź od razu do mode: enforce. Najpierw uruchom wdrożenie w trybie testing i potwierdź, że wszystkie trzy elementy działają.

Sprawdź rekord TXT

Odpytaj rekord bezpośrednio i potwierdź, że id jest zgodne z Twoim zamiarem:

dig +short TXT _mta-sts.example.com

Powinieneś zobaczyć swój ciąg v=STSv1; id=... i nic zniekształconego.

Sprawdź plik polityki HTTPS

Pobierz plik i sprawdź zarówno certyfikat, jak i treść:

curl -v https://mta-sts.example.com/.well-known/mta-sts.txt

Zweryfikuj, że uzgadnianie TLS kończy się sukcesem z prawidłowym certyfikatem dla mta-sts.example.com, że odpowiedź to 200 OK z nagłówkiem Content-Type: text/plain oraz że treść odpowiada Twoim zamierzonym wartościom mode, mx i max_age. Ostrzeżenie o certyfikacie w tym miejscu jest najczęstszym powodem, dla którego polityka po cichu zawodzi.

Potwierdź pokrycie mx

Porównaj wiersze mx z Twoimi rzeczywistymi rekordami MX:

dig +short MX example.com

Każda zwrócona nazwa hosta musi być wymieniona w pliku polityki, jawnie lub poprzez pasujący symbol wieloznaczny. Przeprowadź pełne sprawdzenie za pomocą skanera SPFWise lub dowolnego walidatora MTA-STS, aby wychwycić niezgodności, które mógłbyś przeoczyć gołym okiem. Dopiero gdy wszystkie trzy kontrole przejdą pomyślnie i po kilku dniach w trybie testowym bez niespodzianek, zmień mode: testing na mode: enforce i zwiększ id w rekordzie TXT, aby nadawcy pobrali zmianę.

MTA-STS, TLS-RPT i DANE

Warto znać dwa powiązane rekordy. TLS-RPT (RFC 8460) to towarzyszący rekord TXT, który prosi raportujących nadawców o przesyłanie codziennych podsumowań sukcesów i niepowodzeń dostarczania TLS, dzięki czemu dowiadujesz się, że polityka działa, zanim włączysz tryb enforce. Minimalny rekord wygląda tak: _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com".

DANE to alternatywne podejście do wymuszania TLS w SMTP, wykorzystujące rekordy TLSA podpisane przez DNSSEC zamiast hostowanej polityki HTTPS. Oba rozwiązują ten sam problem przy użyciu różnych kotwic zaufania i wiele domen stosuje jednocześnie oba. Aby uzyskać bezpośrednie porównanie, kiedy wybrać które, zobacz MTA-STS a DANE. Jeśli Twoim celem jest szersze trafianie do skrzynek odbiorczych, połącz tę pracę z solidną polityką DMARC oraz wymaganiami nadawców Google i Yahoo, ponieważ bezpieczeństwo transportu i uwierzytelnianie razem są tym, czego oczekują nowoczesni dostawcy skrzynek pocztowych.

Najczęściej zadawane pytania

Czy potrzebuję MTA-STS, jeśli mam już SPF, DKIM i DMARC?

Tak, rozwiązują różne problemy. SPF, DKIM i DMARC uwierzytelniają, kto wysłał wiadomość, i powstrzymują podszywanie się. MTA-STS chroni warstwę transportową, aby poczta przychodząca nie mogła zostać obniżona do tekstu jawnego ani przekierowana podczas dostarczania. Stosuj oba rozwiązania.

Jaka jest różnica między trybem testing a enforce?

W trybie testing nadawcy oceniają Twoją politykę i zgłaszają niepowodzenia, ale nadal dostarczają pocztę, nawet gdy nie można nawiązać TLS, więc błędna konfiguracja nie może spowodować przerwy w działaniu. W trybie enforce nadawcy odmawiają dostarczenia, gdy połączenie nie spełnia polityki. Zawsze zaczynaj od trybu testing, zweryfikuj, a następnie przejdź do enforce.

Dlaczego mój plik polityki potrzebuje własnej subdomeny i certyfikatu?

Specyfikacja ustala lokalizację na https://mta-sts.<domena>/.well-known/mta-sts.txt właśnie po to, aby nadawcy mogli ją znaleźć bez zgadywania, i wymaga prawidłowego certyfikatu dla tego hosta mta-sts, aby atakujący nie mógł sfałszować polityki. Brak rekordu DNS dla subdomeny lub nieprawidłowy certyfikat sprawiają, że nadawcy całkowicie ignorują politykę.

Jak bezpiecznie zaktualizować lub usunąć politykę MTA-STS?

Aby zmienić politykę, edytuj plik, a następnie ustaw nowe id w rekordzie TXT _mta-sts, aby buforujący nadawcy pobrali ją ponownie. Aby wycofać MTA-STS, ustaw mode: none w pliku i zwiększ id, a potem pozostaw oba rekordy na miejscu, dopóki bufor każdego nadawcy (regulowany przez Twoje max_age) nie wygaśnie, zanim cokolwiek usuniesz.