Jak skonfigurować MTA-STS i TLS-RPT: zapobieganie przechwytywaniu wiadomości e-mail

Miliardy wiadomości e-mail przesyłanych jest codziennie przez Internet, a znaczna część z nich nadal nie jest szyfrowana. Już sama skala tego zjawiska sprawia, że wiadomości e-mail są jednym z najbardziej atrakcyjnych celów przechwytywania, gdzie wiadomości mogą być czytane lub zmieniane podczas przesyłania bez wiedzy nadawcy lub odbiorcy.

Słaby punkt tkwi w sposobie dostarczania wiadomości e-mail. Protokół SMTP opiera się na szyfrowaniu oportunistycznym, które pozwala atakującym na usunięcie lub manipulowanie poleceniem STARTTLS i wymuszenie przejścia połączenia na tryb zwykłego tekstu. Takie ataki typu SMTP downgrade otwierają furtkę do przechwytywania typu man-in-the-middle, umożliwiając atakującym monitorowanie ruchu, przechwytywanie poufnych treści lub przekierowywanie wiadomości przez serwery, które kontrolują.

Skontaktuj się z nami Zarezerwuj demo

Spis treści

    1. Agent transferu poczty - ścisłe bezpieczeństwo transportu (MTA-STS)
    2. Zapewnienie szyfrowania za pomocą MTA-STS
    3. Anatomia ataku MITM
    4. Plik polityki MTA-STS
    5. Jak opublikować plik zasad MTA-STS
    6. Rekord DNS MTA-STS
    7. Konfiguracja MTA-STS dla Twojej domeny
    8. CWyzwania związane z ręcznym wdrażaniem MTA-STS
    9. Jak przetestować i zweryfikować konfigurację MTA-STS
    10. Usługi MTA-STS świadczone przez PowerDMARC
    11. Raportowanie SMTP TLS (TLS-RPT)
    12. Zabezpieczanie transportu poczty elektronicznej za pomocą MTA-STS
    13. Najczęściej zadawane pytania

Mail Transfer Agent-Strict Transport Security (MTA-STS) wypełnia tę lukę, wymagając szyfrowanych połączeń TLS między serwerami wysyłającymi i odbierającymi pocztę oraz odrzucając dostarczanie wiadomości, gdy nie można ustanowić bezpiecznego kanału. Zamiast liczyć na to, że szyfrowanie zostanie zastosowane, MTA-STS egzekwuje jego stosowanie, co sprawia, że jest ono niezbędne dla organizacji, które chcą wdrożyć MTA-STS jako część swojej strategii bezpieczeństwa poczty elektronicznej.

szyfrowanie tls

Agent transferu poczty - ścisłe bezpieczeństwo transportu (MTA-STS)

MTA-STS, podobnie jak sugeruje nazwa, jest protokołem umożliwiającym szyfrowany transport wiadomości między dwoma serwerami pocztowymi SMTP. MTA-STS określa serwerom wysyłającym, że wiadomości e-mail powinny być wysyłane wyłącznie za pośrednictwem szyfrowanego połączenia TLS i nie powinny być dostarczane w ogóle, jeśli nie zostanie nawiązane bezpieczne połączenie za pomocą polecenia STARTTLS. Poprzez zwiększenie bezpieczeństwa wiadomości e-mail w trakcie przesyłania, MTA-STS pomaga w ograniczaniu ataków typu „man-in-the-middle” (MITM), takich jak ataki typu SMTP downgrade i ataki typu DNS spoofing.

Czytaj więcej

Zapewnienie szyfrowania za pomocą MTA-STS

Wiadomości e-mail są dostarczane między serwerami za pomocą protokołu SMTP, który obsługuje szyfrowanie, ale domyślnie nie wymaga go. Stwarza to lukę, w wyniku której wiadomości mogą być nadal przesyłane bez ochrony. MTA-STS wypełnia tę lukę, sprawiając, że szyfrowane dostarczanie wiadomości staje się wymogiem, a nie opcją.

