2026-08-11 · RESEARCH · Il team di Offensive Technology

SMTP TLS Downgrade: il 92% di divario dietro DMARC

Un attacco SMTP TLS downgrade rimuove la cifratura dall'email mentre è in transito, e la maggior parte dei domini non può fermarlo. La cifratura SMTP classica è opportunistica: i server offrono STARTTLS, ma se un attaccante on-path rimuove questa offerta, il server mittente torna silenziosamente al cleartext invece di rifiutare. Gli unici record che rendono il TLS obbligatorio sono MTA-STS e DANE. Abbiamo risolto il DNS pubblico dei primi 25.000 siti Tranco e letto quei record per i 18.012 domini che ricevono posta. Il risultato è una spaccatura netta. L'autenticazione è comune: il 79,3% pubblica DMARC e il 55,2% lo applica in enforcement. L'enforcement della cifratura in transito è raro: solo il 3,3% pubblica una policy MTA-STS, il 3,6% pubblica un record DANE, e solo il 6,5% pubblica almeno uno dei due. Mettendo insieme le due cose il divario è netto: dei domini che applicano DMARC, il 92% non pubblica né MTA-STS né DANE, quindi la loro posta è autenticata contro lo spoofing ma resta comunque degradabile in transito.

Cos'è davvero un attacco SMTP TLS downgrade

L'SMTP tra server di posta inizia in chiaro. Il server ricevente annuncia le proprie capacità, e se supporta la cifratura la elenca STARTTLS tra queste. Il server mittente emette quindi STARTTLS e i due negoziano una sessione TLS. Il punto debole sta nella parola opportunistica. Se la capacità STARTTLS non viene annunciata, o l'handshake TLS fallisce, o il certificato non si convalida, il comportamento predefinito storico non è interrompere. È inviare comunque la posta in chiaro, sul presupposto che consegnare il messaggio conti più che cifrarlo.

Quel comportamento predefinito è ciò che un attaccante sfrutta. Un avversario con una posizione sul percorso di rete, un operatore presso un provider di transito, qualcuno che ha compromesso un router, un attore statale a un confine, osserva lo scambio iniziale in chiaro e cancella la riga STARTTLS dall'elenco delle capacità del ricevente prima che raggiunga il mittente. Il mittente, non vedendo alcuna offerta di cifratura, consegna in cleartext. Questo è lo STARTTLS stripping, ed è un downgrade piuttosto che una violazione: non viene decifrato nulla, il protocollo viene semplicemente reindirizzato verso il suo fallback non cifrato. Il messaggio, i suoi allegati, ed eventuali contenuti di reset password o fatture viaggiano in chiaro sul filo. La comunità operativa APNIC ha una descrizione chiara del meccanismo (SMTP downgrade attacks and MTA-STS) se volete la visione a livello di pacchetto.

Due standard chiudono il fallback. MTA-STS (RFC 8461) permette a un dominio di pubblicare una policy che dice, in sostanza, "per la mia posta in ingresso, è richiesto TLS con certificato valido, non fare fallback." Un mittente che ha recuperato e messo in cache quella policy rifiuterà una connessione strippata invece di degradarla. DANE per SMTP (RFC 7672) svolge lo stesso compito pubblicando un record TLSA nel DNS, autenticato da DNSSEC, che fissa quale certificato il server di posta deve presentare. Entrambi trasformano un downgrade silenzioso in una consegna rifiutata. Nessuno dei due è attivo di default, e questa è tutta la storia dietro i numeri qui sotto.

Perché DMARC non aiuta qui

