The email files: Ricomincio da 3

ok, lo dico: sono stanco di mettere pezze.
Ogni settimana mi ritrovo con il rotolo di nastro isolante in una mano e l’estintore nell’altra, a tappare buchi in sistemi di posta progettati “con affetto”… ma senza un progetto. 😅
Spoiler: l’email non è “manda allegato e incrocia le dita”.
È un’infrastruttura critica. E quando la tratti come un giocattolo, arrivano: throttling, blocklist, utenti in panico, DPO sul pianerottolo e quel delizioso profumo di incidente.
Da oggi ricomincio da 3 (e vi porto con me):
Posta umana,
Posta applicativa,
Posta marketing.
Flussi separati, regole chiare, SEG davanti a tutto e Continuity quando il mondo decide di fare il lunedì.
Ho scritto un pezzo pratico (e un po’ sarcastico) per chi deve progettare davvero un sistema di posta: niente magie, solo architetture sensate, processi, sicurezza e compliance senza mal di stomaco.
👉 Titolo: “The Email Files: ricominicio da 3”

Se anche voi siete stanchi di vivere di cerotti, benvenuti nel club. 💌🔧🔥

(Framework pratico per progettare un sistema di posta che funzioni, regga agli urti e resti in regola)

lo so lo so. Lo so che lo sapete, ma a volte — dico a volte — quando pensate alla posta ci pensate un po’ “meno che professionalmente”. E siccome io non sarei io se non mi togliessi il dubbio, mi sono messo (scomodamente) nei panni di chi la posta aziendale la deve pensare, disegnare e far vivere: ogni giorno, con norme che cambiano, utenti creativi e attaccanti instancabili.

Questo articolo è un pezzo unico: niente spezzatini. È un percorso: partiamo dalle domande giuste, fissiamo i tre flussi da separare, innestiamo sicurezza e compliance, aggiungiamo Security Email Gateway e Continuity come best practice architetturali, e chiudiamo con checklist, runbook operativi, pattern decisionali e modelli copiabili. L’obiettivo è darti un framework con cui progettare (o riprogettare) la posta senza incrociare le dita.

0) Perché “ricominicio da 3”?

Domanda. Perché non “riparto da zero”? Risposta. Perché ogni volta che “ripartiamo da zero”, finiamo per mischiare mele e bulloni. Tre sono i flussi che contano davvero, tre i piani (organizzativo, tecnico, normativo) che li governano, tre gli errori ricorrenti che fanno male:

Mescolare i canali (umana, applicativa, marketing) “per comodità”.
Ignorare limiti e regole dei provider finché non scatta il throttling.
Dimenticare la compliance (retention, controlli, informativa) e trovarsi nei guai.

Ricominciare da 3 vuol dire: separare i canali, assegnare responsabilità, progettare regole per flusso, non per “strato tecnico”.

1) Qual è la mappa del problema?

Domanda. Come si imprime a fuoco la mappa mentale prima di toccare pulsanti? Risposta. Con tre domande:

Chi invia e chi riceve? (utenti, applicazioni, clienti, fornitori, PA)
Che contenuto scorre? (personale, aziendale, sensibile, commerciale)
Perché lo invia? (lavoro, transazione/avviso, promozione)

Da qui derivano i tre flussi: (A) Posta umana (User-Based), (B) Posta applicativa (Application-Based), (C) Posta di marketing (Bulk/Promozionale). Sono diversi per natura, rischi e norme: separarli non è un vezzo, è ingegneria.

2) Chi devo coinvolgere (subito) e perché?

IT Operations (domini, DNS, connettori, ibrido, monitoraggi).
Security/SOC (anti-phish, malware, BEC, DLP, cifratura, SIEM).
Compliance/Legal/DPO (basi giuridiche, retention, discovery, limiti ai controlli).
Marketing/CRM (consenso, preference center, deliverability).
HR (policy d’uso, formazione, gestione casi, on/off-boarding).