Aby zrozumieć, jak działa szyfrowanie podczas dostarczania wiadomości e-mail, rozważmy serwer pocztowy wysyłający wiadomość na adres [email protected]. Wysyłający agent transferu poczty (MTA) najpierw wykonuje zapytanie DNS w celu pobrania rekordów MX dla powerdmarc.com, identyfikując serwery pocztowe odpowiedzialne za odbiór wiadomości. Następnie wysyłający MTA łączy się z jednym z tych serwerów i sprawdza, czy obsługuje on szyfrowanie TLS, używając polecenia STARTTLS. Jeśli TLS jest dostępne, wiadomość e-mail jest wysyłana przez szyfrowane połączenie. Jeśli nie jest, serwer wysyłający nie może nawiązać bezpiecznego połączenia i bez wymuszenia może powrócić do wysyłania wiadomości w postaci zwykłego tekstu.

MTA-STS zmienia to zachowanie dostarczania, egzekwując surowe wymagania bezpieczeństwa podczas komunikacji między serwerami:

MTA-STS nakazuje serwerom pocztowym dostarczanie wiadomości wyłącznie za pośrednictwem połączenia szyfrowanego protokołem TLS. Jeśli nie można ustanowić szyfrowania, wiadomość nie jest dostarczana. Eliminuje to ciche przechodzenie na tekst jawny, które umożliwia przechwycenie wiadomości.

Serwer poczty odbiorczej musi przedstawić ważny certyfikat TLS, a nazwa domeny na tym certyfikacie musi być zgodna z domeną zdefiniowaną w zasadach MTA-STS. Dzięki temu serwer wysyłający komunikuje się z właściwym odbiorcą, a nie z fałszywym hostem.

Polityki MTA-STS są pobierane przez protokół HTTPS z bezpiecznego serwera internetowego. Pobieranie polityki przez szyfrowany i uwierzytelniony kanał uniemożliwia atakującym modyfikowanie lub fałszowanie instrukcji polityki podczas przesyłania.

Dzięki wymuszaniu szyfrowania i sprawdzaniu zarówno certyfikatów, jak i instrukcji dotyczących zasad, MTA-STS blokuje ataki typu SMTP downgrade, które polegają na usuwaniu lub zmianie polecenia STARTTLS. Serwery wysyłające nie akceptują już niebezpiecznych rozwiązań zastępczych, gdy powinno istnieć bezpieczne połączenie.

usługi hostowane mta sts
hostowany MTA STS

MTA-STS jest wdrażany poprzez opublikowanie rekordu DNS, który kieruje serwery pocztowe wysyłające wiadomości do pobrania pliku zasad z wyznaczonej subdomeny. Dostęp do pliku zasad odbywa się za pośrednictwem protokołu HTTPS, jest on weryfikowany przy użyciu certyfikatów TLS i zawiera zatwierdzone nazwy hostów serwerów pocztowych odbiorców. Protokół nakazuje serwerom SMTP wysyłającym wiadomości wymaganie szyfrowanego połączenia i sprawdzanie, czy domena wymieniona w certyfikacie TLS jest zgodna z domeną zdefiniowaną w pliku zasad. Jeśli protokół MTA-STS jest egzekwowany, w przypadku gdy nie można wynegocjować szyfrowanego kanału, wiadomość nie jest w ogóle dostarczana.

Anatomia ataku MITM

Zasadniczo, atak MITM ma miejsce, gdy osoba atakująca zastępuje lub usuwa komendę STARTTLS, aby zabezpieczone połączenie powróciło do niezabezpieczonego, bez szyfrowania TLS. Jest to określane jako atak typu downgrade. Po pomyślnym przeprowadzeniu ataku downgrade, atakujący może bez przeszkód uzyskać dostęp i przeglądać zawartość wiadomości e-mail.

Atakujący MITM może również podmienić rekordy MX w odpowiedzi na zapytanie DNS na serwer pocztowy, do którego ma dostęp i nad którym sprawuje kontrolę. W takim przypadku agent pocztowy dostarcza wiadomość e-mail na serwer atakującego, umożliwiając mu dostęp do treści wiadomości i manipulowanie nią. Następnie e-mail może zostać przekierowany na serwer odbiorcy bez wykrycia. Jest to tak zwany atak DNS spoofing.

Atak na obniżenie jakości SMTP

Znaki ostrzegawcze

Ataki MITM często przebiegają w sposób niezauważalny, ale pewne wzorce mogą sygnalizować, że coś jest nie tak podczas dostarczania wiadomości e-mail. Jednym z częstych sygnałów ostrzegawczych są nieoczekiwane błędy dostarczania lub opóźnienia podczas komunikacji z określonymi domenami, zwłaszcza gdy domeny te wcześniej akceptowały wiadomości bez problemów. Nagły wzrost liczby błędów negocjacji TLS, powrót do połączeń niezaszyfrowanych lub powtarzające się błędy STARTTLS mogą również wskazywać na zakłócenia podczas transmisji.

