Come configurare MTA-STS e TLS-RPT

Come configurare MTA-STS e TLS-RPT per la sicurezza delle email

MTA-STS consente a un dominio ricevente di indicare ai sistemi di posta mittenti quali server possono ricevere i suoi messaggi e che le connessioni devono usare TLS affidabile. TLS-RPT aggiunge la funzione di reportistica: i mittenti che aderiscono allo standard possono inviarti informazioni sugli errori di consegna TLS e sui problemi relativi alle policy. Se stai cercando come configurare MTA-STS e TLS-RPT per proteggere le email, inizia dalla configurazione della posta in entrata, non da un record DNS.

Queste misure non sostituiscono SPF, DKIM o DMARC. Intervengono su un’altra fase del percorso: la connessione crittografata tra i server di posta. Una policy che indica un host MX obsoleto o configurato male può causare problemi di consegna, quindi verifica l’intera configurazione prima di attivare l’applicazione obbligatoria della policy.

1. Verifica che la configurazione del servizio di posta sia pronta

Per prima cosa, controlla i record MX attuali del dominio. Elenca tutti gli hostname a cui puntano, inclusi quelli usati per la ridondanza o la consegna regionale. Se la posta in entrata è gestita dal tuo provider, chiedigli di confermare quali nomi MX devono essere inclusi nella policy MTA-STS e se ognuno supporta TLS con un certificato valido.

Verifica i nomi, non solo il marchio del provider. Un dominio potrebbe avere record MX come mx1.mail.example.com e mx2.mail.example.com, mentre il provider gestisce anche altri host non elencati per il tuo dominio. La policy deve includere gli hostname MX che possono ricevere la posta destinata al dominio.

Controlla il certificato e la configurazione TLS di ogni host elencato. Il certificato deve essere considerato affidabile e valido per l’hostname MX a cui si connette il sistema di posta mittente. Un certificato valido per il sito web del provider, ma non per il suo server di posta, non è un’alternativa adeguata.

Chiedi anche al provider se sono previsti cambiamenti agli host. Se durante la configurazione è prevista la sostituzione di un hostname MX, aspetta di avere l’elenco definitivo oppure concorda con il provider l’aggiornamento della policy. Un host sostitutivo non incluso nella policy può causare problemi di consegna quando un mittente avrà memorizzato una policy in modalità di applicazione obbligatoria.

2. Pubblica una destinazione per i report TLS-RPT

Prima di pubblicare il record DNS, scegli dove ricevere i report. Puoi usare una casella di posta in grado di riceverli oppure un servizio di reportistica TLS che fornisca un indirizzo o una destinazione HTTPS. Verifica che la destinazione sia monitorata e che il tuo sistema di posta accetti i report in entrata.

Pubblica un record TXT all’indirizzo _smtp._tls.example.com, sostituendo example.com con il tuo dominio. Questo record DNS TLS-RPT indica ai mittenti dove inviare i report. Per indicare una destinazione email, usa questo formato: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Se il servizio di reportistica fornisce una destinazione diversa, usa esattamente l’URI indicato.

Se possibile, usa una casella separata dalla posta quotidiana di una persona. I report TLS possono arrivare come allegati strutturati; una casella dedicata semplifica la gestione delle regole di accesso, la conservazione dei messaggi e l’assegnazione delle verifiche all’amministratore responsabile della consegna della posta. Prima di pubblicare il record, controlla le impostazioni di archiviazione e filtraggio.

Le modifiche DNS potrebbero richiedere del tempo per diventare visibili, perché i resolver memorizzano i record in cache in base al loro TTL. Dopo aver pubblicato il record, interroga il DNS autorevole e un resolver pubblico per verificare che entrambi restituiscano il valore TXT previsto. Un errore nel nome del record può impedire ai mittenti di trovare la destinazione.

3. Ospita il file della policy MTA-STS

Inserisci la policy all’indirizzo https://mta-sts.example.com/.well-known/mta-sts.txt, sostituendo example.com con il tuo dominio. La policy MTA-STS per la posta deve essere raggiungibile tramite HTTPS e il certificato deve essere valido per l’hostname mta-sts.example.com. Un file nella normale directory principale del sito web non soddisfa questo requisito.

La policy è un file di testo semplice. Per una prima prova, usa campi come questi:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Sostituisci i nomi MX di esempio con gli host effettivamente usati per la posta in entrata del tuo dominio. Il valore max_age indica per quanti secondi un mittente può conservare la policy in cache; nell’esempio sopra, un giorno. Un periodo iniziale più breve può rendere più semplice modificare la policy di test, mentre con un periodo più lungo i mittenti potrebbero conservarla più a lungo.

Prima di applicare la policy, usa la modalità testing. In questa modalità, i mittenti possono segnalare eventuali problemi senza interpretare la policy come un obbligo di rifiutare i messaggi che non possono essere consegnati rispettando le condizioni TLS richieste. Prova a raggiungere l’URL dall’esterno della rete e verifica che il file venga restituito senza richiedere l’accesso, generare un ciclo di reindirizzamenti o produrre un errore dell’applicazione web.

4. Pubblica il record di individuazione MTA-STS

I mittenti individuano la policy tramite un record TXT all’indirizzo _mta-sts.example.com. Il valore include la versione e un identificativo della policy, ad esempio: v=STSv1; id=20261104a. Scegli un identificativo che possa essere rintracciato nel registro delle modifiche, anziché riutilizzarne uno vecchio.

