Czym jest MTA-STS? Konfiguracja właściwej polityki MTA STS

Powszechnie znanym standardem internetowym, który ułatwia poprawę bezpieczeństwa połączeń między serwerami SMTP (Simple Mail Transfer Protocol) jest SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS). MTA-STS rozwiązuje istniejące problemy w SMTP bezpieczeństwa poczty e-mail poprzez wymuszenie szyfrowania TLS w tranzycie. Szyfrowanie jest opcjonalne w SMTP, co oznacza, że wiadomości e-mail mogą być wysyłane w postaci zwykłego tekstu. MTA-STS umożliwia dostawcom usług pocztowych egzekwowanie Transport Layer Security (TLS) w celu zabezpieczenia połączeń SMTP, a także określenie, czy wysyłające serwery SMTP powinny odmawiać dostarczania wiadomości e-mail do hostów MX, które nie obsługują TLS z wiarygodnym certyfikatem serwera. Udowodniono, że skutecznie łagodzi ataki TLS downgrade i ataki Man-In-The-Middle (MITM).

Historia i pochodzenie MTA-STS 

W roku 1982 po raz pierwszy określono specyfikację SMTP, która nie zawierała żadnego mechanizmu zapewniającego bezpieczeństwo na poziomie transportu w celu zabezpieczenia komunikacji pomiędzy agentami transferu poczty. Jednak w 1999 roku do SMTP dodano polecenie STARTTLS, które z kolei wspierało szyfrowanie wiadomości e-mail pomiędzy serwerami, dając możliwość przekształcenia niezabezpieczonego połączenia w bezpieczne, szyfrowane za pomocą protokołu TLS.

W takim razie musisz się zastanawiać, czy SMTP zaadoptował STARTTLS do zabezpieczania połączeń między serwerami, dlaczego wymagana była zmiana na MTA-STS i co to w ogóle zrobiło. Przejdźmy do tego w kolejnych sekcjach tego bloga!

Uprość bezpieczeństwo z PowerDMARC!

Co to jest MTA-STS? (Mail Transfer Agent Strict Transport Security - Explained)

MTA-STS to skrót od Mail Transfer Agent - Strict Transport Security. Jest to standard bezpieczeństwa, który zapewnia bezpieczną transmisję wiadomości e-mail za pośrednictwem szyfrowanego połączenia SMTP. Skrót MTA oznacza Message Transfer Agent, czyli program do przesyłania wiadomości e-mail między komputerami. Skrót STS oznacza Strict Transport Security, który jest protokołem używanym do implementacji standardu. Agent transferu poczty (MTA) obsługujący MTA-STS lub bezpieczny agent transferu wiadomości (SMTA) działa zgodnie z tą specyfikacją i zapewnia bezpieczny kanał end-to-end do wysyłania wiadomości e-mail przez niezabezpieczone sieci.

Protokół MTA-STS pozwala klientowi SMTP zweryfikować tożsamość serwera i upewnić się, że nie łączy się on z oszustem, wymagając od serwera podania odcisku palca jego certyfikatu w trakcie rozmowy TLS. Klient następnie weryfikuje certyfikat z magazynem zaufania zawierającym certyfikaty znanych serwerów.

Wprowadzenie do MTA-STS Email Security 

MTA-STS został wprowadzony w celu wypełnienia luki w zabezpieczeniach podczas komunikacji SMTP. Jako standard bezpieczeństwa, MTA-STS zapewnia bezpieczną transmisję wiadomości e-mail przez szyfrowane połączenie SMTP.

Skrót MTA oznacza Message Transfer Agent, czyli program do przesyłania wiadomości e-mail między komputerami. Skrót STS oznacza Strict Transport Security, który jest protokołem używanym do implementacji standardu. Agent transferu poczty (MTA) lub bezpieczny agent transferu wiadomości (SMTA) obsługujący MTA-STS działa zgodnie z tą specyfikacją i zapewnia bezpieczny kanał end-to-end do wysyłania wiadomości e-mail przez niezabezpieczone sieci.

