L’e-mail: come funziona, da dove viene, dove va

Ha più di 50 anni ed è ancora lo strumento più importante del mondo degli affari: come un’e-mail trova la sua strada, perché falsificarla era così facile e che cosa sta cambiando.

Architettura e ruoli

MUA → MSA (submission 587/465) → MTA → risoluzione MX nel DNS → MTA del destinatario (25, STARTTLS) → MDA → IMAP 993 verso il MUA — MUA, MSA, MTA, MDA: i ruoli nel sistema di posta.

Ruolo	Compito	Protocollo / porta
MUA (Mail User Agent)	programma di posta, webmail, app	submission 587 (STARTTLS) o 465 (TLS implicito, RFC 8314)
MSA / MTA	accettazione autenticata, inoltro tra server	SMTP 25, STARTTLS opportunistico (RFC 3207)
MDA	deposito nella casella, filtri (p. es. Sieve)	locale, LMTP
Accesso	lettura e sincronizzazione	IMAP 993 (IMAP4rev2, RFC 9051), POP3 995, JMAP (RFC 8620/8621)

Consegna: l’MTA mittente risolve il record MX del dominio destinatario (ripiego su A/AAAA se non esiste MX; un «null MX» secondo la RFC 7505 dichiara che un dominio non riceve posta) e prova i server in ordine di priorità. Gli errori temporanei (4xx) comportano nuovi tentativi per ore o giorni, quelli permanenti (5xx) un avviso di mancato recapito.

Busta e intestazione: due mittenti

SMTP separa la busta (MAIL FROM, anche Return-Path o RFC5321.MailFrom) dall’intestazione del messaggio (From:, RFC5322.From). L’essere umano vede solo l’intestazione. Proprio questa lacuna è sfruttata dalle falsificazioni, e proprio qui interviene l’allineamento di DMARC.

S: 220 mx.example.ch ESMTP
C: EHLO mail.eam.ch
S: 250-STARTTLS
C: STARTTLS
   … handshake TLS …
C: MAIL FROM:<bounce@eam.ch>
C: RCPT TO:<cliente@example.ch>
C: DATA
   From: eam.ch <noreply@eam.ch>
   Subject: …

Storia e standard

1971 Ray Tomlinson, BBN: posta tra computer su ARPANET, separatore @.
1982 RFC 821 (SMTP) e RFC 822 (formato dei messaggi).
1984/1988 POP (RFC 918), IMAP (Mark Crispin, 1986; IMAP2 RFC 1064, 1988).
1992/1996 MIME (RFC 1341, oggi RFC 2045–2049): allegati, set di caratteri, messaggi in più parti.
1995 ESMTP (RFC 1869): estensioni come SIZE, 8BITMIME, poi AUTH.
1999/2002 STARTTLS per SMTP (RFC 2487, oggi RFC 3207).
2008 Le RFC 5321/5322 sostituiscono le RFC 2821/2822 (standard SMTP attuale).
2006–2015 SPF (RFC 4408 → 7208, 2014), DKIM (RFC 4871 → 6376, 2011), DMARC (RFC 7489, 2015, informativa).
2012 Indirizzi internazionalizzati (SMTPUTF8, RFC 6531).
2015–2019 DANE per SMTP (RFC 7672), MTA-STS (RFC 8461) e TLS-RPT (RFC 8460, entrambe 2018), ARC (RFC 8617, sperimentale).
2018 RFC 8314: TLS implicito raccomandato per submission e accesso (465, 993, 995).
2021 IMAP4rev2 (RFC 9051).
2024/2025 Google e Yahoo (da febbraio 2024) e Microsoft per Outlook.com, Hotmail e Live (dal 5 maggio 2025, oltre 5000 e-mail al giorno): SPF, DKIM e DMARC obbligatori, altrimenti rifiuto.
2026 DMARCbis come standard: RFC 9989 (protocollo), 9990 (rapporti aggregati), 9991 (rapporti di errore); la RFC 7489 è sostituita.

L’autenticazione in dettaglio

SPF verifica l’IP rispetto al mittente della busta, DKIM la firma con dominio d= e selettore s=, DMARC esige l’allineamento con l’intestazione From — SPF e DKIM forniscono il risultato, DMARC lo collega al mittente visibile.

SPF (RFC 7208)

Record TXT sul dominio della busta, p. es. v=spf1 mx include:spf.protection.outlook.com -all. Limiti: al massimo 10 query DNS (include, a, mx, redirect …), gli inoltri rompono SPF e SPF non verifica il mittente visibile.

DKIM (RFC 6376)

Firma su campi di intestazione scelti e sul corpo; la chiave pubblica si trova sotto <selettore>._domainkey.<dominio>. Raccomandato: RSA 2048 bit (o in aggiunta Ed25519, RFC 8463), cambio regolare delle chiavi, firmare From più volte (oversigning).