Domanda. Perché tutta questa gente per “un mail”? Risposta. Perché nulla è statico: cambiano norme, tecnologia e minacce. Senza questi attori attivi dal giorno 0, il progetto invecchia prima di nascere.

3) Flusso A — Posta “umana” (User-Based)

3.1 In cosa è diversa?

Domanda. Cosa rende “umana” la posta degli utenti? Risposta. Volumi variabili (non massiva), contenuti di ogni tipo (dal “ti chiamo dopo” al contratto strategico), impatto su brand, legal e sicurezza. Qui l’identità è persona, non servizio: policy e controlli devono rispettare proporzionalità e trasparenza.

3.2 Come distinguo posta aziendale e personale nella stessa inbox?

Domanda. Perché questa distinzione non è un cavillo? Risposta. Perché il mezzo è lo stesso, il significato giuridico no. Nel contesto lavorativo esistono limiti ai controlli del datore di lavoro: servono informativa, necessità, proporzionalità e garanzie (Corte EDU Bărbulescu v. Romania, 2017). In UE valgono i principi GDPR (art. 5), le basi giuridiche (art. 6, in particolare legittimo interesse con balancing test), e la disciplina del trattamento nel contesto occupazionale (art. 88) con le linee guida WP29/EDPB. In Italia si aggiunge lo Statuto dei Lavoratori, art. 4, e il documento di indirizzo del Garante (06/2024) su metadati e tempi contenuti di conservazione.

Traduzione operativa. Se mescoli personale e aziendale nella stessa casella, non puoi trattare “tutto” allo stesso modo. Devi definire cosa registri (metadati vs contenuti), perché, per quanto, chi accede e come si traccia l’eccezione. Prima si cercano alternative meno intrusive (metadati, intestazioni) e solo in casi giustificati si accede al contenuto.

3.3 Che sicurezza metto in ingresso/uscita?

Inbound

Anti-spam/malware, sandbox allegati, protezione URL.
Anti-impersonation (display name, domini look-alike), DMARC enforcement.

Outbound

DLP (pattern + contesto) e cifratura by policy (auto/on-demand).
Firme coerenti, journaling selettivo (laddove richiesto).

Identità & Telemetria

MFA, Conditional Access, alert su regole mailbox sospette.
Log verso SIEM, regole (wire fraud), playbook SOC.

3.4 Quali casi d’uso devo prevedere?

Contratti/Offerte → DLP + cifratura + journaling mirato; retention dedicata.
Customer care → mailbox condivise, code, audit quanto basta, KPI.
HR → canali dedicati, informativa chiara, controllo minimo e proporzionato.
PA/Legale → protocolli, formati, conservazione a norma, evidenze invio/ricezione.

4) Flusso B — Posta applicativa (Application-Based)

4.1 Che cos’è e cosa la rende delicata?

Domanda. Cosa rientra nella “posta delle macchine”? Risposta. Notifiche, reset, conferme d’ordine, bollette, alert, M2M via SMTP. È delicata perché:

l’autenticazione varia (dall’OAuth2 alla stampante del 2011);
i volumi possono essere massivi (throttling e reputazione a rischio);
le responsabilità sono diffuse (owner? IT? OT? Fornitore?).

Inventario prima di tutto: sorgenti, volumi, destinatari, orari, sicurezza, errori. Senza inventario non progetti: speri.

4.2 Quali modelli d’invio su Microsoft 365?

Client Submission (SMTP AUTH) via smtp.office365.com (preferisci OAuth 2.0).
Direct Send (senza auth) solo verso interni al tenant.
SMTP relay tramite smart host (on-prem/terzo). Limiti: throttling tipico ~30 msg/min e 10.000 destinatari/giorno per mailbox; pianifica code e backoff. Autenticazione: percorso di ritiro del Basic Auth per client submission; migra a OAuth 2.0.

4.3 E su Google Workspace?

