Zarówno MTA-STS, jak i DANE rozwiązują ten sam problem: połączenie SMTP między serwerami pocztowymi zaczyna się jawnym tekstem, a STARTTLS może zostać usunięte przez atakującego znajdującego się na trasie. Każdy z tych standardów mówi serwerowi wysyłającemu: "szyfruj połączenie do mnie, zweryfikuj mój certyfikat i nie wracaj do transmisji jawnym tekstem". Różnica polega na tym, czemu ufają, aby dowieść, że certyfikat jest prawdziwy. MTA-STS opiera się na HTTPS i publicznym systemie urzędów certyfikacji. DANE opiera się na DNSSEC i skrócie zakotwiczonym w DNS. Dla większości domen w 2026 roku uczciwa odpowiedź brzmi: opublikuj teraz MTA-STS, ponieważ honorują je duzi dostawcy skrzynek, a DANE dodaj tam, gdzie wspiera je Twój dostawca DNS i odbiorcy.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Problem, który rozwiązują oba standardy
Gdy jeden serwer pocztowy doręcza wiadomość do drugiego, wyszukuje rekordy MX odbiorcy, łączy się na porcie 25 i wydaje polecenie STARTTLS, aby podnieść sesję do TLS. To podniesienie jest domyślnie oportunistyczne. Jeśli atakujący sieciowy przepisze odpowiedź STARTTLS, serwer wysyłający po cichu doręczy wiadomość jawnym tekstem, a SMTP z założenia nikogo o tym nie ostrzega. To jest atak z obniżeniem zabezpieczeń i niweczy on sens TLS.
Oportunistyczne TLS zwykle też nie weryfikuje certyfikatu. Serwer wysyłający często zaakceptuje certyfikat wygasły, samopodpisany lub o niewłaściwej nazwie, ponieważ odrzucenie poczty z powodu problemu z certyfikatem historycznie wyrządzało więcej szkód niż atak, przed którym miało chronić. Zatem obie luki są w obu przypadkach takie same: brak gwarancji, że TLS jest używane, oraz brak gwarancji, że certyfikat należy do prawdziwego odbiorcy.
MTA-STS (RFC 8461) oraz DANE dla SMTP (RFC 7672, oparte na RFC 6698) zamykają obie te luki. Różnią się jedynie tym, jak nadawca poznaje politykę i jak uwierzytelnia certyfikat.
Jak działa MTA-STS
MTA-STS publikuje politykę, którą serwer wysyłający pobiera przez HTTPS. Dodajesz rekord TXT pod _mta-sts.example.com i hostujesz plik polityki pod stałym adresem URL HTTPS w subdomenie mta-sts..
Rekord DNS wygląda tak:
_mta-sts.example.com. IN TXT "v=STSv1; id=20260703T120000"
Plik polityki znajduje się pod https://mta-sts.example.com/.well-known/mta-sts.txt i wygląda mniej więcej tak:
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800
Serwer wysyłający, który obsługuje MTA-STS, pobiera ten plik przez HTTPS, sprawdza certyfikat względem publicznego systemu urzędów certyfikacji dokładnie tak, jak robi to przeglądarka, i buforuje politykę przez max_age sekund. W trybie enforce nadawca wymaga następnie TLS do pasującego hosta MX z ważnym certyfikatem o zgodnej nazwie. Jeśli nie może tego uzyskać, nie doręcza wiadomości. Najpierw przechodzisz przez mode: none i mode: testing, aby móc obserwować ewentualne awarie, zanim włączysz wymuszanie. Pełne wdrożenie opisano w jak skonfigurować MTA-STS.
Słabość zaufania przy pierwszym użyciu
MTA-STS ma jedną strukturalną lukę: zaufanie przy pierwszym użyciu, czyli TOFU. Przy pierwszym kontakcie nadawcy z Twoją domeną nie ma on jeszcze zbuforowanej polityki. Atakujący, który potrafi zablokować pobranie przez HTTPS z Twojego hosta mta-sts. lub zablokować odpytanie rekordu TXT, może sprawić, że nadawca zachowa się tak, jakbyś w ogóle nie miał polityki, i wróci do transmisji jawnym tekstem. To samo dotyczy sytuacji po wygaśnięciu zbuforowanej polityki. MTA-STS drastycznie zawęża okno ataku w porównaniu ze zwykłym oportunistycznym TLS, ale go nie eliminuje, ponieważ sama polityka jest tylko tak wiarygodna, jak nieuwierzytelnione odpytanie DNS plus osiągalny serwer WWW.
Jak działa DANE
DANE obiera inną drogę. Nie używa w ogóle HTTPS ani publicznych urzędów certyfikacji. Zamiast tego publikuje w DNS rekord TLSA zawierający skrót certyfikatu lub klucza publicznego serwera pocztowego i wymaga, aby ta strefa DNS była podpisana za pomocą DNSSEC.
Rekord TLSA dla hosta SMTP wygląda tak:
_25._tcp.mail.example.com. IN TLSA 3 1 1 0b87ea...
Trzy liczby to usage, selector oraz matching type. Usage 3 oznacza "dokładnie ten certyfikat lub klucz", selector 1 oznacza, że rekord obejmuje klucz publiczny, a matching type 1 oznacza SHA-256. Serwer wysyłający, który obsługuje DANE, wyszukuje host MX, pobiera jego rekord TLSA, weryfikuje łańcuch podpisów DNSSEC, a następnie wymaga, aby przedstawiony certyfikat pasował do zakotwiczonego skrótu.
Ponieważ DNSSEC kryptograficznie podpisuje całe odpytanie, DANE nie ma okna zaufania przy pierwszym użyciu. Nie ma "pierwszego kontaktu", który atakujący mógłby wykorzystać, ponieważ sfałszowana lub usunięta odpowiedź TLSA nie przechodzi walidacji DNSSEC, a nadawca traktuje to jako atak, a nie jako "brak polityki". To jest kluczowa przewaga: DANE uwierzytelnia już pierwsze połączenie, a MTA-STS tego nie potrafi.
Koszt wejścia w DANE
Haczyk tkwi w DNSSEC. DANE jest tylko tak silne, jak podpisana strefa pod spodem, dlatego musisz poprawnie prowadzić DNSSEC dla swojej domeny i dla strefy każdej nazwy hosta MX. DNSSEC jest potężne, ale bezlitosne. Nieudana rotacja klucza lub wygasły podpis nie tylko psuje DANE, lecz może sprawić, że cała Twoja domena stanie się nieosiągalna. Wielu zarządzanych dostawców DNS wciąż utrudnia obsługę DNSSEC, a niektórzy w ogóle nie pozwalają publikować dowolnych rekordów TLSA. Ta poprzeczka operacyjna to najważniejszy powód, dla którego adopcja DANE pozostaje w tyle za MTA-STS.
Rzeczywistość wsparcia po stronie dostawców
Tutaj decyzja zwykle zapada za Ciebie. Duzi konsumenccy dostawcy skrzynek dokonali przeciwnych wyborów.
Google i Microsoft działają zgodnie z MTA-STS jako nadawcy. Gdy Gmail lub Microsoft 365 doręcza pocztę do Twojej domeny i znajduje wymuszającą politykę MTA-STS, honoruje ją. Google publikuje też politykę MTA-STS dla własnej poczty przychodzącej Gmaila. Ani Gmail, ani Outlook nie weryfikują DANE przy odbiorze poczty, więc rekord TLSA na Twoim MX nic nie daje dla poczty przychodzącej z tych dwóch sieci. Microsoft stopniowo wdraża wsparcie DANE i DNSSEC dla poczty wychodzącej i przychodzącej w Exchange Online, ale aktualny status powinieneś potwierdzić w centrum administracyjnym Microsoft 365, a nie zakładać, że jest włączone.
DANE ma głębokie wsparcie w innej grupie: w dużej części europejskiego ekosystemu hostingu i dostawców internetu, u dostawców skrzynek w Niemczech i Holandii oraz u dużych operatorów, którzy już prowadzą DNSSEC. Jeśli wysyłasz do tych sieci lub odbierasz z nich pocztę, DANE ma realną wagę.
Mapa wsparcia wygląda więc mniej więcej tak. MTA-STS daje Ci pokrycie u największych globalnych odbiorców. DANE daje silniejszą ochronę bez TOFU u operatorów zaangażowanych w DNSSEC. Chronią one nakładający się, ale nie identyczny ruch.
Którego użyć
Nie musisz wybierać i nie powinieneś ujmować tego jako "albo-albo".
Opublikuj najpierw MTA-STS, jeśli masz zrobić tylko jedną rzecz. Nie wymaga ono DNSSEC, chroni pocztę idącą od Gmaila i Outlooka do Ciebie, a wdrożyć je możesz bezpiecznie przez tryb testing. Dla większości domen firmowych jest to ruch o większym zasięgu i mniejszym ryzyku.
Dodaj DANE, gdy Twój DNS działa już na DNSSEC lub gdy jesteś gotów prowadzić je właściwie. DANE zamyka lukę zaufania przy pierwszym użyciu, którą MTA-STS pozostawia otwartą, i dociera do nadawców weryfikujących DANE, którzy ignorują MTA-STS. Jeśli hostujesz pocztę dla europejskiej publiczności lub organizacji wrażliwej na bezpieczeństwo, DANE jest warte kosztu operacyjnego.
Prowadź oba tam, gdzie możesz. Współistnieją one bez problemu. Serwer wysyłający wybiera ten standard, który obsługuje; nie ma konfliktu, gdy istnieje jednocześnie ważny rekord TLSA i wymuszająca polityka MTA-STS, ponieważ każdy nadawca po prostu podąża za tym, który rozumie. Publikacja obu maksymalizuje zbiór nadawców zmuszonych do szyfrowania i weryfikacji w drodze do Ciebie.
Jedna rzecz, którą warto mieć jasno: bezpieczeństwo transportu to nie uwierzytelnianie. MTA-STS i DANE chronią rurę między serwerami. Nie mówią nic o tym, czy wiadomość naprawdę pochodzi z Twojej domeny. To zadanie należy do SPF, DKIM i DMARC, objaśnionych w SPF, DKIM i DMARC wyjaśnione oraz konfigurowanych przez jak skonfigurować DMARC i jak skonfigurować DKIM. Jeśli przechodzisz przez wymagania dla nadawców Google i Yahoo, uwierzytelnianie jest warstwą obowiązkową, a bezpieczeństwo transportu leży na jej wierzchu.
Najczęściej zadawane pytania
Czy mogę prowadzić MTA-STS i DANE jednocześnie?
Tak, i jest to zalecana konfiguracja, gdy Twój DNS obsługuje DNSSEC. Standardy nie kolidują ze sobą. Każdy serwer wysyłający podąża za tym, który wdraża, więc publikacja obu oznacza po prostu, że więcej nadawców jest zmuszonych używać zweryfikowanego TLS, aby dotrzeć do Ciebie.
Czy DANE wymaga DNSSEC?
Tak. Cały model bezpieczeństwa DANE opiera się na podpisaniu odpytania TLSA przez DNSSEC. Bez poprawnie podpisanej strefy rekord TLSA jest bezwartościowy, a nadawcy świadomi DANE go zignorują. Jeśli nie potrafisz prowadzić DNSSEC niezawodnie, użyj zamiast tego MTA-STS.
Czy Gmail i Outlook obsługują DANE?
Jako odbiorcy: Gmail nie weryfikuje DANE, a wsparcie Outlooka wdrażane jest etapami, a nie włączone powszechnie. Oba honorują MTA-STS jako nadawcy. Dlatego właśnie MTA-STS jest wyborem o większym pokryciu, gdy chcesz dotrzeć do dużych dostawców skrzynek, a DANE stanowi uzupełnienie, a nie zamiennik.
Co jest bezpieczniejsze, MTA-STS czy DANE?
DANE jest silniejsze w jednym konkretnym aspekcie: nie ma okna zaufania przy pierwszym użyciu, ponieważ DNSSEC uwierzytelnia pierwsze połączenie. MTA-STS można obejść przy pierwszym kontakcie nadawcy lub po wygaśnięciu jego zbuforowanej polityki. W praktyce bezpieczniejszym wyborem jest ten, który Twoi odbiorcy faktycznie honorują, dlatego wdrożenie obu daje najlepszą ochronę w rzeczywistych warunkach.