Modifica l’identificativo ogni volta che pubblichi una versione aggiornata del file della policy. In questo modo segnali ai sistemi mittenti che devono verificare la presenza di una policy aggiornata, invece di affidarsi solo a una copia memorizzata nella cache. L’identificativo è un segnale di individuazione: non sostituisce il file della policy né il suo hosting tramite HTTPS.

Pubblica il record solo dopo aver verificato che il file della policy sia raggiungibile all’URL richiesto. Poi interroga il record TXT e apri l’URL da una connessione esterna. Il record DNS e il file devono descrivere la stessa configurazione attuale: un identificativo aggiornato che rimanda a un file mancante o obsoleto corrisponde comunque a una configurazione non funzionante.

5. Verifica l’individuazione, la policy e la copertura degli MX

Verifica separatamente ogni elemento. Interroga i record TXT _smtp._tls e _mta-sts, richiedi la policy tramite HTTPS e confronta ogni riga mx: con i record MX attivi. Questo controllo in tre passaggi permette di individuare errori che una semplice ricerca DNS non rileverebbe.

Verifica che la risposta HTTPS presenti un certificato affidabile per l’hostname MTA-STS e che il file contenga i campi previsti. Controlla poi che ogni host MX supporti TLS e abbia un certificato valido per il suo hostname esatto. Se il provider usa diversi nomi MX per la posta in entrata, provali tutti invece di presumere che abbiano una configurazione dei certificati identica.

Registra i risultati, inclusi i valori DNS, l’identificativo della policy, gli hostname MX e la data del controllo. In questo modo, il prossimo amministratore avrà un riferimento utile se in seguito i report segnaleranno un problema. Per altre informazioni sulla configurazione della posta, è possibile aggiungere il feed RSS del blog di YourTrend all’elenco delle risorse del team.

6. Esamina i report prima di applicare la policy

Mantieni la policy in modalità testing mentre raccogli i report TLS-RPT e verifichi il normale flusso della posta. I report possono segnalare sistemi mittenti che hanno riscontrato un problema con il certificato, una difficoltà nella negoziazione TLS o una discrepanza tra gli host MX dichiarati e quelli indicati nella policy. Un report è un elemento da approfondire, non un’istruzione automatica per modificare un record DNS.

Esamina il periodo a cui si riferisce il report, il dominio interessato dalla policy e i dettagli dell’host ricevente. Confrontali con l’elenco dei tuoi MX e con la configurazione del provider. Se manca un host legittimo, aggiorna il file della policy e cambia l’ID della policy; se il certificato è errato, chiedi al provider di correggerlo prima di attivare l’applicazione obbligatoria.

Prova anche a inviare messaggi dai sistemi di posta da cui dipende la tua organizzazione, ad esempio quelli di un partner commerciale o di un servizio separato sotto il tuo controllo. Verifica che i messaggi arrivino e che i registri della posta in entrata mostrino connessioni TLS riuscite. Il fatto che nella casella dei report non arrivino segnalazioni non dimostra, da solo, che tutti i mittenti abbiano verificato la tua policy.

Definisci un periodo di verifica adeguato al volume della posta e alle esigenze operative. Non esiste un numero universale di giorni che garantisca la presenza nei report di tutti i sistemi mittenti, quindi non considerare un intervallo di tempo specifico come prova di copertura completa. Registra cosa hai verificato e quali mittenti noti hanno consegnato correttamente durante il test.

7. Applica la policy, monitora e mantieni la configurazione

Quando l’elenco MX, i certificati, la policy HTTPS e i risultati dei test sono pronti, modifica la modalità della policy da testing a enforce. Pubblica il file aggiornato e un nuovo identificativo _mta-sts. Dopo l’aggiornamento, verifica entrambi dall’esterno della rete e continua a controllare i report TLS-RPT e i registri del flusso di posta.

Con l’applicazione della policy, ci si aspetta che un sistema mittente compatibile con MTA-STS usi TLS e verifichi l’host ricevente secondo quanto indicato nella policy. Se non è in grado di farlo, la consegna potrebbe subire ritardi mentre il mittente riprova, invece di avvenire tramite una connessione non protetta. Coordina la modifica con il provider di posta e con il team di supporto, così sapranno come diagnosticare eventuali ritardi di consegna.

Documenta le procedure di manutenzione insieme all’URL della policy e ai record DNS. Quando cambia un host MX, aggiorna la policy prima di affidarti al nuovo host; quando viene rinnovato un certificato, verifica che copra l’hostname corretto e che la catena di attendibilità sia valida. Se l’applicazione della policy fa emergere un problema, tornare alla modalità testing può ridurne l’impatto, ma aggiorna l’ID della policy e verifica che venga fornito correttamente il file modificato.

Assegna a una persona la responsabilità di controllare la casella o il servizio di reportistica e di tenere traccia delle modifiche a DNS e certificati. Se pubblichi note operative o aggiornamenti sul servizio di posta per i colleghi, anche il feed del blog di YourTrend può essere aggiunto alle fonti da seguire. Avere un referente preciso e una procedura documentata per le modifiche agli MX semplifica la gestione del prossimo rinnovo o della migrazione a un altro provider.