Kolejnym wskaźnikiem jest niekonsekwentne zachowanie routingu poczty. E-maile mogą wydawać się przechodzić przez nieznane serwery lub logi mogą wykazywać połączenia z hostami, które nie odpowiadają opublikowanym rekordom MX zamierzonego odbiorcy. W bardziej zaawansowanych przypadkach wiadomości docierają zmienione, skrócone lub przekazane przez systemy pośredniczące bez jasnego wyjaśnienia.

Wykrywanie w dużym stopniu opiera się na widoczności. Monitorowanie logów połączeń SMTP pomaga zidentyfikować powtarzające się błędy szyfrowania lub niezgodności certyfikatów. TLS-RPT dodaje kolejną warstwę, dostarczając raporty w przypadku niepowodzenia serwerów w nawiązaniu bezpiecznych połączeń TLS, sygnalizując problemy, takie jak próby obniżenia poziomu zabezpieczeń, nieprawidłowe certyfikaty lub błędy w egzekwowaniu zasad. 

Wszystkie te sygnały pomagają wykryć aktywność MITM, która w przeciwnym razie pozostałaby niewykryta podczas normalnego przepływu wiadomości e-mail.

Plik polityki MTA-STS

Plik polityki MTA-STS jest w zasadzie prostym plikiem tekstowym, który wygląda następująco:

wersja: STSv1
tryb: enforce
mx: mx1.powerdmarc.com
mx: mx2.powerdmarc.com
mx: mx3.powerdmarc.com
max_age: 604800

Uwaga: Pole wersja musi być zawarte na początku pliku tekstowego, podczas gdy inne pola mogą być włączone w dowolnej kolejności.

Plik zasad wykorzystuje pary klucz-wartość, przy czym każda wartość jest zakodowana w osobnym wierszu pliku tekstowego, jak pokazano powyżej. Rozmiar tego pliku może wynosić do 64 KB. Nazwa pliku zasad musi brzmieć mta-sts.txt. Pliki zasad muszą być aktualizowane za każdym razem, gdy dodajesz lub zmieniasz serwery pocztowe w swojej domenie.

Uwaga: Ustawienie MTA-STS w trybie wymuszania może spowodować, że niektóre emaile nie zostaną do Ciebie dostarczone. Dlatego zaleca się ustawienie polityki w trybie testowym i wybranie niskiego max_age, aby upewnić się, że wszystko działa poprawnie przed przejściem do trybu wymuszania. Zalecamy również ustawienie TLS-RPT dla polityki w trybie testowym, aby otrzymywać powiadomienia w przypadku, gdy emaile są wysyłane w plaintext. 

MTA-STS-Policy

Jak opublikować plik zasad MTA-STS

Aby opublikować plik polityki MTA-STS, serwer WWW, który hostuje plik musi:

  • Obsługa HTTPS/SSL

    Plik polityki musi być udostępniany za pośrednictwem serwera WWW obsługującego protokół HTTPS, aby zapewnić bezpieczne pobieranie go przez serwery pocztowe.

  • Użyj certyfikatu wydanego przez zaufany urząd certyfikacji.

    Certyfikat serwera musi być podpisany i zatwierdzony przez zewnętrzny urząd certyfikacji, aby wysyłające serwery MTA mogły uwierzytelnić źródło polityki.

  • Umieść plik w dedykowanej subdomenie mta-sts.

    Należy skonfigurować publiczny serwer internetowy z subdomeną mta-sts dodaną do domeny, która jest używana wyłącznie do publikowania zasad MTA-STS.

  • Umieść plik polityki w wymaganym katalogu.

    Plik polityki musi mieć nazwę mta-sts.txt i być opublikowany w katalogu .well-known w subdomenie mta-sts.

  • Upewnij się, że plik zasad jest publicznie dostępny pod prawidłowym adresem URL.

    Wysyłające MTA muszą mieć możliwość pobrania pliku z lokalizacji o formacie
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt bez uwierzytelniania lub przekierowań.

hostowany MTA STS

Rekord DNS MTA-STS