Vale la pena essere precisi su questo punto, perché i due problemi vengono costantemente confusi. DMARC, SPF e DKIM sono autenticazione. Permettono a un destinatario di decidere se l'indirizzo From visibile è legittimo, e DMARC dice al destinatario cosa fare quando non lo è. È così che si impedisce a qualcuno di falsificare il vostro dominio. Abbiamo misurato quel livello in un post precedente sul divario tra pubblicare ed applicare DMARC, e conta. Ma autenticazione e cifratura sono ortogonali. DMARC opera su chi il messaggio dichiara di essere. Un attacco di downgrade opera sul trasporto che porta il messaggio. Si può superare ogni controllo di autenticazione a pieni voti e avere comunque la connessione strippata a cleartext, perché DMARC non ha mai avuto un'opinione sul trasporto, fin dall'inizio.

Quindi un dominio a p=reject con SPF e DKIM perfettamente allineati ha risolto lo spoofing e non ha fatto nulla contro l'intercettazione. La posta che arriva è dimostrabilmente dal mittente giusto ed era leggibile da chiunque si trovasse sul percorso. Questa è la confusione che questa misurazione esiste per correggere: un controllo DMARC verde non è un lucchetto sulla busta.

I dati: autenticata, non cifrata

Ecco il quadro di adozione sui 18.012 domini che ricevono posta nel campione. La barra dell'autenticazione è alta. Le due barre che effettivamente fermano un downgrade sono minuscole.

I meccanismi di sicurezza del trasporto scomposti, con cosa offre ciascuno, sono qui sotto. Leggete insieme le ultime due righe: sommando MTA-STS e DANE, solo una piccola minoranza di domini di posta ha un qualche enforcement contro un downgrade, e quasi nessuno esegue entrambi.

Un dettaglio in quella tabella merita una pausa. DANE (3,6%) è marginalmente più comune di MTA-STS (3,3%), il che contraddice l'assunto abituale secondo cui MTA-STS avrebbe vinto perché non richiede DNSSEC. I due si sovrappongono a malapena: solo lo 0,3% dei domini di posta pubblica entrambi. In pratica si tratta di due schieramenti. I provider e le zone country-code che già firmano con DNSSEC propendono per DANE, tutti gli altri che si preoccupano almeno un po' propendono per MTA-STS, e l'unione dei due sforzi lascia comunque il 93,5% dei domini di posta senza alcun enforcement.

Il divario del 92%

Il numero che vale la pena ricordare è il confronto incrociato. Dei 9.945 domini che applicano DMARC a quarantine o reject, 9.192, ovvero il 92%, non pubblica né una policy MTA-STS né un record DANE. Non si tratta di ritardatari che hanno ignorato la sicurezza email. Sono i domini che hanno fatto il lavoro più difficile e più visibile di portare DMARC all'enforcement, e poi si sono fermati un livello prima. Hanno deciso che un mittente falsificato è inaccettabile, il che è corretto, lasciando però il messaggio reale leggibile in transito a chiunque sia posizionato per strippare la sessione.

Guardatelo dal punto di vista dell'attaccante, perché è quella prospettiva a decidere se un controllo conta. Supponiamo che vogliate leggere o alterare la posta diretta a un bersaglio, non falsificarla. Cercate una posizione sul percorso e un dominio che effettuerà il downgrade. Controllate il DNS del bersaglio nello stesso modo in cui lo abbiamo fatto noi. Se il dominio pubblica una policy MTA-STS in modalità enforce, o un record DANE su una zona firmata, un server mittente che la rispetta rifiuterà di consegnarvi una sessione in chiaro, e il vostro downgrade fallisce al mittente. Se il dominio non pubblica nessuno dei due, il che descrive il 92% dell'insieme in enforcement e il 93,5% di tutti i domini di posta, lo STARTTLS opportunistico è la regola e uno strip restituisce cleartext. La postura DMARC che vedete anche in quella query DNS non cambia nulla di questo esito. Non stavate mai per falsificare il mittente. Stavate per leggere la posta.

