MTA-STS Checker Gratuito

Perché verificare il Suo MTA-STS

Il trasporto SMTP usa TLS in modo opportunistico: se la cifratura fallisce, la connessione torna in chiaro senza alcun avviso. Un attaccante in posizione di man-in-the-middle può quindi rimuovere il banner STARTTLS e forzare l'invio delle Sue email in testo leggibile.

MTA-STS (RFC 8461) colma questa lacuna. Pubblica una policy servita via HTTPS basata su PKI pubblica che ordina agli MTA mittenti di rifiutare qualsiasi connessione senza TLS valido. È il livello mancante per chiudere la porta agli attacchi di downgrade e allo spoofing TLS.

Verificare la Sua configurazione prima di passare a enforce è critico:

• Policy rotta → le email legittime possono essere bloccate
• Pattern MX incompleti → alcuni server restano vulnerabili
• Certificato scaduto → la policy diventa non valida, gli MTA mittenti tornano al TLS opportunistico

Casi d'uso comuni:

• Dopo la pubblicazione → confermare che DNS, policy HTTPS e TLS sono coerenti
• Prima di mode: enforce → assicurarsi che nessun MX legittimo sia escluso
• Audit di sicurezza → validare la protezione contro il downgrade TLS

Come usare questo checker in 3 passi

Passo 1: inserire il dominio da analizzare

Inserisca il dominio esattamente come appare nei Suoi indirizzi email:

• captaindns.com (dominio principale)
• marketing.captaindns.com (sottodominio se invia da un sottodominio)

Lo strumento interroga automaticamente _mta-sts.dominio, recupera https://mta-sts.dominio/.well-known/mta-sts.txt e confronta i pattern con i record MX.

Passo 2: analizzare i risultati

Il checker mostra:

Passo 3: correggere i problemi segnalati

I risultati sono classificati per gravità:

• Critico → la policy è inutilizzabile, gli MTA mittenti la ignorano
• Avviso → funziona ma espone a un rischio o a una protezione parziale
• Info → buona pratica non bloccante

Corregga il DNS o il file di policy, attenda la propagazione, poi rilanci il checker.

Cos'è MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) è un meccanismo che:

1. Pubblica una policy HTTPS che indica quali host MX supportano TLS
2. Impone la cifratura TLS tra MTA mittenti e riceventi
3. Blocca gli attacchi di downgrade che rimuovono STARTTLS

L'architettura combina tre elementi:

Esempio di record DNS:

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Esempio di policy:

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

Differenza con DANE: MTA-STS si basa sulla PKI pubblica (autorità di certificazione), DANE si basa su DNSSEC e sui record TLSA. Entrambi i meccanismi sono compatibili e possono essere distribuiti insieme.

Cosa verifica il checker

Sette dimensioni sono analizzate in parallelo per produrre uno score 0-100:

Record DNS pubblicato

Recupero del file di policy

Sintassi della policy

Copertura dei server MX

Tutti gli host MX risolti per il dominio devono corrispondere ad almeno un pattern:

• Corrispondenza diretta: mx: mail.captaindns.com copre mail.captaindns.com
• Wildcard limitato a un'etichetta: *.mail.captaindns.com copre eu.mail.captaindns.com ma non mail.captaindns.com

Validità del certificato TLS

Il sottodominio mta-sts.dominio viene sondato via HTTPS:

• Certificato non scaduto
• Nome host presente nel SAN
• Catena completa fino a una CA riconosciuta
• Versione TLS recente (1.2 minimo)

Coerenza tra DNS e policy

L'ID DNS e l'ID della policy servita devono corrispondere. Una discrepanza indica un aggiornamento parziale pericoloso per la cache degli MTA mittenti.

Presenza di TLS-RPT

Il checker segnala l'assenza del record _smtp._tls (TLS-RPT, RFC 8460). Senza TLS-RPT, non saprà mai se la policy causa fallimenti di consegna silenziosi.

Diagnostica comune e soluzioni