Rekord DNS TXT dla MTA-STS jest publikowany w DNS Twojej domeny, aby określić, że Twoja domena obsługuje protokół MTA-STS oraz aby zasygnalizować odświeżenie zbuforowanych wartości w MTA w przypadku zmiany polityki. Rekord DNS MTA-STS jest umieszczany w subdomenie _mta-sts jak w: _mta-sts.powerdmarc.com. Rekord TXT musi zaczynać się od v=STSv1, a wartość "id" wartość może zawierać do 32 znaków alfanumerycznych, zawartych w następujący sposób:

 v=STSv1; id=30271001S00T000;

Uwaga: Wartość id rekordu TXT musi być aktualizowana do nowej wartości przy każdorazowym wprowadzaniu zmian w polityce. 

Rekord DNS MTA-STS jest używany do: 

  • Określ wsparcie dla MTA-STS dla domeny
  • Sygnalizowanie MTA do ponownego pobrania polityki przez HTTPS w przypadku zmiany polityki

Zwróć uwagę, że dzięki rekordowi DNS MTA-STS TXT, plik z polityką może być przechowywany przez MTA przez dłuższy czas bez konieczności ponownego pobierania polityki, chyba że została ona zmieniona, jednocześnie nadal wykonując zapytanie DNS za każdym razem, gdy odebrany zostanie email dla danej domeny.

Konfiguracja MTA-STS dla Twojej domeny

Aby włączyć MTA-STS dla swojej domeny należy:

  • Dodaj rekord DNS typu cname pod adresem mta-sts.example.comskierowany na serwer WWW z obsługą HTTPS, który hostuje plik polityki MTA-STS.

  • Dodaj rekord DNS typu txt lub cname pod adresem _mta-sts.example.com który określa wsparcie dla MTA-STS dla Twojej domeny.

  • Skonfiguruj serwer WWW z obsługą HTTPS i ważnym certyfikatem dla swojej domeny.

  • Włącz raportowanie SMTP TLS dla swojej domeny, aby wykryć problemy w dostarczaniu wiadomości e-mail spowodowane błędami w szyfrowaniu TLS.

ikona wyszukiwania rekordów spf powerdmarc

Wyzwania związane z ręcznym wdrażaniem MTA-STS

Ręczne wdrożenie MTA-STS wymaga czegoś więcej niż tylko opublikowania pojedynczego rekordu DNS. Wymaga koordynacji infrastruktury internetowej, certyfikatów, zasad i bieżącej konserwacji, co może stanowić pewne wyzwanie, jeśli nie zostanie odpowiednio zarządzane.

  • Wymóg posiadania serwera internetowego obsługującego protokół HTTPS

    Polityki MTA-STS muszą być hostowane na publicznie dostępnym serwerze HTTPS z ważnym certyfikatem TLS. Wymaga to zapewnienia infrastruktury, prawidłowej konfiguracji TLS, terminowego odnawiania certyfikatów i zapewnienia wysokiej dostępności.

    Rozwiązanie: Organizacje dysponujące ograniczoną infrastrukturą internetową mogą zmniejszyć złożoność poprzez wykorzystanie hostowanej usługi MTA-STS, która automatycznie zarządza serwerami i certyfikatami.

  • Bieżąca obsługa dokumentacji polityki

    Każda zmiana konfiguracji serwera pocztowego wymaga aktualizacji pliku zasad MTA-STS. Jeśli plik jest nieaktualny, po włączeniu egzekwowania zasad może dojść do niepowodzenia dostarczenia legalnych wiadomości e-mail.

    Rozwiązanie: Scentralizowane zarządzanie polityką lub zautomatyzowane narzędzia pomagają zapewnić natychmiastowe i dokładne stosowanie aktualizacji.

  • Aktualizacje rekordów DNS i kontrola wersji

    Rekord MTA-STS TXT musi być aktualizowany o nową wartość identyfikatora za każdym razem, gdy zmienia się polityka. Brak aktualizacji lub nieprawidłowe aktualizacje mogą opóźnić odświeżenie polityki i spowodować niespójne egzekwowanie.

    Rozwiązanie: Automatyzacja zmniejsza ryzyko błędu ludzkiego i zapewnia zgodność rekordów DNS ze zmianami zasad.

  • Ograniczona widoczność niepowodzeń dostaw

    Bez TLS-RPT problemy związane z szyfrowaniem mogą pozostać niewykryte. Nawet przy włączonej funkcji TLS-RPT interpretacja surowych raportów JSON może być trudna bez specjalistycznej wiedzy.

    Rozwiązanie: Platformy raportujące, które analizują i wizualizują raporty TLS, ułatwiają wykrywanie awarii i szybkie reagowanie.

  • Wyższe koszty operacyjne i nakłady związane z koordynacją

    Ręczne wdrażanie wymaga koordynacji między zespołami ds. DNS, poczty elektronicznej i bezpieczeństwa, co zwiększa ryzyko błędnej konfiguracji i opóźnień.

    Rozwiązanie: Zespoły powinny ocenić, czy dysponują czasem i wiedzą specjalistyczną niezbędną do długoterminowego utrzymania MTA-STS, czy też zarządzane podejście lepiej odpowiada ich priorytetom operacyjnym.