SMTP Relay Service (smtp-relay.gmail.com) per app/dispositivi con auth per IP allowlist o credenziali. Limite: 100 destinatari/transaction + tetti giornalieri.

4.4 Quali buone pratiche trasversali?

Sottodomini dedicati (notify., m2m.) con SPF/DKIM/DMARC allineati.
IP separati per non trascinare giù “tutto” in caso di incidente.
TLS ovunque; segreti custoditi e ruotati.
Rate-limit e ritentativi robusti; gestione 4xx/5xx.
Telemetria: Postmaster, deferral, complaint, bounce reason.

4.5 Decision tree rapido (applicativo)

Domanda. La mia app può autenticarsi con OAuth2?

Sì → usa Client Submission o API moderne, sottodominio dedicato.
No → può stare dietro a SMTP Relay/smart host con allowlist IP + rate-limit?
Legacy senza TLS → isola dietro relay aziendale in LAN, cifra verso Internet al relay, monitora e pianifica phase-out.

5) Flusso C — Posta di marketing (Bulk/Promozionale)

5.1 Perché separarla sempre?

Perché vive di consenso/opt-out e reputazione dominio/IP. Miscelarla con posta umana o transactional brucia la deliverability del dominio primario.

5.2 Qual è la struttura consigliata?

ESP/MTA dedicato o servizio cloud per bulk.
Sottodominio dedicato (mktg.) con SPF/DKIM/DMARC allineati.
Warm-up IP, list hygiene, preference center.
One-Click Unsubscribe dove richiesto; monitoraggio complaint rate.

5.3 Warm-up pratico (esempio)

Domanda. Come inizio senza finire in spam? Risposta.

Settimana 1: 500–1.000/dì su domini “amici” (engagement alto).
Settimana 2–3: raddoppia progressivamente, mantieni open/click > 20% sui segmenti.
Settimana 4+: introduce nuove liste verificate; rimuovi hard bounce e inerti.
Mantieni complaint rate sotto 0,1% e mai oltre 0,3%.

5.4 Regole dei grandi provider (promemoria)

Google (dal 2024): SPF+DKIM+DMARC, one-click per promozionali >5.000/giorno, cura spam rate (<0,1%, mai ≥0,3%). I transactional sono esclusi dall’obbligo one-click.
Microsoft/Outlook (dal 2025): requisiti più rigidi per >5.000/giorno; enforcement su SPF/DKIM/DMARC.

6) Quale architettura di riferimento adotto?

6.1 Perché mettere un Security Email Gateway (SEG)?

Per avere una difesa stratificata e controlli coerenti sui tre canali:

Inbound: anti-phish mirato, sandbox, anti-impersonation, DMARC enforcement.
Outbound: DLP/cifratura uniformi, watermarking, journaling, log verso SIEM.
Routing separato: umana/transactional/marketing su percorsi/IP/sottodomini distinti.

Pattern top

SEG come MX → l’inbound passa qui; outbound via smart host sul SEG.
SEG parallelo → connettori per flussi specifici (es. transactional).
SEG solo outbound → quando l’inbound è già blindato altrove.

6.2 Perché serve un sistema di Continuity?

Perché la mail è canale critico. La continuity riduce RTO a minuti e RPO a (quasi) zero con spooling + webmail di emergenza (anche mobile) + backfill al ripristino. È coerente con ISO 22301, NIS2 e, per il finance, DORA.

Disegno pratico

MX → SEG → Provider; in parallelo, spooling su continuity.
Webmail di emergenza: SSO + fallback credenziali locali.
Invio in emergenza: IP pool separato per non “sporcare” i primari.
Backfill verificato; runbook di attivazione/chiusura.

7) DNS, autenticazioni e domini: che cosa non devo sbagliare?

7.1 DNS “a prova di dito”

Domanda. Come evito il classico incidente da record copiati a metà? Risposta.

