SPF, DKIM e DMARC dimostrano chi ha inviato un messaggio. MTA-STS e TLS-RPT proteggono il messaggio mentre è in viaggio: si assicurano che la connessione che trasporta la tua posta sia davvero cifrata e ti avvisano quando non lo è. MTA-STS (SMTP MTA Strict Transport Security, definito nella RFC 8461) permette a un dominio di dichiarare che la posta destinata ai suoi server deve arrivare tramite TLS con un certificato valido. TLS-RPT (SMTP TLS Reporting, RFC 8460) chiede ai server mittenti di inviare un report giornaliero sull'esito positivo o negativo di quella cifratura. Nessuno dei due autentica il contenuto: insieme chiudono una lacuna diversa, quella che il semplice TLS opportunistico lascia spalancata. Ecco cosa fa ciascuno e come introdurli senza compromettere la tua posta in entrata.
In breve#
MTA-STS è una policy che pubblichi affinché i server di posta altrui cifrino la posta che inviano a te. Ha due componenti: un record TXT DNS su _mta-sts.yourdomain.com che segnala l'esistenza della policy, e un file di policy ospitato in HTTPS su https://mta-sts.yourdomain.com/.well-known/mta-sts.txt che elenca i tuoi hostname MX, una modalità (none, testing o enforce) e per quanto tempo tenerlo in cache. TLS-RPT è un secondo record TXT su _smtp._tls.yourdomain.com che indica un indirizzo a cui inviare report giornalieri sull'andamento di quelle connessioni TLS. L'introduzione sicura ricalca quella di DMARC: pubblica prima in modalità testing, leggi i report TLS-RPT finché non sei certo che ogni connessione negozi TLS senza problemi, poi passa a enforce.
Il monitoraggio check-up del dominio mostra se il tuo record TXT _mta-sts è pubblicato nell'ambito del controllo giornaliero, accanto a SPF, DKIM, DMARC e BIMI. Non scarica il file della policy HTTPS né legge i report TLS-RPT, quindi continua a verificarli tu.
La lacuna che MTA-STS colma#
L'SMTP moderno cifra già gran parte della posta in transito con STARTTLS: il server mittente chiede "supporti TLS?", il ricevente risponde di sì e i due negoziano un canale cifrato. Il problema è che questo handshake è opportunistico e non autenticato. Se una delle due parti non offre TLS, la posta ripiega sul testo in chiaro invece di fallire. Peggio ancora, un attaccante che si trova tra i due server può eliminare dalla conversazione l'offerta di STARTTLS (un attacco di downgrade) e il server mittente, non vedendo alcun TLS disponibile, recapita tranquillamente il messaggio in chiaro. Nemmeno il certificato viene verificato, quindi un man-in-the-middle può presentare il proprio e intercettare la connessione.
MTA-STS risolve entrambe le debolezze. Pubblicando una policy, dici ai mittenti conformi: la posta per questo dominio deve viaggiare su TLS, il server ricevente deve presentare un certificato valido e corrispondente a uno dei miei hostname MX elencati e, se queste condizioni non sono soddisfatte, non recapitare: rimanda e riprova, senza ripiegare sul testo in chiaro. Poiché la policy viene recuperata in HTTPS, il suo stesso certificato fa da ancora di fiducia, ed è questo che impedisce a un attaccante di falsificarla o eliminarla. Il risultato è che né un intercettatore passivo né un attaccante attivo che tenta il downgrade possono più costringere la tua posta in entrata a viaggiare in chiaro.
Cosa aggiunge TLS-RPT#
Da solo, MTA-STS è applicazione della policy senza visibilità: diresti ai mittenti di rifiutare le connessioni non sicure, ma non avresti modo di vedere quanto spesso succede davvero o quali mittenti stanno fallendo. TLS-RPT è il canale di feedback. Funziona esattamente come i report aggregati di DMARC e si abbina in modo naturale all'abitudine di leggere i report DMARC.
Quando pubblichi un record TLS-RPT, i mittenti che aderiscono ti inviano un report JSON giornaliero che riassume tutte le sessioni TLS aperte verso i tuoi host MX: quante sono riuscite, quante sono fallite e, soprattutto, perché sono fallite. Un report può mostrare un certificato scaduto su uno dei tuoi server MX, una mancata corrispondenza dell'hostname, una negoziazione STARTTLS interrotta o un problema nel recupero della policy. Sono esattamente le informazioni che ti servono prima di osare il passaggio di MTA-STS a enforce, perché un errore in modalità enforce significa posta in entrata differita o rimbalzata. È TLS-RPT a rendere l'introduzione sicura invece che un salto nel buio.
Configurare MTA-STS: il record DNS e il file di policy#
Per MTA-STS servono tre elementi: un record DNS, un file di policy e un sottodominio che ospiti il file in HTTPS.
1. Il record TXT DNS. Pubblica un record TXT su _mta-sts.yourdomain.com. Il suo compito è modesto: annuncia che esiste una policy e contiene un id che i mittenti usano per accorgersi quando la policy cambia.
_mta-sts.example.com. TXT "v=STSv1; id=20260725090000"
L'id è una stringa arbitraria di massimo 32 caratteri alfanumerici. La convenzione comune è usare un timestamp. L'unica regola che conta: ogni volta che modifichi il file di policy, cambia l'id. I mittenti tengono in cache la tua policy, e un nuovo id è il segnale che dice loro di recuperarla di nuovo. Se dimentichi di aggiornarlo, le tue modifiche potrebbero passare inosservate per tutta la durata del tuo max_age.
2. Il file di policy. Ospita un file di testo semplice nel percorso fisso https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Il file elenca la modalità, ogni hostname MX valido e la durata della cache:
version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400
Ogni riga mx deve corrispondere a un hostname dei record MX del tuo dominio, e la forma con carattere jolly (*.example.com) corrisponde a una sola etichetta, quella più a sinistra. Ogni host MX che elenchi deve servire un certificato attualmente valido, con catena fino a una CA pubblica e corrispondente al suo hostname: altrimenti un mittente in modalità enforce lo rifiuterà. Il max_age è la durata della cache in secondi; la RFC 8461 consente valori fino a 31557600 (circa un anno). Tienilo basso (più o meno un giorno) durante i test, così le modifiche si propagano in fretta, poi aumentalo quando ti senti sicuro di enforce: i riceventi come Google consigliano un max_age lungo in produzione, anche se il valore esatto lo scegli tu.
3. Il sottodominio mta-sts in HTTPS. Il file di policy deve essere raggiungibile in HTTPS sul sottodominio mta-sts, con un certificato valido per mta-sts.yourdomain.com. In pratica punti quel sottodominio (tramite A/AAAA o CNAME) verso ciò che serve il file, di solito un piccolo host statico o una CDN, e ti assicuri che risponda con Content-Type: text/plain. Molti provider DNS e di hosting offrono ormai un'opzione MTA-STS gestita che si occupa per te del file e del certificato.
Configurare TLS-RPT#
TLS-RPT è di gran lunga il più semplice dei due: un solo record TXT, nessun file di policy.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
Il tag rua indica dove vanno i report. Accetta un indirizzo mailto:, un endpoint https: che riceve i report tramite POST, oppure un elenco di entrambi separato da virgole. Il JSON grezzo di TLS-RPT è denso, quindi la maggior parte dei team punta rua verso un servizio di monitoraggio che trasforma i report in una dashboard leggibile, nello stesso modo in cui i report DMARC di solito finiscono in un parser anziché nella casella di una persona. Puoi pubblicare TLS-RPT da solo, e vale la pena farlo prima di MTA-STS: ti dà un quadro dello stato attuale del tuo TLS senza alcun rischio per il flusso della posta.
Introdurre MTA-STS e TLS-RPT in sicurezza#
L'ordine delle operazioni per MTA-STS e TLS-RPT conta più dei record stessi: se lo sbagli, puoi far ritardare la tua stessa posta in entrata. Segui la stessa disciplina di monitoraggio prima e applicazione poi che regola una buona implementazione di DMARC.
1. Pubblica prima TLS-RPT. Senza ancora una policy MTA-STS, i report ti dicono semplicemente quanta della tua posta in entrata usa già TLS e se qualcuno dei tuoi certificati MX è configurato male. Sistema subito ciò che è evidente.
2. Pubblica MTA-STS in modalità testing. Aggiungi il record DNS e il file di policy con mode: testing. In questa modalità i mittenti valutano la tua policy e segnalano gli errori tramite TLS-RPT, ma recapitano comunque la posta normalmente. Nel flusso della tua posta non cambia nulla: stai solo raccogliendo dati. Resta in questa fase abbastanza a lungo da coprire un ciclo completo dei tuoi corrispondenti abituali, idealmente un paio di settimane.
3. Leggi i report TLS-RPT e correggi gli errori. Tieni d'occhio problemi di certificato, mancate corrispondenze dell'hostname e host MX che hai dimenticato di elencare. Ogni errore in modalità testing è un errore che avresti causato in modalità enforce. Continua a intervenire su certificati e file di policy finché i report non sono puliti.
4. Passa a mode: enforce. Quando gli errori sono cessati, modifica il file di policy impostando enforce e aggiorna l'id nel record DNS, così i mittenti recuperano di nuovo il file. Da questo momento i mittenti conformi rifiuteranno di recapitare su una connessione non autenticata o sottoposta a downgrade. Valuta di aumentare ora il max_age per una protezione più forte contro i tentativi di downgrade.
Dove si collocano rispetto a SPF, DKIM e DMARC#
Vale la pena essere precisi su ciò che MTA-STS e TLS-RPT fanno e non fanno, perché è facile archiviarli alla voce "deliverability" e aspettarsi la cosa sbagliata.
SPF, DKIM e DMARC rispondono alla domanda questo messaggio arriva davvero da chi dice di essere?: autenticano identità e contenuto. MTA-STS e TLS-RPT rispondono a una domanda diversa: la connessione che ha trasportato questo messaggio era davvero cifrata e verificata?: proteggono la riservatezza in transito. I due livelli sono complementari e indipendenti. Un messaggio può superare DMARC viaggiando in chiaro, e può viaggiare su TLS imposto senza superare DMARC. Una configurazione completa li richiede entrambi.
Due precisazioni oneste. Primo, MTA-STS e TLS-RPT non fanno parte dei requisiti per i mittenti di grandi volumi di Google e Yahoo entrati in vigore nel 2024: quelli impongono SPF, DKIM, DMARC, disiscrizione in un clic e un basso tasso di spam, non policy di sicurezza del trasporto. Detto questo, i principali provider pubblicano e rispettano MTA-STS come riceventi, quindi una policy che pubblichi viene davvero applicata da Gmail e da altri quando recapitano a te. Secondo, MTA-STS non è un rimedio contro la cartella spam. Rafforza la sicurezza del trasporto in entrata; da solo non migliora il posizionamento del tuo marketing in uscita. Il posizionamento dipende sempre da reputazione del mittente, coinvolgimento e igiene della lista, e se la tua posta finisce nello spam i motivi stanno in quei segnali, non nella tua configurazione TLS. Considera MTA-STS e TLS-RPT il capitolo sulla sicurezza del trasporto di un dominio di invio maturo: vale la pena occuparsene, ma sono distinti dalle leve della guida alla deliverability che spostano davvero il posizionamento.
Se vuoi un'analogia, MTA-STS è uno stretto parente di DANE, il metodo più vecchio, basato su DNSSEC, per applicare TLS all'SMTP. Entrambi puntano allo stesso problema di downgrade; MTA-STS è stato progettato perché i domini senza DNSSEC potessero ottenere comunque gran parte della protezione, usando invece il sistema dei certificati web. Se usi già DANE potresti non aver bisogno di MTA-STS, ma i due possono coesistere.
Domande frequenti
01MTA-STS sostituisce SPF, DKIM o DMARC?
No: operano su livelli diversi e ti servono entrambi. SPF, DKIM e DMARC autenticano il mittente e il contenuto di un messaggio, dimostrando che arriva davvero dal tuo dominio e che non è stato alterato. MTA-STS e TLS-RPT proteggono il trasporto: obbligano la connessione che porta il messaggio a usare TLS verificato e segnalano quando non succede. Un messaggio ha bisogno di autenticazione e di recapito cifrato, quindi MTA-STS affianca DMARC senza sostituirne alcuna parte.
02MTA-STS e TLS-RPT sono richiesti da Google e Yahoo?
Non nell'ambito dei requisiti del 2024 per i mittenti di grandi volumi, che impongono SPF, DKIM, DMARC, disiscrizione in un clic e un tasso di spam inferiore allo 0,3%: MTA-STS non è in quell'elenco. I grandi provider, però, pubblicano essi stessi policy MTA-STS e rispettano la tua come riceventi, quindi una policy che pubblichi viene davvero applicata da Gmail e da altri. È una buona pratica consigliata per un dominio di invio maturo, ma non una condizione formale per raggiungere la posta in arrivo.
03Qual è la differenza tra MTA-STS e DANE?
Entrambi applicano TLS all'SMTP in entrata e difendono dagli attacchi di downgrade; differiscono nel modo in cui stabiliscono la fiducia. DANE pubblica le informazioni sul certificato nel DNS e si affida a DNSSEC per rendere quei record a prova di manomissione. MTA-STS evita il requisito di DNSSEC servendo la sua policy in HTTPS e usando il normale sistema dei certificati web come ancora di fiducia. MTA-STS è in genere più facile da implementare per i domini senza DNSSEC; i due possono anche funzionare insieme.
04MTA-STS migliorerà il mio posizionamento nella posta in arrivo?
Non direttamente. MTA-STS è un controllo di sicurezza del trasporto per la posta che entra nel tuo dominio: non cambia il modo in cui viene filtrato il tuo marketing in uscita. Il posizionamento dipende da reputazione del mittente, coinvolgimento, tassi di segnalazioni e qualità della lista. Vale la pena configurare MTA-STS per sicurezza e completezza, ma se la tua posta finisce nello spam la soluzione sta nell'igiene della lista e nella reputazione, non nella tua policy TLS.
MTA-STS e TLS-RPT rafforzano i canali in cui viaggia la tua posta, ma la posta in arrivo si conquista con la qualità della lista. La verifica email gratuita intercetta domini morti ed errori di battitura prima che generino bounce, e il piano Free esegue l'intero processo di verifica sulla tua lista: un dominio sicuro e ben autenticato ottiene un buon posizionamento solo quando la lista che ha dietro è pulita.