Protokół MTA-STS pozwala klientowi SMTP zweryfikować tożsamość serwera i upewnić się, że nie łączy się on z oszustem, wymagając od serwera podania odcisku palca jego certyfikatu w trakcie rozmowy TLS. Klient następnie weryfikuje certyfikat z magazynem zaufania zawierającym certyfikaty znanych serwerów.

Potrzeba przejścia na wymuszone szyfrowanie TLS

STARTTLS nie był doskonały i nie rozwiązał dwóch głównych problemów: po pierwsze, jest to środek opcjonalny, dlatego STARTTLS nie zapobiega atakom typu man-in-the-middle (MITM). Wynika to z faktu, że atakujący MITM może łatwo zmodyfikować połączenie i uniemożliwić aktualizację szyfrowania. Drugim problemem jest to, że nawet jeśli STARTTLS jest zaimplementowany, nie ma sposobu na uwierzytelnienie tożsamości serwera wysyłającego, ponieważ SMTP nie weryfikują certyfikatów.

Podczas gdy większość wychodzących wiadomości e-mail jest obecnie zabezpieczona za pomocą Transport Layer Security (TLS) szyfrowanie, standard branżowy przyjęty nawet w konsumenckiej poczcie e-mail, atakujący nadal mogą utrudniać i manipulować pocztą e-mail, nawet zanim zostanie ona zaszyfrowana. Ponieważ bezpieczeństwo musiało zostać zmodernizowane w SMTP, aby zapewnić jego wsteczną kompatybilność poprzez dodanie polecenia STARTTLS w celu zainicjowania szyfrowania TLS, w przypadku gdy klient nie obsługuje TLS, komunikacja powraca do czystego tekstu. W ten sposób wiadomości e-mail w tranzycie mogą paść ofiarą wszechobecnych ataków monitorujących, takich jak MITM, w których cyberprzestępcy mogą podsłuchiwać wiadomości oraz zmieniać i manipulować informacjami, zastępując lub usuwając polecenie szyfrowania (STARTTLS), powodując powrót komunikacji do zwykłego tekstu. Atakujący MITM może po prostu zastąpić STARTTLS bezużytecznym ciągiem znaków, którego klient nie jest w stanie zidentyfikować. Dlatego też klient z łatwością powraca do wysyłania wiadomości e-mail w postaci zwykłego tekstu. Jeśli nie uda się przesłać wiadomości e-mail za pośrednictwem bezpiecznego połączenia, dane mogą zostać naruszone, a nawet zmodyfikowane i zmanipulowane przez cyberprzestępcę.

W tym miejscu wkracza MTA-STS, rozwiązując ten problem, gwarantując bezpieczny transfer wiadomości e-mail oraz skutecznie ograniczając ataki MITM. MTA-STS wymusza przesyłanie wiadomości e-mail za pośrednictwem szyfrowanej ścieżki TLS, a w przypadku niemożności ustanowienia szyfrowanego połączenia wiadomość e-mail nie jest w ogóle dostarczana, zamiast tego jest dostarczana w postaci zwykłego tekstu. Ponadto serwery MTA przechowują pliki zasad MTA-STS, utrudniając atakującym przeprowadzenie ataku ataku spoofingu DNS. Głównym celem jest poprawa bezpieczeństwa na poziomie transportu podczas komunikacji SMTP i zapewnienie prywatności ruchu poczty elektronicznej. Ponadto szyfrowanie wiadomości przychodzących i wychodzących zwiększa bezpieczeństwo informacji, wykorzystując kryptografię do ochrony informacji elektronicznych.

Konfiguracja MTA-STS za pomocą PowerDMARC!

Jak działa MTA-STS?

Protokół MTA-STS jest wdrażany poprzez posiadanie rekordu DNS, który określa, że serwer pocztowy może pobrać plik polityki z określonej subdomeny. Ten plik zasad jest pobierany przez HTTPS i uwierzytelniany za pomocą certyfikatów, wraz z listą nazw serwerów pocztowych odbiorcy. Wdrożenie MTA-STS jest łatwiejsze po stronie odbiorcy w porównaniu do strony wysyłającej, ponieważ wymaga obsługi przez oprogramowanie serwera pocztowego. Podczas gdy niektóre serwery pocztowe obsługują MTA-STS, takie jak PostFixale nie wszystkie. MTA-STS pozwala serwerom wskazać, że obsługują TLS, co pozwoli im na zamknięcie (tj. niewysłanie wiadomości e-mail), jeśli negocjacja aktualizacji TLS nie zostanie przeprowadzona, uniemożliwiając w ten sposób przeprowadzenie ataku TLS downgrade.