Jak przetestować i zweryfikować konfigurację MTA-STS

Testowanie jest kluczowym etapem przed przełączeniem polityki MTA-STS w tryb egzekwowania. Po włączeniu egzekwowania serwery wysyłające otrzymują polecenie odrzucania dostarczania wiadomości e-mail, jeśli nie można nawiązać bezpiecznego połączenia TLS. Bez odpowiedniej walidacji błędy konfiguracji mogą prowadzić do niezamierzonej utraty wiadomości, dlatego dokładne testowanie jest niezbędne do utrzymania niezawodnego dostarczania wiadomości e-mail.

  • Sprawdzanie propagacji DNS

    Po opublikowaniu rekordu MTA-STS TXT i powiązanych wpisów DNS sprawdź, czy są one poprawnie rozpoznawane przez publiczne serwery DNS. Niekompletna lub opóźniona propagacja może spowodować, że serwery wysyłające będą opierać się na nieaktualnych lub buforowanych zasadach, co spowoduje niespójne działanie podczas dostarczania.

  • Dostępność plików polityki

    Sprawdź, czy plik zasad MTA-STS jest dostępny przez protokół HTTPS w oczekiwanej lokalizacji w subdomenie mta-sts. Plik powinien być dostępny bez przekierowań, wymagań dotyczących uwierzytelniania lub błędów certyfikatu. Każda przerwa w dostępie może uniemożliwić serwerom wysyłającym pobranie zasad.

  • Weryfikacja obsługi protokołu TLS

    Sprawdź, czy wszystkie hosty MX wymienione w zasadach obsługują protokół TLS i posiadają ważne certyfikaty zgodne z wymaganiami zasad. Pomyślne wynegocjowanie protokołu TLS gwarantuje, że po włączeniu egzekwowania zasad będzie można konsekwentnie nawiązywać szyfrowane połączenia.

Usługi MTA-STS świadczone przez PowerDMARC

PowerDMARC ułatwi Ci życie, ponieważ zajmie się tym wszystkim za Ciebie, całkowicie w tle. Gdy pomożemy Ci to skonfigurować, już nigdy więcej nie będziesz musiał o tym myśleć.

  • Pomożemy Ci opublikować Twoje rekordy cname za pomocą zaledwie kilku kliknięć

  • Bierzemy na siebie odpowiedzialność za utrzymanie serwera www i hosting certyfikatów

  • Dzięki naszym hostowanym usługom MTA-STS, wdrożenie po Twojej stronie jest zredukowane do opublikowania kilku rekordów DNS.

  • Zmiany w polityce MTA-STS można wprowadzać natychmiastowo i z łatwością, poprzez pulpit PowerDMARC, bez konieczności ręcznego wprowadzania zmian w DNS.

  • Hostowane usługi MTA-STS firmy PowerDMARC są zgodne z RFC i obsługują najnowsze standardy TLS.

  • Od generowania certyfikatów i pliku polityki MTA-STS do egzekwowania polityki, pomagamy Ci uniknąć ogromnych zawiłości związanych z przyjęciem protokołu.

Raportowanie SMTP TLS (TLS-RPT)

Aby połączenie między dwoma komunikującymi się serwerami SMTP było bezpieczniejsze i szyfrowane za pomocą protokołu TLS, wprowadzono protokół MTA-STS, który wymusza szyfrowanie i zapobiega dostarczaniu wiadomości e-mail w postaci zwykłego tekstu, gdy nie można ustanowić bezpiecznego połączenia. Jednak jeden problem pozostaje nierozwiązany: jak powiadomić właścicieli domen, gdy serwery zdalne doświadczają problemów z dostarczaniem wiadomości e-mail spowodowanych awariami TLS. W tym miejscu do gry wkracza TLS-RPT, uzupełniając MTA-STS poprzez dostarczanie raportów diagnostycznych, które wspierają monitorowanie i rozwiązywanie problemów związanych z komunikacją serwerów, takich jak wygasłe certyfikaty TLS, nieprawidłowe konfiguracje serwerów pocztowych lub nieudane negocjacje TLS.

