Controlli la sua configurazione MTA-STS

Inserisca il suo dominio per controllare sia il record DNS sia il file di criterio ospitato sul suo dominio.

Che cos'è MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) è uno standard di sicurezza e-mail definito in RFC 8461 che consente ai domini di dichiarare di supportare la crittografia TLS per la posta in entrata e che i server mittenti devono rifiutare la consegna dei messaggi su connessioni non cifrate.

Senza MTA-STS, la posta tra i server può essere intercettata tramite attacchi man-in-the-middle che rimuovono la crittografia TLS, anche se entrambi i server la supportano. Questo è chiamato attacco di downgrade TLS. MTA-STS lo previene indicando ai server mittenti di richiedere il TLS e di validare il certificato.

MTA-STS ha due componenti: un record DNS TXT su _mta-sts.ilsuodominio.com e un file di criterio ospitato su https://mta-sts.ilsuodominio.com/.well-known/mta-sts.txt.

Configurazione del criterio

Modalità del criterio MTA-STS

enforce

La posta che non può essere consegnata su una connessione TLS valida viene rifiutata. È la modalità più forte e offre la massima protezione dagli attacchi di downgrade.

testing

I fallimenti TLS vengono segnalati tramite TLS-RPT ma la posta viene comunque consegnata. Ideale per il rilascio iniziale, per individuare i problemi prima di applicare il criterio.

none

MTA-STS è di fatto disattivato. Nessun requisito TLS viene comunicato ai server mittenti. Usato per disattivare un criterio precedentemente pubblicato.

Passo dopo passo

Come funziona MTA-STS

Scoperta DNS

Il server mittente interroga _mta-sts.ilsuodominio.com per un record TXT che contiene v=STSv1; id=20240101.

Recupero del criterio

Se il record TXT esiste, il mittente recupera il file di criterio da https://mta-sts.ilsuodominio.com/.well-known/mta-sts.txt tramite HTTPS.

Applicazione del TLS

In base alla modalità del criterio, il mittente impone il TLS (rifiuta i fallimenti), segnala i fallimenti (modalità testing) oppure non fa nulla (modalità none).

Validazione MX

Il file di criterio specifica quali host MX sono validi. Il mittente verifica che il certificato del server MX corrisponda a uno degli host autorizzati prima di consegnare.

Riferimento RFC 8461

MTA-STS è definito in RFC 8461 (settembre 2018). Integra RFC 8460 (SMTP TLS Reporting), che offre visibilità sui fallimenti di connessione TLS.

Esempio di file di criterio MTA-STS:

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

Leggere i risultati

Comprendere il suo controllo MTA-STS

MTA-STS è insolito tra i record e-mail perché risiede in due luoghi contemporaneamente - un record DNS e un file di criterio ospitato sul web - e entrambi devono concordare. Ecco perché la maggior parte dei problemi MTA-STS sono discordanze di configurazione più che record mancanti.

Cosa valida il verificatore

Un controllo completo conferma che quattro elementi combacino: il record TXT _mta-sts esiste e reca un id valido, il file di criterio è raggiungibile via HTTPS su mta-sts.ilsuodominio.com/.well-known/mta-sts.txt con un certificato attendibile, la mode del criterio è quella prevista e gli host mx elencati corrispondono effettivamente ai suoi record MX pubblicati. Se uno solo non torna, i server mittenti non possono applicare il suo criterio.

Fallimenti MTA-STS comuni

Record TXT ma nessun file di criterio. Il record DNS punta a un criterio che non viene servito: i mittenti ripiegano su nessuna applicazione.
File di criterio non su HTTPS valido. Il sottodominio mta-sts necessita di un proprio certificato TLS attendibile; un certificato autofirmato o scaduto fa fallire il recupero.
Discordanza MX. Le righe mx nel criterio non corrispondono ai suoi host MX reali, quindi server di posta validi falliscono la validazione del certificato.
Bloccato su testing o none. Il criterio è pubblicato ma non impone effettivamente il TLS.
id non modificato. Dopo aver modificato il criterio, l'id del record DNS deve cambiare, altrimenti i mittenti mantengono la vecchia versione in cache.

Rilasciare in sicurezza: testing prima di enforce

Distribuisca MTA-STS a fasi. Pubblichi prima con mode: testing e lo abbini a TLS-RPT, così riceve i rapporti di eventuali fallimenti TLS senza bloccare la posta. Una volta che i rapporti sono puliti e la sua lista MX è confermata, passi a mode: enforce. Imposti un max_age ragionevole (una settimana è comune) così i mittenti mettono in cache il criterio ma recepiscono le modifiche entro un intervallo sensato.

MTA-STS e TLS-RPT lavorano insieme

MTA-STS impone la consegna cifrata; TLS-RPT (RFC 8460) le offre la visibilità per fidarsi di quell'applicazione. Senza reportistica applica alla cieca: distribuisca entrambi insieme, così un certificato guasto emerge come rapporto invece che come posta silenziosamente respinta.

Dove si colloca MTA-STS nel suo stack e-mail

MTA-STS protegge la posta in entrata in transito, ma non autentica i mittenti: è il compito di SPF, DKIM e DMARC sul lato in uscita. Esegua il verificatore di autenticazione del dominio completo per vederli tutti insieme, e mantenga il suo record SPF valido e sotto il limite di 10 ricerche con AutoSPF, così la metà di autenticazione del suo stack sia solida quanto quella di crittografia. Se si chiede perché controllare SPF regolarmente, la deriva dovuta a nuovi mittenti è la ragione.

Completi il suo stack di sicurezza e-mail

MTA-STS protegge il TLS in entrata. AutoSPF protegge il suo SPF in uscita, appiattendo automaticamente i record per restare entro il limite di 10 ricerche.

Inizia la prova gratuita→Vedi piani e prezzi

MTA-STS Checker gratuito