Główni dostawcy usług pocztowych, tacy jak Microsoft, Oath i Google, obsługują protokół MTA-STS. Serwis Gmail firmy Google już niedawno wdrożył zasady MTA-STS. Protokół MTA-STS wyeliminował wady związane z bezpieczeństwem połączeń pocztowych, ułatwiając proces zabezpieczania połączeń i zapewniając dostępność dla obsługiwanych serwerów pocztowych.

Połączenia użytkowników z serwerami pocztowymi są zazwyczaj chronione i szyfrowane za pomocą protokołu TLS, jednak pomimo tego przed wdrożeniem MTA-STS istniał brak bezpieczeństwa w połączeniach między serwerami pocztowymi. Wraz ze wzrostem świadomości na temat bezpieczeństwa poczty elektronicznej w ostatnim czasie oraz wsparciem ze strony głównych dostawców poczty na całym świecie, organizacje coraz częściej wdrażają nowoczesne rozwiązania bezpieczeństwa i narzędzia AI w celu automatyzacji wykrywania zagrożeń i wzmocnienia infrastruktury poczty elektronicznej. Oczekuje się więc, że w najbliższej przyszłości większość połączeń serwerowych będzie szyfrowana. Ponadto MTA-STS skutecznie uniemożliwia cyberprzestępcom w sieciach odczytanie treści wiadomości e-mail.

Plik polityki MTA-STS

Plik zasad MTA-STS jest zwykłym plikiem konfiguracyjnym MTA-STS, który jest hostowany na serwerze internetowym domeny pod adresem URL HTTPS: Definiuje on zasady ustanawiania bezpiecznych połączeń między serwerami pocztowymi, wymuszania szyfrowania TLS i określania działań, które należy podjąć, jeśli nie można ustanowić bezpiecznego połączenia. 

https://mta-sts.<domain>//.well-known/mta-sts.txt

Struktura pliku polityki MTA-STS 

Przykład polityki MTA-STS

wersja: STSv1 

tryb: wymuszanie 

mx: mail.example.com 

mx: backupmail.example.com 

max_age: 86400

Wymagania wstępne dla wdrożenia MTA-STS

Przed rozpoczęciem konfiguracji MTA-STS należy wykonać następujące czynności: 

1. Zarejestrowana nazwa domeny 
2. Ważne certyfikaty TLS

• Certyfikaty TLS muszą być wydawane przez zaufany urząd certyfikacji.
• Certyfikaty muszą być aktualne i nie mogą wygasać.
• Powinien to być co najmniej TLS w wersji 1.2 lub wyższej. 

3. Rekord DNS TXT dla MTA-STS 
4. Serwer internetowy HTTPS 
5. Serwer pocztowy skonfigurowany do korzystania z TLS 
6. Nazwa hosta serwera pocztowego pasująca do wpisów w polu mx pliku zasad
7. Środowisko testowe lub hostowana usługa MTA-STS do monitorowania dzienników i wprowadzania zmian w razie potrzeby.

Przed wdrożeniem MTA-STS upewnij się, że Twoja domena ma solidną podstawę do uwierzytelniania poczty e-mail. Obejmuje to prawidłowo skonfigurowane rekordySPF i DKIM. Możesz zweryfikować swoją konfigurację SPF za pomocą naszego bezpłatnego narzędzia SPF Record Lookup, aby upewnić się, że nie ma żadnych błędów przed przystąpieniem do wdrożenia MTA-STS.

Kroki konfiguracji MTA-STS dla twojej domeny

Aby skonfigurować MTA-STS dla swojej domeny, możesz wykonać kroki pokazane poniżej: 