Policy non raggiungibile (policy_fetch_failed)

Causa: il sottodominio mta-sts.dominio non risponde, non serve HTTPS o restituisce un errore HTTP.

Soluzioni:

1. Verificare che mta-sts.dominio si risolva in DNS (A o CNAME)
2. Confermare che venga servito un certificato TLS valido (Let's Encrypt, autocert, ecc.)
3. Confermare che /.well-known/mta-sts.txt restituisca 200 OK con text/plain

Certificato TLS non valido (cert_invalid)

Causa: certificato scaduto, autofirmato, nome host non coperto dal SAN, o catena incompleta.

Soluzioni:

1. Rinnovare il certificato prima della scadenza
2. Includere mta-sts.dominio nel SAN
3. Servire la catena intermedia completa

Record DNS assente (missing_record)

Causa: nessun TXT esiste su _mta-sts.dominio.

Soluzione: pubblicare

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Policy disattivata (mode_none)

Causa: mode: none indica che MTA-STS è annunciato ma senza effetto.

Soluzione: passare a mode: testing dopo la pubblicazione iniziale, poi a mode: enforce quando TLS-RPT è pulito.

Copertura MX incompleta (mx_partial_match)

Causa: uno o più MX risolti non corrispondono a nessun pattern della policy.

Soluzione: elencare esplicitamente ogni host MX o usare un wildcard più ampio adatto alla Sua infrastruttura.

Assenza di TLS-RPT (tls_rpt_missing)

Causa: nessun record _smtp._tls.dominio è pubblicato.

Soluzione: pubblicare

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Progressione da testing a enforce

Fase 1: pubblicazione iniziale in modalità testing

version: STSv1
mode: testing
mx: mail.captaindns.com
max_age: 86400

• Gli MTA mittenti segnalano i fallimenti TLS via TLS-RPT senza bloccare la consegna
• Mantenga max_age corto (1 a 7 giorni) per iterare rapidamente
• Raccolga i report TLS-RPT per 2 a 4 settimane

Fase 2: stabilizzazione e osservazione

In questo periodo, verifichi:

• Nessun MX legittimo escluso (TLS-RPT segnalerebbe fallimenti mx-mismatch)
• Nessun problema di certificato sugli host MX (TLS-RPT segnalerebbe certificate-not-trusted)
• Nessun MTA mittente in difficoltà (report vuoti o nulli)

Fase 3: passaggio alla modalità enforce

version: STSv1
mode: enforce
mx: mail.captaindns.com
max_age: 604800

• Allungare max_age (minimo 7 giorni, fino a 1 anno)
• Monitorare TLS-RPT in continuo: i fallimenti diventano ora mancate consegne
• Preparare un piano di rollback (tornare a testing rapidamente se necessario)

Errori frequenti:

• max_age troppo corto → gli MTA mittenti riscaricano la policy troppo spesso, carico inutile
• max_age troppo lungo → un cambio di MX richiede settimane per propagarsi
• Pattern MX incompleti → le email legittime sono rifiutate silenziosamente

MTA-STS vs DANE

Entrambi i meccanismi proteggono il trasporto SMTP dagli attacchi di downgrade, ma con approcci diversi.

Quando scegliere MTA-STS: non ha DNSSEC, o vuole un'implementazione rapida con sforzo operativo minimo.

Quando scegliere DANE: il Suo dominio è già firmato DNSSEC e vuole la garanzia aggiuntiva del pinning crittografico.

Entrambi sono compatibili e possono essere distribuiti in parallelo. Gli MTA mittenti scelgono il meccanismo che sanno gestire.

Strumenti complementari e risorse

Risorse:

• MTA-STS: la guida completa per proteggere il trasporto delle Sue email
• Guida al troubleshooting di MTA-STS
• Passare MTA-STS da testing a enforce
• MTA-STS vs DANE: confronto
• TLS-RPT: la guida completa
• RFC 8461 - SMTP MTA Strict Transport Security
• RFC 8460 - SMTP TLS Reporting