Raporty TLS pomagają wykrywać i reagować na problemy w dostarczaniu wiadomości email poprzez mechanizm raportowania w postaci plików JSON. Te pliki JSON mogą być skomplikowane i nie do rozszyfrowania dla osoby nietechnicznej.

PowerDMARC pomaga uprościć pliki JSON, tworząc proste, zrozumiałe i czytelne dokumenty z wykresami i tabelami dla Twojej wygody. Raporty diagnostyczne dla Twojej domeny są również wyświetlane w dwóch formatach na pulpicie nawigacyjnym PowerDMARC:według wyników i według źródła wysyłania.

 

powerdmarc tls rpt

Czym zajmuje się TLS-RPT

TLS-RPT służy do zgłaszania błędów dostarczania wiadomości e-mail związanych z szyfrowaniem TLS między serwerami pocztowymi. Jego głównym celem jest zapewnienie właścicielom domen wglądu w sytuacje, w których wiadomości nie mogą być dostarczane w bezpieczny sposób, pomagając w identyfikacji problemów, które w przeciwnym razie pozostałyby niewykryte podczas normalnej komunikacji SMTP.

Dzięki tym raportom TLS-RPT pomaga zidentyfikować problemy, takie jak nieudane negocjacje TLS między serwerami wysyłającymi i odbierającymi, wygasłe lub nieprawidłowe certyfikaty TLS oraz błędy konfiguracji po obu stronach wymiany poczty. Ta wiedza pozwala administratorom dokładnie określić, gdzie dochodzi do awarii szyfrowania, i podjąć działania naprawcze.

Raporty TLS-RPT są generowane i wysyłane przez zgodne agenty transferu poczty, zazwyczaj codziennie, zapewniając stały wgląd w stan bezpieczeństwa dostarczania wiadomości e-mail.

wykresy json

Jak to włączyć

TLS-RPT można włączyć, publikując rekord DNS TXT w wymaganej lokalizacji _smtp._tls dla swojej domeny. Rekord ten sygnalizuje obsługę raportowania TLS i określa miejsce docelowe, do którego powinny być dostarczane raporty diagnostyczne.

Rekord TXT definiuje jeden lub więcej adresów raportowania, zazwyczaj adresy e-mail lub punkty końcowe HTTPS, które zgodne serwery pocztowe wykorzystują do wysyłania danych TLS-RPT. Po utworzeniu rekordu raportowanie rozpoczyna się automatycznie, bez konieczności wprowadzania zmian w działaniu serwera pocztowego.

TLS-RPT można skonfigurować ręcznie, dodając rekord TXT bezpośrednio do DNS lub za pośrednictwem platform, które zapewniają konfigurację opartą na interfejsie użytkownika. Korzystanie z zarządzanego interfejsu upraszcza wdrażanie, obsługując tworzenie i walidację rekordów, zmniejszając ryzyko błędów składniowych lub nieprawidłowej konfiguracji.

Czytaj więcej

Zabezpieczanie transportu poczty elektronicznej za pomocą MTA-STS

Poczta elektroniczna pozostaje kluczowym kanałem komunikacji, ale bez wymuszonego szyfrowania jest podatna na ataki typu downgrade i MITM, które mogą ujawnić treść wiadomości lub zakłócić jej dostarczenie. Ochrona poczty elektronicznej podczas przesyłania ma zasadnicze znaczenie dla zachowania poufności i utrzymania zaufania między serwerami wysyłającymi i odbierającymi pocztę.

MTA-STS wzmacnia transport poczty elektronicznej, wymagając szyfrowania TLS i odrzucając dostarczanie wiadomości, gdy nie można ustanowić bezpiecznego połączenia. Eliminując możliwość przejścia na niezaszyfrowaną komunikację, pomaga zapewnić, że wiadomości są dostarczane wyłącznie za pośrednictwem uwierzytelnionych i chronionych kanałów, poprawiając spójność i niezawodność wymiany danych między serwerami.