• Sprawdź, czy Twoja domena ma istniejącą konfigurację MTA-STS. Jeśli korzystasz z Google Workspace dla swoich wiadomości e-mail, możesz to łatwo zrobić za pomocą tego przewodnik.
• Utwórz i opublikuj politykę MTA-STS, skonfigurowaną oddzielnie dla każdej domeny. Plik zasad MTA-STS definiuje serwery poczty e-mail z obsługą MTA-STS używane przez tę domenę. 
• Po utworzeniu pliku zasad należy przesłać go na publiczny serwer WWW, do którego zdalne serwery będą miały łatwy dostęp 
• Na koniec utwórz i opublikuj rekord DNS MTA-STS (rekord TXT "_mta-sts"), aby poinstruować serwery odbierające, że wiadomości e-mail muszą być szyfrowane TLS, aby można je było uznać za autentyczne, i powinny mieć dostęp do skrzynki odbiorczej odbiorcy tylko wtedy, gdy to pierwsze jest prawdą

Po utworzeniu aktywnego pliku zasad zewnętrzne serwery pocztowe nie będą zezwalać na dostęp do poczty e-mail bez bezpiecznego połączenia. 

3 Tryby polityki MTA-STS: Brak, Testowanie i Wymuszanie

Trzy dostępne wartości dla trybów polityki MTA-STS są następujące: 

1. Brak: Ta zasada unieważnia konfigurację MTA-STS, ponieważ serwery zewnętrzne uznają protokół za nieaktywny dla domeny.
2. Testowanie: Podczas korzystania z tej polityki wiadomości e-mail przesyłane przez niezaszyfrowane połączenie nie będą odrzucane, zamiast tego przy włączonej funkcji TLS-RPT nadal będziesz otrzymywać raporty TLS dotyczące ścieżki dostarczania i zachowania wiadomości e-mail.
3. Siła: Wreszcie, gdy włączona jest polityka wymuszania, wiadomości e-mail przesyłane przez niezaszyfrowane połączenie SMTP będą odrzucane przez serwer.

MTA-STS zapewnia ochronę przed :

• Ataki na obniżenie ratingu
• Ataki typu Man-In-The-Middle (MITM)
• Rozwiązuje wiele problemów związanych z bezpieczeństwem SMTP, w tym wygasłe certyfikaty TLS, brak wsparcia dla bezpiecznych protokołów i certyfikaty, które nie są wydawane przez wiarygodne strony trzecie.

Raportowanie TLS: Monitorowanie luk w dostarczalności wiadomości e-mail po konfiguracji MTA-STS 

TLS-RPT (Transport Layer Security Reporting) to protokół umożliwiający właścicielom domen otrzymywanie szczegółowych raportów dotyczących błędów szyfrowania TLS w komunikacji e-mail. TLS Reporting działa w połączeniu z MTA-STS. Umożliwia raportowanie problemów z łącznością TLS, które są doświadczane przez aplikacje wysyłające wiadomości e-mail i wykrywanie błędnych konfiguracji. Umożliwia raportowanie problemów z dostarczaniem wiadomości e-mail, które mają miejsce, gdy wiadomość e-mail nie jest szyfrowana za pomocą TLS. We wrześniu 2018 r. standard ten został po raz pierwszy udokumentowany w dokumencie RFC 8460.

Kluczowe funkcje obejmują: 

• Raportowanie błędów: Zapewnia szczegółowe raporty dotyczące problemów z dostarczaniem lub awarii spowodowanych przez problemy TLS, takie jak wygasłe certyfikaty lub nieaktualne wersje TLS, a także awarie szyfrowania TLS. Po włączeniu TLS-RPT, zgodni agenci transferu poczty zaczną wysyłać raporty diagnostyczne dotyczące problemów z dostarczaniem wiadomości e-mail między komunikującymi się serwerami do wyznaczonej domeny e-mail. Raporty są zazwyczaj wysyłane raz dziennie, obejmując i przekazując zasady MTA-STS obserwowane przez nadawców, statystyki ruchu, a także informacje o awariach lub problemach w dostarczaniu wiadomości e-mail.
• Widoczność: Pomaga monitorować problemy związane z wdrożeniem protokołu MTA-STS i dostarczalnością wiadomości e-mail. TLS-RPT zapewnia lepszą widoczność wszystkich kanałów poczty elektronicznej, dzięki czemu można uzyskać lepszy wgląd we wszystko, co dzieje się w domenie, w tym w wiadomości, których dostarczenie nie powiodło się.
• Zwiększone bezpieczeństwo poczty e-mail: Usuwając błędy związane z nieudanymi negocjacjami szyfrowania TLS, można poprawić ogólną skuteczność konfiguracji MTA-STS, a tym samym skuteczniej zapobiegać cyberatakom. Co więcej, zapewnia on dogłębne raporty diagnostyczne, które pozwalają zidentyfikować i dotrzeć do źródła problemu z dostarczaniem wiadomości e-mail oraz naprawić go bez żadnych opóźnień.

