MTA-STS e TLS-RPT: la sicurezza email che tutti ignorano

La quasi totalità delle guide sulla sicurezza email si ferma a SPF, DKIM e DMARC. Sono fondamentali, ma riguardano l'autenticazione del mittente, non la cifratura del canale. Quando il tuo server SMTP consegna a Gmail, la connessione TLS viene negoziata in modo opportunistico: se l'handshake fallisce, il messaggio viene comunque consegnato in chiaro. Un attaccante in posizione MITM (DNS poisoning, BGP hijack) può degradare la connessione a cleartext e leggere tutto. Qui entrano in gioco MTA-STS (RFC 8461) e TLS-RPT (RFC 8460): due standard del 2018 che la maggior parte dei domini italiani non ha ancora pubblicato. Vediamo come implementarli oggi sul tuo dominio in meno di trenta minuti.

Il problema: STARTTLS è opzionale

Quando un MTA mittente apre una connessione verso un MTA destinatario sulla porta 25, scambia il comando EHLO e legge le estensioni supportate. Se il destinatario annuncia 250-STARTTLS, il mittente può negoziare TLS. Se l'handshake fallisce, l'RFC 3207 dice che il mittente "should fall back to cleartext", e Postfix in default fa esattamente questo (smtp_tls_security_level = may). Un attaccante che intercetta la connessione può:

1. Riscrivere il banner 250-STARTTLS rimuovendolo (downgrade attack)
2. Iniettare un certificato self-signed che non viene comunque verificato (may non controlla CA)
3. Leggere il payload in chiaro e/o modificarlo

MTA-STS risolve esattamente questo: pubblica una policy nel DNS e tramite HTTPS che impone quale cifratura il destinatario accetta e cosa fare se fallisce.

Anatomia di MTA-STS

MTA-STS si compone di tre pezzi:

1. Un record DNS TXT su _mta-sts.tuodominio.it che annuncia la versione della policy
2. Un file di testo servito via HTTPS su https://mta-sts.tuodominio.it/.well-known/mta-sts.txt
3. Un certificato TLS valido (Let's Encrypt va benissimo) sul subdomain mta-sts.tuodominio.it

Il record DNS

_mta-sts.targetsmtp.it. 3600 IN TXT "v=STSv1; id=20260516120000;"

Il campo id è arbitrario ma deve cambiare ogni volta che modifichi la policy: i receiver lo usano come cache key. Convenzione: timestamp in formato compatto.

La policy

version: STSv1
mode: enforce
mx: mx1.targetsmtp.it
mx: mx2.targetsmtp.it
max_age: 604800

Tre modi disponibili:

• none: il dominio dichiara di non avere policy (usato per ritiro graduale)
• testing: i fallimenti vengono solo segnalati (via TLS-RPT) ma la consegna procede
• enforce: i fallimenti TLS causano il rifiuto della consegna

⚠️ Attenzione: parti SEMPRE da mode: testing per almeno due settimane. In enforce un errore in policy (es. tipo MX sbagliato) blocca tutta la posta in entrata. Lascia max_age basso (86400 = 1 giorno) all'inizio per poter rollback rapido.

Il file via HTTPS

Configurazione nginx minimale:

server {
    listen 443 ssl http2;
    server_name mta-sts.targetsmtp.it;
    ssl_certificate /etc/letsencrypt/live/mta-sts.targetsmtp.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.targetsmtp.it/privkey.pem;
    root /var/www/mta-sts;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        add_header Cache-Control "max-age=86400";
    }
}

Il certificato sul subdomain mta-sts. è obbligatorio e deve essere valido (CA pubblica, non scaduto, hostname matchante). Senza HTTPS valido la policy viene scartata silenziosamente.

TLS-RPT: ricevere i report

MTA-STS senza TLS-RPT è cieco: scopri di un problema solo quando un cliente ti chiama. TLS-RPT (RFC 8460) chiede ai mittenti di inviare report aggregati JSON a un indirizzo dichiarato nel DNS:

_smtp._tls.targetsmtp.it. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@targetsmtp.it"

I report arrivano una volta al giorno, in formato JSON compresso gzip, allegati a una mail con MIME type application/tlsrpt+gzip. Esempio reale di report ricevuto da Google:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-05-15T00:00:00Z",
    "end-datetime": "2026-05-15T23:59:59Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mx1.targetsmtp.it"],
      "policy-domain": "targetsmtp.it"
    },
    "summary": {
      "total-successful-session-count": 4823,
      "total-failure-session-count": 2
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "mx1.targetsmtp.it",
      "failed-session-count": 2
    }]
  }]
}

Categorie di failure più comuni

Implementazione passo passo

1. Crea subdomain mta-sts.tuodominio.it A/AAAA verso un webserver
2. Emetti cert Let's Encrypt: certbot certonly --nginx -d mta-sts.tuodominio.it
3. Crea /var/www/mta-sts/.well-known/mta-sts.txt con mode: testing
4. Pubblica TXT _mta-sts con id univoco
5. Pubblica TXT _smtp._tls con indirizzo report
6. Aspetta 24-48 ore, leggi i report
7. Quando i report sono puliti, passa a mode: enforce e aumenta id

💡 Suggerimento: per parsare automaticamente i TLS-RPT report usa parsedmarc che supporta sia DMARC che TLS-RPT e li carica su Elasticsearch/Splunk per dashboard storiche.

MTA-STS vs DANE

Esiste un'alternativa: DANE (RFC 7672), che pubblica il fingerprint del certificato nel DNS via record TLSA. È più potente di MTA-STS perché non dipende dalla CA pubblica, ma richiede DNSSEC sul dominio. Per la maggior parte degli scenari italiani MTA-STS è più pratico: non serve DNSSEC, non serve riemettere TLSA a ogni rotazione cert. I grandi mailer (Gmail, Microsoft, Yahoo) supportano entrambi. Pubblica MTA-STS oggi; se hai già DNSSEC, aggiungi anche DANE.

Strumenti di verifica

• aykevl MTA-STS checker
• Hardenize (controllo completo email security)
• CheckTLS
• kdig +short TXT _mta-sts.tuodominio.it

Riferimenti normativi

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

MTA-STS e TLS-RPT non sono obbligatori, ma sono parte dell'igiene 2026 di un dominio email professionale. Target SMTP pubblica automaticamente policy MTA-STS in enforce per tutti i domini cliente provisionati e processa i TLS-RPT report aggregando le anomalie in dashboard. Se la tua infrastruttura email non li ha ancora, fai il deploy questa settimana: trenta minuti di lavoro che chiudono una superficie d'attacco silenziosa.