MTA-STS e TLS-RPT per il dominio email

In breve: MTA-STS consente a un dominio ricevente di pubblicare una policy per richiedere TLS affidabile nella consegna SMTP tra server; TLS-RPT aggiunge report aggregati sugli errori TLS. Sono complementari a SPF, DKIM e DMARC: proteggono il trasporto MTA-to-MTA, non l’autenticazione del mittente.

In sintesi

MTA-STS consente a un dominio ricevente di pubblicare una policy per richiedere TLS affidabile nella consegna SMTP tra server; TLS-RPT aggiunge report aggregati sugli errori TLS. Sono complementari a SPF, DKIM e DMARC: proteggono il trasporto MTA-to-MTA, non l’autenticazione del mittente.

Come funziona MTA-STS

MTA-STS pubblica prima un record TXT su _mta-sts.example.com che contiene almeno la versione e un identificatore di policy, per esempio v=STSv1; id=20260816. I mittenti compatibili usano quell’identificatore per capire se la policy è cambiata.

Il contenuto completo viene recuperato via HTTPS dall’host mta-sts.example.com nel percorso /.well-known/mta-sts.txt. La policy definisce la versione, la modalità (testing, enforce o none), gli MX ammessi e max_age. L’host HTTPS deve essere raggiungibile e presentare un certificato valido: se il file non è disponibile o non è coerente, la protezione non funziona come previsto.

Come funziona TLS-RPT

TLS-RPT usa un record TXT separato, normalmente su _smtp._tls.example.com, con versione TLSRPTv1 e uno o più URI di report. Un esempio è v=TLSRPTv1; rua=mailto:tls-report@example.com. I sistemi mittenti che supportano lo standard possono inviare statistiche e dettagli sugli errori di routing, DNS, STARTTLS, certificato e validazione MTA-STS.

I report servono soprattutto a osservare cosa accadrebbe o cosa sta accadendo in produzione. Prima di passare a enforce, è prudente usare una fase di testing, verificare gli MX pubblicati e leggere i report per evitare di bloccare posta legittima a causa di una policy errata.

Checklist di configurazione

1. Controlla MX e relativi hostname: devono coincidere con i pattern dichiarati nella policy.
2. Pubblica _mta-sts e verifica il TXT direttamente sui nameserver autorevoli.
3. Configura mta-sts.example.com su HTTPS e controlla certificato, redirect e contenuto del file policy.
4. Pubblica _smtp._tls per TLS-RPT e assicurati che la casella o endpoint di raccolta sia realmente monitorato.
5. Inizia con mode: testing, osserva gli errori e correggi gli MX prima di usare mode: enforce.
6. Quando cambi la policy, aggiorna l’id del record TXT in modo che i mittenti rilevino la nuova versione.

Errori da evitare

• Usare RFC SMTP/IMAP generici come se descrivessero MTA-STS: le specifiche dedicate sono RFC 8461 e RFC 8460.
• Confondere MTA-STS con DMARC: il primo riguarda TLS nella consegna tra MTA, il secondo l’autenticazione e la policy del dominio mittente.
• Attivare enforce prima di aver verificato tutti gli MX, inclusi servizi di backup o provider esterni.
• Lasciare scadere il certificato HTTPS di mta-sts o pubblicare un file policy con hostname non corrispondenti agli MX reali.
• Raccogliere TLS-RPT senza processare i report: il valore operativo è proprio individuare errori e downgrade.

Verifica finale

La configurazione è pronta quando record TXT, policy HTTPS e MX sono coerenti, i report TLS-RPT arrivano e non mostrano errori sistematici. Conserva una procedura di rollback: in caso di cambio provider email, aggiorna prima MX e policy, verifica in testing e solo dopo applica nuovamente l’enforcement.

Guide Xlogic correlate

• Record MX presenti ma email non ricevute
• Autodiscover punta al provider email sbagliato
• DMARC rua non riceve report

Fonti

• RFC 8461 — SMTP MTA Strict Transport Security
• RFC 8460 — SMTP TLS Reporting

Domande frequenti