Łatwe wdrażanie MTA-STS za pomocą PowerDMARC

MTA-STS wymaga serwera WWW obsługującego protokół HTTPS z ważnym certyfikatem, rekordów DNS i stałej konserwacji. Wdrożenie MTA-STS może być żmudnym zadaniem, które wiąże się ze złożonością podczas adopcji. Od generowania plików polityk i rekordów po utrzymanie serwera WWW i hostowanie certyfikatów, jest to długotrwały proces. PowerDMARC's Analizator DMARC znacznie ułatwia życie, obsługując to wszystko za Ciebie, całkowicie w tle. Gdy pomożemy Ci go skonfigurować, nigdy więcej nie będziesz musiał o nim myśleć.

Z pomocą PowerDMARC można wdrożyć Hosted MTA-STS w swojej organizacji bez kłopotów związanych z obsługą certyfikatów publicznych. Pomagamy:

• Publikuj rekordy DNS CNAME za pomocą kilku kliknięć
• Aktualizuj zasady i optymalizuj swój rekord jednym kliknięciem bez konieczności uzyskiwania dostępu do ustawień DNS.
• Zweryfikuj wersję polityki i walidację certyfikatu
• Wykrywanie błędów aplikacji polityki MTA-STS 
• Hostowanie pliku tekstowego zasad MTA-STS
• Przejęcie odpowiedzialności za utrzymanie serwera internetowego polityki i hosting certyfikatów.
• Szybsze wykrywanie awarii połączeń, udanych połączeń i problemów z połączeniami dzięki uproszczonym raportom
• Zapewnienie zgodności z RFC i wsparcie dla najnowszych standardów TLS

PowerDMARC sprawia, że proces wdrażania SMTP TLS Reporting (TLS-RPT) jest łatwy i szybki. Przekształcamy skomplikowane pliki JSON zawierające raporty o problemach z dostarczaniem wiadomości e-mail w proste, czytelne dokumenty (dla każdego wyniku i źródła wysyłania), które można łatwo zrozumieć.
Zarejestruj się już dziś, aby szybko wymusić wysyłanie wiadomości e-mail do Twojej domeny za pośrednictwem połączenia szyfrowanego TLS i zabezpieczyć połączenie przed atakami MITM i innymi cyberatakami.

"`

• O
• Latest Posts

Maitham Al Lawati

Ekspert ds. cyberbezpieczeństwa, CEO w PowerDMARC

Maitham jest przedsiębiorcą technologicznym, ekspertem ds. cyberbezpieczeństwa, dyrektorem generalnym i założycielem PowerDMARC z ponad 15-letnim doświadczeniem w branży. Maitham posiada tytuł Global MBA Uniwersytetu w Manchesterze oraz różne certyfikaty zawodowe, w tym CISSP, CISM, CRISC i ISC2 CCSP.

Najnowsze posty autorstwa Maitham Al Lawati (zobacz wszystkie)

• Statystyki dotyczące phishingu e-mailowego i DMARC: trendy w zakresie bezpieczeństwa poczty elektronicznej w 2026 r. – 6 stycznia 2026 r.
• Jak naprawić błąd „Nie znaleziono rekordu SPF” w 2026 r. – 3 stycznia 2026 r.
• SPF Permerror: Jak naprawić zbyt dużą liczbę wyszukiwań DNS – 24 grudnia 2025 r.