Pomyślne wdrożenie protokołu MTA-STS zależy od starannego przygotowania. Należy dokładnie skonfigurować zasady, zweryfikować infrastrukturę pomocniczą, a po przeprowadzeniu dokładnych testów stopniowo wprowadzać egzekwowanie zasad. Pominięcie tych kroków może skutkować niezamierzonymi błędami dostarczania, zwłaszcza gdy zasady są zbyt szybko przechodzą w tryb egzekwowania.

Przed włączeniem egzekwowania organizacje powinny dokonać przeglądu aktualnego stanu bezpieczeństwa poczty elektronicznej, potwierdzić gotowość TLS na wszystkich serwerach pocztowych oraz upewnić się, że pliki DNS i pliki zasad są prawidłowo opublikowane. Bieżące monitorowanie i okresowa weryfikacja pozostają ważne w miarę upływu czasu, ponieważ konfiguracje serwerów ulegają zmianom, a certyfikaty wygasają, co pomaga zapewnić, że zasady MTA-STS nadal skutecznie chronią dostarczanie poczty elektronicznej.

Najczęściej zadawane pytania

Panel kontrolny PowerDMARC pozwala automatycznie skonfigurować MTA-STS i TLS-RPT dla Twojej domeny poprzez opublikowanie tylko trzech rekordów CNAME w DNS domeny. Od hostingu plików polityki MTAS-STS i certyfikatów do utrzymania serwera WWW, dbamy o to wszystko w tle, bez konieczności dokonywania jakichkolwiek zmian w DNS. Wdrożenie MTA-STS z Twojej strony z PowerDMARC jest zredukowane do zaledwie kilku kliknięć.

Możesz wdrożyć i zarządzać MTA-STS dla wszystkich swoich domen z konta PowerDMARC, za pomocą jednej szyby. W przypadku, gdy któraś z tych domen korzysta z serwerów pocztowych, które nie obsługują STARTTLS, będzie to widoczne w raportach TLS, pod warunkiem, że masz włączony TLS-RPT dla tych domen.

Zawsze zaleca się ustawienie trybu polityki MTA-STS na testowanie podczas początkowych faz wdrożenia, tak aby można było monitorować aktywność i uzyskać wgląd w swój ekosystem emailowy przed przejściem na bardziej agresywną politykę typu enforce. W ten sposób, nawet jeśli emaile nie są wysyłane przez szyfrowane połączenie TLS, nadal będą wysyłane w postaci plaintext. Upewnij się jednak, że włączyłeś TLS-RPT, aby otrzymywać powiadomienia, jeśli tak się stanie.

TLS-RPT to rozbudowany mechanizm raportowania, który pozwala na otrzymanie powiadomienia w przypadku, gdy nie udało się nawiązać bezpiecznego połączenia i wiadomość e-mail nie została dostarczona do użytkownika. Pomaga to wykryć problemy w dostarczaniu wiadomości e-mail lub wiadomości dostarczonych przez niezabezpieczone połączenie, dzięki czemu można je szybko złagodzić i rozwiązać.

Musisz zauważyć, że podczas gdy MTA-STS zapewnia, że e-maile są przesyłane przez szyfrowane połączenie TLS, w przypadku gdy bezpieczne połączenie nie zostanie wynegocjowane, e-mail może w ogóle nie zostać dostarczony. Jest to jednak konieczne, ponieważ zapewnia, że email nie jest dostarczany przez niezaszyfrowaną ścieżkę. Aby uniknąć takich problemów, zaleca się skonfigurowanie polityki MTA-STS w trybie testowym i włączenie TLS-RPT dla domeny na początku, przed przejściem do trybu egzekwowania MTA-STS. 

Możesz łatwo zmienić tryb MTA-STS z pulpitu nawigacyjnego PowerMTA-STS, wybierając żądany tryb polityki i zapisując zmiany bez konieczności dokonywania jakichkolwiek zmian w DNS.

Możesz wyłączyć MTA-STS dla swojej domeny, ustawiając tryb polityki na „brak”, co spowoduje poinformowanie serwerów MTA, że Twoja domena nie obsługuje tego protokołu, lub usuwając rekord DNS TXT MTA-STS. 

Rekordy MX dla pliku polityki MTA-STS powinny zawierać wpisy dla wszystkich serwerów poczty odbiorczej wykorzystywanych przez domenę.

Zaplanuj prezentację już dziś
bezpieczna poczta elektroniczna powerdmarc

15-dniowy trialZamów demo