MTA-STS, TLS-RPT e BIMI: i passi successivi dopo DMARC

MTA-STS: consegna cifrata o niente

I server di posta cifrano con STARTTLS quando entrambi i lati lo supportano, ma tornano al testo in chiaro se l'offerta manca, e un attaccante sul percorso può toglierla. MTA-STS (RFC 8461) pubblica un impegno: «i miei host MX hanno sempre certificati validi; non consegnare senza TLS». Servono un record DNS e un piccolo file di testo su un server web:

; announces the policy; change id whenever the policy file changes
_mta-sts.example.com.  3600 IN TXT   "v=STSv1; id=20261013T1200"
; the web host that serves the policy file over HTTPS
mta-sts.example.com.   3600 IN CNAME static-host.example.

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

• mode: testing segnala i fallimenti ma consegna comunque; enforce rifiuta la consegna senza TLS valido; none ritira la policy.
• mx: una riga per ogni host MX, esattamente come nei record MX. Un *. iniziale corrisponde a un'etichetta, per i provider con molti host.
• max_age: per quanto i mittenti tengono la policy in cache, in secondi. Una settimana (604800) durante i test; diversi mesi quando è stabile.

1. Ottieni un certificato valido per mta-sts.example.com e pubblica il file in /.well-known/mta-sts.txt: va bene qualsiasi hosting statico.
2. Pubblica _mta-sts con un nuovo id (un timestamp è comodo).
3. Aggiungi il record TLS-RPT della sezione successiva e resta in testing da due a quattro settimane.
4. Quando i report sono puliti, passa mode a enforce e aggiorna l'id.

TLS-RPT: report sulla cifratura fallita

TLS-RPT (RFC 8460) chiede ai server mittenti di inviarti un riepilogo giornaliero delle loro connessioni TLS verso i tuoi server di posta: quante sono riuscite e perché le altre sono fallite — certificato scaduto, nome non corrispondente, STARTTLS assente, errore nel recupero della policy.

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Google, Microsoft e altri grandi provider inviano questi report come file JSON. Da solo il record non cambia nulla nella consegna, quindi è sicuro pubblicarlo per primo. Con MTA-STS in testing, è così che scopri se enforce romperebbe qualcosa.

BIMI: il tuo logo nella casella

BIMI (Brand Indicators for Message Identification) permette alle caselle compatibili di mostrare il tuo logo al posto di un'iniziale accanto ai messaggi che superano DMARC. Il record punta al logo e, di solito, a un certificato che dimostra che puoi usarlo:

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

• DMARC deve essere applicato: p=quarantine o p=reject sul dominio, senza pct sotto 100 e senza sp=none.
• Il logo è un SVG quadrato nel profilo ristretto «SVG Tiny Portable/Secure», servito via HTTPS. Una normale esportazione SVG di solito viene rifiutata.
• Gmail mostra il logo solo con un certificato: un VMC (Verified Mark Certificate), che richiede un marchio registrato, o un CMC (Common Mark Certificate), che richiede che il logo sia in uso da almeno un anno. Yahoo può mostrarlo anche senza.

In che ordine

1. SPF, DKIM e DMARC con p=none e report (vedi Come configurare DMARC).
2. TLS-RPT: gratuito, innocuo e utile fin dal primo giorno.
3. MTA-STS in testing, poi enforce quando i report TLS sono puliti.
4. DMARC portato a p=quarantine e poi a p=reject.
5. BIMI, se un logo nella casella per te vale il certificato.