DMARC (RFC 7489 e RFC 9989)

_dmarc.example.ch. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.ch; adkim=s; aspf=s"

DMARC è superato se SPF o DKIM è superato e corrisponde al dominio in From: (allineamento, relaxed o strict).
Policy p=none (solo rapporti), quarantine, reject; sp= per i sottodomini.
DMARCbis (RFC 9989): pct, rf e ri sono storici; nuovi sono t=y (modalità di test, un livello sotto), np= per i sottodomini inesistenti e psd= per i domini di suffisso pubblico; il dominio organizzativo è determinato con un «tree walk» DNS (al massimo otto query) invece della Public Suffix List.
I rapporti aggregati (rua) mostrano chi invia a nome del dominio – la base per arrivare a p=reject.

ARC e inoltri

Le mailing list e gli inoltri modificano i messaggi o la busta. ARC (RFC 8617) registra i risultati dell’autenticazione lungo il percorso, affinché intermediari affidabili possano spiegare gli errori DMARC.

Cifratura del trasporto

Metodo	Effetto	Presupposto
STARTTLS (opportunistico)	cifrato se entrambe le parti lo supportano; un aggressore in rete può sopprimerlo (downgrade)	certificato sul MX
MTA-STS (RFC 8461)	i mittenti esigono un certificato valido e TLS; policy via HTTPS su `mta-sts.<dominio>`	TXT `_mta-sts`, file di policy, certificati validi
DANE (RFC 7672)	certificato fissato tramite record TLSA nel DNS	DNSSEC per dominio e MX
TLS-RPT (RFC 8460)	rapporti giornalieri sulle consegne cifrate non riuscite	TXT `_smtp._tls`

Situazione attuale (2026)

I grandi fornitori di caselle impongono SPF, DKIM, DMARC (almeno p=none, allineamento), record PTR validi, TLS e – per gli invii massivi – la disiscrizione con un clic (RFC 8058) e tassi di reclamo per spam bassi.
La quota di domini con p=reject cresce, ma è ancora bassa, soprattutto tra PMI e amministrazioni.
La submission sulla porta 465 (TLS implicito) si sta affermando; la porta 25 è bloccata per i dispositivi finali presso molti provider.
La cifratura end-to-end (S/MIME, OpenPGP) resta una nicchia; i contenuti confidenziali passano spesso da portali.
La compromissione della posta aziendale (BEC) e il phishing restano, in molti rapporti sulla situazione, tra i vettori d’attacco più frequenti; mittenti falsificati e domini simili (typosquatting) vi hanno un ruolo centrale.

Sviluppi

DMARCbis nella pratica: tree walk, np=, t=; analisi e strumenti devono adeguarsi.
Crittografia post-quantistica: gli accordi di chiave ibridi (p. es. X25519MLKEM768) sono arrivati nelle librerie TLS e si diffonderanno anche tra i server di posta; per DKIM si discutono firme resistenti ai computer quantistici.
Cifratura del trasporto imposta con MTA-STS o DANE al posto dello STARTTLS opportunistico.
BIMI (logo del marchio per mittenti verificati, con certificato VMC/CMC) come incentivo per p=quarantine/reject.
JMAP come protocollo di accesso moderno basato su JSON, accanto a IMAP.
L’IA su entrambi i fronti: filtri migliori, ma anche e-mail di phishing ingannevolmente autentiche senza errori – l’autenticazione tecnica diventa un obbligo.

Che cosa verifica eam.ch

SPF (presente, troppo permissivo, errori), DMARC (presente, policy, indirizzo per i rapporti), DKIM (selettori comuni).
MX: STARTTLS e certificato; MTA-STS e TLS-RPT; domini senza posta non protetti dalla falsificazione.
Domini simili in grado di inviare e-mail (domini contraffatti) e server di posta su liste di blocco (reputazione).

Fonti: RFC 821, 822, 1341, 2045, 3207, 5321, 5322, 6376, 6531, 7208, 7489, 7505, 7672, 8058, 8314, 8460, 8461, 8463, 8617, 8620, 8621, 9051, 9989–9991 (rfc-editor.org); Microsoft Tech Community, «Strengthening Email Security: Outlook’s New Requirements for High-Volume Senders» (2025); Google, «Email sender guidelines» (2024).

In breve

L’e-mail viaggia in tre tappe: invio (SMTP), inoltro tra server (SMTP tramite il record MX) e ritiro (IMAP).
I mittenti si possono falsificare perché SMTP non li verifica.
SPF, DKIM e DMARC rendono le e-mail verificabili; solo p=reject protegge efficacemente.
Dal 2024/2025 Google, Yahoo e Microsoft esigono questi record; nel 2026 DMARCbis è pubblicato come nuovo standard.
MTA-STS e DANE impongono la consegna cifrata.