SMTP transport security
MTA-STS
MTA-STS este politica prin care un domeniu poate cere ca livrarea SMTP catre serverele sale MX sa se faca prin TLS valid, nu printr-o conexiune nesecurizata sau printr-un certificat gresit.
Ce este MTA-STS
MTA-STS inseamna SMTP MTA Strict Transport Security. Este un mecanism prin care domeniul destinatar publica o politica pentru serverele care ii trimit email. Politica spune ce MX-uri sunt valide si daca senderul trebuie sa livreze doar prin STARTTLS cu certificat verificabil. In email, transportul SMTP a fost istoric oportunistic: daca STARTTLS exista, se foloseste; daca nu exista sau apare o problema, multe servere pot livra oricum. MTA-STS schimba aceasta logica pentru domeniile care aleg sa publice o politica in modul enforce.
Flagul MTA-STS din Mailcheck este important pentru domenii care primesc email critic: facturi, notificari de securitate, resetari de parola, comunicari B2B sau mesaje cu date personale. Nu valideaza identitatea expeditorului, deci nu inlocuieste SPF, DKIM sau DMARC. Rolul lui este sa protejeze transportul intre servere, in special cand exista riscul ca cineva sa incerce sa elimine STARTTLS sau sa redirectioneze livrarea catre un MX cu certificat nepotrivit.
Cum functioneaza
Un domeniu publica doua elemente. Primul este un TXT DNS la _mta-sts.domeniu. Acest TXT contine versiunea si un identificator id. Al doilea element este fisierul policy servit prin HTTPS la https://mta-sts.domeniu/.well-known/mta-sts.txt. Senderii compatibili citesc TXT-ul, descarca fisierul policy si il pot memora pana la durata indicata prin max_age.
_mta-sts.example.com. TXT "v=STSv1; id=2026081501"
Campul id trebuie schimbat cand modifici fisierul policy. Daca nu il schimbi, multe servere care trimit email pot continua sa foloseasca politica memorata anterior. De aceea, cand adaugi sau scoti un MX, cand treci din testing in enforce sau cand schimbi max_age, actualizezi si TXT-ul.
Fisierul policy HTTPS
Fisierul policy trebuie servit de hostul mta-sts.domeniu, prin HTTPS valid. Certificatul trebuie sa fie valid pentru hostul respectiv. Continutul este text simplu si include versiunea, modul, lista de MX-uri si durata de cache.
version: STSv1 mode: enforce mx: mx1.example.com mx: mx2.example.com max_age: 86400
Modul testing este util pentru inceput. Senderii pot raporta probleme, dar nu ar trebui sa blocheze livrarea strict pe baza politicii. Modul enforce este modul final: daca MX-ul real nu este in policy, daca TLS lipseste sau certificatul nu este valid, livrarea poate esua. Modul none dezactiveaza politica si este folosit pentru retragere controlata.
Lista mx: trebuie sa reflecte MX-urile publicate in DNS. Se pot folosi wildcard-uri, dar este mai clar si mai sigur sa listezi numele reale atunci cand infrastructura este stabila. Daca MX-urile sunt mx1.example.com si mx2.example.com, ambele trebuie sa aiba STARTTLS functional si certificate care se potrivesc cu hostname-ul MX.
Cum interpretezi statusul
- PASS - TXT-ul exista, fisierul policy este accesibil prin HTTPS valid, sintaxa este corecta, modul este coerent, iar MX-urile reale sunt acoperite.
- MISSING - domeniul nu are MTA-STS configurat. Nu este neaparat defect, dar lipseste protectia suplimentara.
- WARN - politica exista, dar ofera protectie redusa, de exemplu
mode: testingsaumax_agefoarte mic. - FAIL - domeniul a inceput configurarea, dar ceva este invalid: TXT gresit, host HTTPS inexistent, certificat invalid, fisier lipsa sau MX-uri neacoperite.
Greseli frecvente
Cea mai comuna greseala este sa existe TXT-ul _mta-sts, dar hostul mta-sts.domeniu sa nu raspunda corect pe HTTPS. In acest caz nu vorbim despre MISSING, ci despre FAIL: domeniul anunta MTA-STS, dar politica nu poate fi citita. O alta problema frecventa este certificatul HTTPS pentru policy emis pe alt nume, de exemplu pentru domeniul principal, nu pentru mta-sts.domeniu.
Mai apare des si diferenta dintre MX-urile reale si MX-urile declarate in policy. Daca DNS spune ca domeniul primeste email prin mx1 si mx2, dar policy contine doar mx1, unele livrari pot fi considerate nesigure. La fel, daca ai schimbat MX-urile si nu ai schimbat id, senderii pot ramane cu politica veche in cache.
Ce verifica Mailcheck
Mailcheck verifica existenta TXT-ului MTA-STS, accesul la fisierul policy, certificatul HTTPS al hostului mta-sts, sintaxa fisierului, modul, max_age si potrivirea cu MX-urile reale. Cand flagul este bifat in test, rezultatul apare atat in tabelul principal, cat si in sectiunea detaliata de flags, astfel incat vezi nu doar PASS/FAIL, ci si motivul tehnic.
Recomandarea practica este sa activezi mai intai mode: testing, sa configurezi TLS-RPT ca sa primesti rapoarte, sa remediezi problemele raportate, apoi sa treci in mode: enforce cu un max_age mai mare. Pentru domeniile care primesc email important, MTA-STS si TLS-RPT sunt o pereche foarte buna.