Ciò che rende questo numero degno di essere citato è come è stato prodotto. È una misurazione passiva indipendente, non telemetria di un vendor. Non abbiamo riferito su posta filtrata da un nostro prodotto, e non abbiamo estrapolato dal flusso in ingresso di un singolo provider. Abbiamo letto i record di policy pubblici che ogni server mittente su internet legge, per un campione fisso a una data fissa. Sondaggi di adozione precedenti raggiungono la stessa conclusione da punti di osservazione diversi: tracker indipendenti come il sondaggio MTA-STS di URIports collocano l'adozione a una cifra singola bassa e in lenta crescita, il che è coerente con ciò che vediamo nel DNS grezzo.

Come controllare e correggere il proprio dominio

Non serve uno strumento o una registrazione. Una query DNS è una lettura passiva di record già pubblici, quindi potete eseguirle sul vostro dominio proprio ora.

• Controllate MTA-STS. Eseguite dig TXT _mta-sts.yourdomain.com +short. Un record che inizia con v=STSv1 significa che annunciate una policy. Se è vuoto, non avete MTA-STS. Notate che il record indica solo dove trovare una policy; il file di policy su https://mta-sts.yourdomain.com/.well-known/mta-sts.txt deve dire mode: enforce per bloccare davvero, non mode: testing.
• Controllate DANE. Trovate prima i vostri server di posta con dig MX yourdomain.com +short, poi per ogni host MX eseguite dig TLSA _25._tcp.that-mx-host +short. Un record TLSA significa che DANE è attivo. DANE si convalida solo su una zona firmata con DNSSEC, quindi confermate la firma con dig DS yourdomain.com +short.
• Attivate il reporting. Pubblicate un record TLS-RPT (RFC 8460) su _smtp._tls.yourdomain.com così gli handshake falliti e i downgrade vengono segnalati a voi invece di restare invisibili. Non blocca nulla, ma è come scoprite che un downgrade sta avvenendo.

Se sia la ricerca MTA-STS che quella TLSA tornano vuote, la vostra posta in ingresso è protetta contro la falsificazione ed esposta all'intercettazione. La correzione è pubblicare una policy MTA-STS in modalità enforce, o un record DANE TLSA su una zona firmata, o entrambi. Fare anche solo una delle due cose vi mette nella piccola minoranza. Il giudizio necessario per implementarne una senza rompere la consegna legittima è lo stesso giudizio che sta dietro al sapere quali dei vostri altri controlli esposti contano davvero, il che è il punto di leggere una superficie nel modo in cui lo fa un attaccante piuttosto che fidarsi dei controlli verdi.

Cosa questo non dimostra

Limiti onesti, perché un numero senza le sue avvertenze è marketing.

• Tranco classifica per popolarità aggregata, non per traffico. La lista Tranco combina diverse classifiche di provider per essere stabile e difficile da manipolare, ma non è un censimento del traffico. Leggete queste cifre come una fetta onesta del web popolare, non l'intero internet.
• MTA-STS è misurato al livello del segnale DNS. Abbiamo contato un dominio come dotato di MTA-STS se pubblica il record _mta-sts. Deliberatamente non abbiamo recuperato il file di policy, il che avrebbe significato contattare l'host web del dominio, quindi non possiamo distinguere mode: enforce da mode: testing. La quota effettivamente in enforcement è quindi pari o inferiore al 3,3%, il che rende il divario più ampio, non più stretto.
• DANE è misurato tramite la presenza di TLSA. Abbiamo verificato la presenza di un record TLSA sugli host MX, fino a cinque per dominio. Un record pubblicato segnala intenzione e configurazione; non abbiamo verificato la catena DNSSEC né che ogni mittente la convalidi, quindi trattate il 3,6% come il tetto massimo di DANE funzionante correttamente.
• È una fotografia. Il DNS cambia quotidianamente. Queste cifre descrivono l'11 agosto 2026, non una tendenza, sebbene concordino con sondaggi indipendenti che mostrano un'adozione bassa e in lenta crescita.
• L'enforcement in transito dipende comunque dal mittente. MTA-STS e DANE aiutano solo quando il server mittente li rispetta. Chi pubblica fa la cosa giusta annunciando la policy; un mittente che la ignora può comunque effettuare il downgrade. I record sono necessari, non di per sé sufficienti.