SPF: evita la “millefoglie” (lookup >10). Centralizza su record per sottodominio.
DKIM: usa selector diversi per canali distinti (es. s=hum, s=txn, s=mkt).
DMARC: metti ruoli chiari dietro alle mailbox di rua/ruf e monitora davvero.
BIMI (se utile): attiva dopo DMARC in enforcement (non prima).
Rotazione chiavi: pianifica un calendario (evita fine anno).

7.2 “onmicrosoft.com” e similari

Domanda. Cosa faccio con i domini “di servizio” del tenant? Risposta.

Non esporre in esterno alias @tenant.onmicrosoft.com.
Evita che applicativi spediscano da domini “tecnici”.
Se devi ricevere su alias tecnici, isola e non miscelare con il dominio primario.

8) Identity & Auth per applicazioni: quali pattern scelgo?

Domanda. Devo aggiornare le app per OAuth2? Risposta. Sì, se puoi. Ottieni scoppi di sicurezza e audit migliori. Per i service principal:

Least privilege: solo scope necessari.
Secret → vault sicuro + rotazione; cert → emetti e ruota.
Conditional Access: consenti invio da reti attese, blocca geografie anomale.
Monitoraggio: log specifici per token, errori di auth, tentativi falliti.

9) Metriche, SLO e “termometro” della posta

Domanda. Come misuro se funziona davvero? Risposta. Definisci SLO (Service Level Objective) e error budget:

Disponibilità recapito (inbound/outbound) ≥ 99,9%.
Tempo medio di consegna (interna) < 60s p95.
Tempo di blocco link/allegati malevoli < 30s p95.
RTO continuity ≤ 15 min; RPO ≈ 0–5 min.
Click-rate su phishing simulato: target ↓ trimestre su trimestre.
Complaint rate marketing < 0,1% (mai ≥ 0,3%).
DMARC alignment: domini in enforcement 100% (per quelli in uso).
DLP: tasso FP/FN monitorato e ottimizzato.

10) Governance & Compliance: che cosa metto per iscritto?

Policy d’uso (personale vs aziendale, cifratura, segnalazioni, caselle di servizio).
Informativa (metadati raccolti, tempi, finalità, diritti, DPO).
Registro trattamenti separato per i tre flussi (finalità, basi giuridiche, retention, destinatari).
LIA per log/metadati; DPIA se i trattamenti sono invasivi.
Procedure di accesso eccezionale al contenuto (chi, quando, come, tracciamento, eventuale notifica).

11) Runbook d’incidente (brevi e usabili)

11.1 Phishing/BEC (Business Email Compromise)

Segnali. Mail sospette, regole inbox “strane”, richiesta cambio IBAN. Azioni.

Isola l’account (reset credenziali, revoca sessioni, MFA).
Cerca copie del messaggio (log, SEG), tira indietro dove possibile.
Blocca domini/URL allegati; alert a utenti coinvolti.
Forensics minimi (IP, user-agent, regole create).
Lezioni: regole anti-impersonation, banner di avviso, formazione mirata.

11.2 Data Loss via email

Segnali. Allegati con dati sensibili spediti all’esterno. Azioni.

DLP: blocco/quarantena o cifratura automatica.
Contatto con il mittente: spiegazione e canale alternativo.
Audit: chi, cosa, a chi, base giuridica, eventuale notifica interna/esterna.
Correzioni: arricchisci regole DLP/etichette, formi il reparto.

11.3 Blocco massivo / throttling del provider

Segnali. Code crescenti, NDR 4xx/5xx, reputazione IP a picco. Azioni.

Failover verso continuity per traffic umano/critico.
Riduci il burst, separa i canali, sospendi invii non critici.
Remediate la causa (lista sporca, autenticazioni, contenuti).
Rientro graduale con warm-up.

12) Settori: cosa cambia (in breve)

12.1 Pubblica Amministrazione

Albi/Protocolli: integra con processi formali.
Trasparenza: conservazione a norma.
Sicurezza: SEG fortemente consigliato; continuity per servizi al cittadino.

12.2 Sanità

Dati particolari: DLP rigoroso, cifratura automatica su certe categorie.
Transactional critici (referti/notifiche): canale separato con SLO stringenti.
Audit: traccia accessi amministrativi, minimizza i log “in chiaro”.

12.3 Manifattura / OT

M2M diffuso: inventario serio; relay locale per legacy.
Separazione forte tra IT e OT, monitoraggio dedicato.
Continuity: garantire ordini/spedizioni anche se il provider mail è giù.

12.4 Finanza (DORA)

Resilienza end-to-end: continuity testata, incident response cronometrata.
Logging e evidenze: journaling selettivo; discovery su richiesta autorità.
Fornitori: verifica requisiti e exit plan.

13) Pattern decisionali (semplificati)

13.1 Che faccio se la mia “posta di tutti” comincia a rallentare?

È marketing? → sposta su ESP dedicato, sottodominio e IP separati.
È transactional? → separa dominio/IP, implementa rate-limit e telemetria.
È umano? → verifica anti-impersonation, sandbox, DMARC; controlla code e limiti.

13.2 Ho app legacy senza TLS: le spengo?

Subito, no (se sono critiche). Metti davanti un relay aziendale che cifra a valle, segmenta, limita, monitora e pianifica phase-out con milestone.

13.3 Il management vuole “tutto accessibile sempre”

No: minimizzazione e proporzionalità (GDPR). Proponi metadati con tempi contenuti, accesso al contenuto solo eccezionale e tracciato, informativa chiara.

14) Modelli copiabili (da adattare)

14.1 Informativa “uso posta in azienda” (ridotta)

Finalità: sicurezza del sistema, continuità del servizio, diagnostica, prevenzione abusi.
Dati: metadati tecnici (mittente, destinatario, data/ora, dimensione, esiti recapito), log sicurezza; non si leggono contenuti salvo casi eccezionali.
Tempi: metadati conservati per periodi contenuti; estensioni motivate e tracciate.
Diritti: accesso/rettifica/limitazione; contatti DPO.
Controlli: solo se necessari e proporzionati; alternative meno intrusive privilegiate.

14.2 Registro trattamenti (estratto tipico)

Posta umana: base giuridica art. 6(1)(f) (legittimo interesse), finalità di sicurezza/continuità; retention metadati breve; accessi eccezionali tracciati.
Transactional: finalità contrattuali/legali; canale separato; telemetria.
Marketing: consenso/soft opt-in; unsubscribe; preference center; telemetria/complaint.

14.3 Retention (linee guida pragmatiche)

Metadati tecnici: finestre contenute (giorni, non mesi).
Contenuti: per categoria (contratti/offerte/progetti) in base a obblighi legali e necessità.
Legal hold: sospende i timer per dati in contenzioso.

15) Piano operativo (90 giorni) — versione estesa

0–30 giorni

Inventario flussi (umana/app/marketing), domini/sottodomini; mappa di owner.
Correggi SPF/DKIM/DMARC; attiva DMARC reporting e caselle di monitoraggio.
Extra-rapid hardening: anti-impersonation, banner “esterno”, link-rewriting.
Policy light; comunicazione interna (1 pagina, niente romanzi).

31–60 giorni

Separazione canali (sottodomini/IP/connettori); SEG messo in MX.
DLP + cifratura per uscite a rischio; journaling dove richiesto.
SMTP Relay/OAuth per app; relay on-prem per legacy; log→SIEM.

61–90 giorni

Marketing su ESP dedicato; one-click; warm-up; Postmaster & SNDS.
Continuity attivata e test trimestrale (simulazione down).
Table-top su phishing/BEC e fuga dati; lezioni apprese e tuning.

16) Antipattern (da appendere in corridoio)

Mischiare umana/transactional/marketing “perché sì”.
Lasciare stampanti/app inviare come utenti umani (o, peggio, del CFO).
Rompere SPF per eccesso di include/redirect.
Trattenere metadati per mesi “perché non si sa mai”.
Pensare che la continuity sia un “nice to have”.