Domande frequenti

Cos'è un attacco STARTTLS downgrade?

È quando un attaccante sul percorso di rete tra due server di posta rimuove l'offerta del server di passare a TLS dall'inizio in chiaro della sessione SMTP. Poiché lo STARTTLS opportunistico torna al cleartext quando nessun TLS viene offerto, il mittente consegna quindi la posta non cifrata e l'attaccante può leggerla o alterarla. MTA-STS e DANE chiudono il fallback dicendo al mittente che il TLS è richiesto.

L'SMTP è cifrato in transito per impostazione predefinita?

Non in modo affidabile. La maggior parte dei server offre STARTTLS, ma il TLS SMTP classico è opportunistico: se l'offerta manca o il certificato non si convalida, il mittente torna silenziosamente al cleartext. La cifratura avviene quando nulla interferisce, ma un attaccante attivo può strippala. Solo il 6,5% dei domini di posta che abbiamo misurato rende il TLS obbligatorio con MTA-STS o DANE.

DMARC cifra l'email in transito?

No. DMARC, insieme a SPF e DKIM, autentica il mittente in modo che un destinatario possa individuare un indirizzo From falsificato. Non dice nulla sul fatto che la connessione sia cifrata. Un dominio può applicare DMARC a p=reject e avere comunque la sua posta consegnata in cleartext dopo un downgrade. Nel nostro campione il 92% dei domini che applicano DMARC non pubblicava né MTA-STS né DANE.

MTA-STS previene gli attacchi di TLS downgrade?

Sì, è esattamente il suo scopo. MTA-STS pubblica una policy che dice ai server mittenti che il vostro dominio richiede TLS con certificato valido, quindi un mittente che ha messo in cache la policy rifiuta una connessione strippata invece di tornare al fallback. Il suo unico limite è il trust-on-first-use: un mittente che non ha mai recuperato la vostra policy non è ancora coperto, ed è qui che DANE, ancorato a DNSSEC, è più forte.

Qual è la differenza tra MTA-STS e DANE?

Entrambi forzano il TLS sull'SMTP in ingresso ma ancorano la fiducia in modo diverso. MTA-STS si basa sul sistema dei certificati web più il trust-on-first-use e non richiede DNSSEC. DANE pubblica un record TLSA autenticato da DNSSEC, che elimina il vuoto del primo utilizzo ma richiede una zona firmata. Nel nostro censimento sono stati adottati a un tasso quasi identico e basso, 3,3% e 3,6%, e solo lo 0,3% dei domini di posta ha pubblicato entrambi.

Che percentuale di domini ha implementato MTA-STS?

Nel nostro censimento di agosto 2026 dei primi 25.000 Tranco, dei 18.012 domini che ricevono posta, il 3,3% pubblicava un record MTA-STS. DANE era al 3,6% e TLS-RPT al 3,9%. Contando entrambi i controlli di enforcement, il 6,5% richiede TLS in transito, contro il 79,3% che pubblica DMARC.

Come controllo se il mio dominio resiste a un downgrade SMTP?

Eseguite dig TXT _mta-sts.yourdomain.com +short e cercate v=STSv1, e dig TLSA _25._tcp.your-mx-host +short per ogni host MX. Se entrambi sono vuoti, la vostra posta in ingresso si affida allo STARTTLS opportunistico e può essere degradata. Pubblicare una policy MTA-STS in modalità enforce, o un record DANE su una zona firmata, chiude il divario.

Letture correlate

• p=none è sufficiente? Pubblicare DMARC non equivale ad applicarlo. Il livello di autenticazione accanto a cui si colloca questo post.
• Quanto sono esposti i domini più trafficati al mondo allo spoofing email? La questione della presenza per il lato anti-spoofing.
• Quanti domini di primo piano limitano chi può emettere i loro certificati? Lo stesso metodo di DNS passivo, applicato ai record CAA.