17) Blueprint finale — il “3×3” con SEG & Continuity

A) Posta umana

MX → SEG → M365/Workspace; outbound via SEG/smart host.
Inbound: anti-phish, sandbox, anti-impersonation, DMARC enforcement.
Outbound: DLP + cifratura; journaling selettivo.
Continuity: spooling + webmail emergenza + backfill.
Compliance: informativa, retention differenziata, audit accessi amm.

B) Transactional/M2M

Sottodomini/IP dedicati (notify., m2m.), SPF/DKIM/DMARC allineati.
Invio: SMTP AUTH (OAuth) / Direct Send (interno) / SMTP Relay / MTA dedicato.
Rate-limit e ritentativi; telemetria; continuity per messaggi critici.

C) Marketing

ESP/MTA dedicato, sottodominio mktg..
One-Click per promozionali >5.000/giorno; complaint rate < 0,1% (mai ≥ 0,3%).
Mai condividere IP/dominio con posta umana.

Appendice 1 — Limiti e requisiti (promemoria sintetico)

Google: SPF+DKIM+DMARC; one-click per promozionali >5.000/giorno; spam rate < 0,1% (mai ≥ 0,3%); SMTP Relay: 100 RCPT/transaction + tetti giornalieri.
Microsoft: invio app via Client Submission (OAuth) / Direct Send (interno) / SMTP relay; throttling tipico ~30 msg/min e 10k destinatari/giorno; requisiti high-volume dal 2025.

Appendice 2 — Riferimenti legali essenziali (distinzione personale/aziendale)

Corte EDU – Bărbulescu v. Romania (2017): aspettativa di riservatezza; monitoraggi preannunciati, proporzionati, con garanzie.
GDPR: art. 5 (principi), art. 6 (basi giuridiche, in specie legittimo interesse), art. 88 (trattamenti nel contesto occupazionale); WP29/EDPB su trattamenti al lavoro.
Italia – Statuto dei Lavoratori, art. 4: controlli a distanza (condizioni/limiti).
Garante Privacy – 06/2024: metadati email dei lavoratori, tempi contenuti e accountability.

Appendice 3 — Checklist finale (da stampare)

Comune a tutti i flussi

SPF/DKIM/DMARC allineati su ogni (sotto)dominio.
Separazione: umana / applicativa / marketing (domini, IP, connettori).
SEG davanti al provider; Continuity con spooling, webmail emergenza, backfill.
TLS ovunque; segreti protetti e ruotati.
Log → SIEM; Postmaster; alert su deferral/bounce/complaint.
Policy & formazione continue.
BC/DR testato (table-top trimestrale).

Google Workspace

One-Click per promozionali >5.000/giorno; spam rate < 0,1%.
SMTP Relay: max 100 RCPT/transaction; gestisci i tetti giornalieri.

Microsoft 365

Scegli tra Client Submission (OAuth), Direct Send (interno), SMTP relay.
Pianifica i limiti: ~30 msg/min e 10k destinatari/giorno su SMTP AUTH.
Per marketing ad alto volume, segui i requisiti 2025 (SPF/DKIM/DMARC).

Chiusura

Separando chi manda, cosa manda e perché lo manda, la posta smette di essere “il coso per mandare allegati” e torna a essere quello che è: un’infrastruttura critica di business. Il Security Email Gateway ferma gli urti; la Continuity ti tiene in marcia quando il resto si ferma; la compliance evita che, oltre al downtime, tu debba anche spiegarti davanti al giudice.

Ricominciare da 3 è l’inizio. Da lì si torna all’uno — un sistema di posta che consegna valore, regge agli urti e non ti fa arrossire davanti al DPO. E sì, possiamo continuare a chiamarla “interdet”, ma con SPF/DKIM/DMARC a posto, SEG in prima linea e una continuity che non sia solo una promessa.