Intestazioni Email: Guida agli Header di un Messaggio

Che cosa sono le intestazioni di una email

Le intestazioni sono la parte del messaggio che precede la prima riga vuota. Lo stabilisce lo standard RFC 5322, che definisce il formato dei messaggi di posta: prima i metadati, una riga vuota, poi il corpo. Tutto ciò che sta sopra quella riga vuota è intestazione; tutto ciò che sta sotto è contenuto.

Ogni intestazione è una riga nella forma Nome: valore. Il nome non distingue fra maiuscole e minuscole, il valore dipende dall'intestazione. Un messaggio ne contiene di norma diverse decine: le prime cinque le conosci già perché il programma di posta te le mostra, le altre restano nascoste.

Le intestazioni si dividono in due famiglie, e la distinzione è la cosa più utile da tenere a mente:

• Quelle scritte da chi invia — From, To, Subject, Date, Reply-To. Sono dichiarazioni del mittente e possono contenere qualunque valore.
• Quelle aggiunte dai server — Received, Return-Path, Authentication-Results. Vengono scritte durante il transito dai sistemi che gestiscono il messaggio e sono la parte su cui si può ragionare.

Le intestazioni sono conservate nel file quando salvi un messaggio in formato .eml: è la ragione per cui quel formato è utile per un'analisi. Cosa contiene esattamente quel file è spiegato in file EML: cosa sono.

Mittente, destinatari e oggetto

Sono le intestazioni che il programma di posta mostra nell'interfaccia. Le compila chi invia, e questo significa che nessuna di esse costituisce una prova di provenienza.

• From — il mittente visibile, nella forma Nome Cognome <indirizzo@dominio>. La parte fra virgolette o prima delle parentesi angolari è il display name, testo completamente libero. Molte app di posta su smartphone mostrano soltanto quello, nascondendo l'indirizzo.
• To — i destinatari principali. Anche questa è una dichiarazione: i destinatari effettivi vengono indicati al server durante la consegna, e non è detto che coincidano con quanto scritto qui. È il motivo per cui a volte ricevi un messaggio in cui il tuo indirizzo non appare da nessuna parte.
• Cc — i destinatari in copia. Compare in tutte le copie del messaggio ed è visibile a tutti.
• Bcc — la copia nascosta. Nel messaggio consegnato non compare: il server la usa per la consegna e la rimuove. Se ricevi un messaggio in cui il tuo indirizzo non è né in To né in Cc, di norma eri in Bcc.
• Reply-To — l'indirizzo a cui va la risposta, se diverso dal mittente. Uso legittimo: una newsletter inviata da un indirizzo automatico che indirizza le risposte all'assistenza. Uso negli attacchi: un messaggio che sembra provenire da un indirizzo aziendale reale ma con Reply-To su un dominio controllato dall'attaccante, così la risposta — e gli allegati che contiene — finisce altrove. È un'intestazione che vale sempre la pena controllare.
• Subject — l'oggetto. Se contiene accenti o emoji è codificato, come spiegato più sotto.
• Date — data e ora della composizione, con il fuso orario, nel formato previsto dall'RFC 5322 (per esempio Mon, 28 Sep 2026 10:15:32 +0200). La scrive il client di chi invia, quindi dipende dall'orologio di quel dispositivo: un orologio sbagliato produce una data sbagliata. Le date affidabili sono quelle dentro le righe Received.

Le intestazioni di percorso e di autenticazione

Sono le intestazioni scritte dai server durante il transito: raccontano da dove il messaggio è realmente passato e cosa hanno rilevato i controlli automatici. Sono la parte che conta in un'analisi.

• Return-Path — l'indirizzo a cui vengono inviati gli avvisi di mancata consegna. Corrisponde al mittente dichiarato a livello di trasporto e lo scrive il server di destinazione. Un Return-Path su un dominio del tutto diverso da quello del From è il segnale più immediato di un messaggio da guardare con attenzione.
• Received — una riga per ogni server attraversato, con il nome e l'indirizzo IP del sistema che ha passato il messaggio, quello che l'ha ricevuto, il protocollo e l'ora. È la ricostruzione del percorso, e va letta in un ordine specifico (sezione successiva).
• Authentication-Results — il verbale dei controlli eseguiti dal server ricevente: spf=, dkim=, dmarc= seguiti dall'esito pass, fail o none. Il valore none indica che il controllo non era applicabile perché il dominio non l'ha configurato, non che sia andato male.
• DKIM-Signature — la firma crittografica apposta dal dominio mittente. Contiene il dominio firmatario (d=), il selettore usato per trovare la chiave pubblica nel DNS (s=), l'elenco delle intestazioni coperte dalla firma (h=) e la firma stessa (b=). La sua presenza non equivale a una firma valida: la validità la stabilisce la verifica, il cui esito finisce in Authentication-Results.

Il significato pratico di SPF, DKIM e DMARC — e in particolare cosa non dimostrano quando risultano superati — è trattato in come riconoscere una email falsa.

Gli identificativi che tengono insieme le conversazioni

Tre intestazioni servono a collegare i messaggi fra loro: sono il motivo per cui il tuo programma di posta riesce a raggruppare una discussione in un unico blocco anche quando gli oggetti cambiano.

• Message-ID — l'identificativo univoco del messaggio, generato da chi lo invia, nella forma <stringa@dominio>. È il riferimento da citare quando si deve individuare un messaggio specifico in un registro di posta, ed è anche il dato che i gestori usano nelle ricerche sui log.
• In-Reply-To — il Message-ID del messaggio a cui si risponde. Contiene un solo riferimento: il precedente diretto.
• References — l'elenco dei Message-ID di tutta la catena, dal primo messaggio in poi. È l'intestazione che permette di ricostruire la discussione completa e di capire se un messaggio appartiene davvero allo scambio in cui sembra inserirsi.

Dettaglio utile: References e In-Reply-To permettono di accorgersi di un messaggio che finge di essere la risposta a uno scambio esistente. Se l'oggetto inizia per «Re:» ma le due intestazioni sono assenti o rimandano a identificativi che non corrispondono a nulla, quel messaggio non fa parte di alcuna conversazione precedente.

Le intestazioni di contenuto e quelle personalizzate

Un altro gruppo di intestazioni descrive com'è costruito il messaggio: se contiene testo semplice, HTML, allegati, e con quale codifica. Sono quelle definite dalle specifiche MIME.

• MIME-Version — vale praticamente sempre 1.0 e dichiara che il messaggio segue le convenzioni MIME. In assenza di questa riga il messaggio è testo semplice puro.
• Content-Type — il tipo di contenuto. I valori che si incontrano più spesso: text/plain per il testo semplice, text/html per la versione formattata, multipart/alternative quando il messaggio contiene entrambe le versioni e il programma sceglie quale mostrare, multipart/mixed quando ci sono allegati. Nei casi multipart la riga include un boundary, cioè la stringa che separa le parti.
• Content-Transfer-Encoding — come i dati sono codificati per il trasporto: base64 per gli allegati e per il testo con molti caratteri non ASCII, quoted-printable per il testo con pochi caratteri accentati. È la ragione per cui un allegato dentro un file .eml occupa circa un terzo in più della sua dimensione reale.
• Intestazioni X- — intestazioni non standard, aggiunte liberamente da programmi e server. Le più comuni sono X-Mailer (il programma che ha composto il messaggio), X-Originating-IP (l'indirizzo da cui il messaggio è stato inviato, quando il provider lo espone) e le varie X-Spam- con i punteggi assegnati dai filtri antispam. Non sono garantite né verificabili, ma a volte sono informative: un X-Mailer che indica uno strumento di invio massivo su un messaggio che si presenta come personale è una piccola incoerenza che vale la pena notare.

In che ordine si leggono le righe Received

Dal basso verso l'alto. Ogni server che gestisce il messaggio aggiunge la propria riga Received in cima a quelle già presenti. Quindi la prima riga che vedi dall'alto è l'ultimo passaggio, e la riga più in basso è la più vecchia: l'origine.

È l'unica convenzione controintuitiva di tutta la struttura, e sbagliarla porta a conclusioni rovesciate. Una riga tipica contiene quattro informazioni:

• from — il nome dichiarato e l'indirizzo IP reale del sistema che ha consegnato il messaggio a questo server. Il nome è dichiarato dal mittente della connessione, l'IP fra parentesi è rilevato e quindi attendibile.
• by — il server che ha ricevuto e che sta scrivendo la riga.
• with — il protocollo usato, per esempio ESMTPS quando la connessione era cifrata.
• l'ora — il momento del passaggio secondo l'orologio di quel server, con il fuso orario. Confrontando le ore delle varie righe si vede quanto tempo il messaggio è rimasto in ciascun punto: un salto di ore fra due passaggi significa una coda, non necessariamente un problema.

Perché vedi righe spezzate e sequenze illeggibili

Aprendo un messaggio in un editor di testo si incontrano due fenomeni che sembrano errori e non lo sono: intestazioni spezzate su più righe e sequenze come =?UTF-8?B?UmljZXZ1dGE=?= al posto delle parole con gli accenti. Sono due meccanismi previsti dagli standard.

Il primo si chiama header folding ed è definito dall'RFC 5322, §2.2.3: un'intestazione troppo lunga può essere spezzata su più righe, purché le righe successive alla prima comincino con uno spazio o una tabulazione. Le righe che iniziano con uno spazio, quindi, non sono nuove intestazioni: sono la continuazione di quella sopra. È il motivo per cui una singola riga Received spesso occupa quattro o cinque righe sullo schermo.

Il secondo si chiama encoded word ed è definito dall'RFC 2047. Le intestazioni possono contenere solo caratteri ASCII: accenti, lettere non latine ed emoji vanno quindi codificati. La sintassi è =?charset?codifica?dati?=, dove la codifica è B per Base64 o Q per quoted-printable. Così Fattura scaduta — sollecito diventa una sequenza illeggibile nell'oggetto grezzo.

Un lettore di email decodifica automaticamente entrambe le cose; un editor di testo no. È la differenza pratica fra aprire il file .eml nel Blocco note e aprirlo in un lettore: nel primo caso vedi il formato grezzo, nel secondo vedi le intestazioni ricomposte e leggibili. La procedura è in come aprire un file EML.

Come vedere le intestazioni nei programmi di posta

Ogni programma nasconde le intestazioni complete in un punto diverso del menu. Questi sono i percorsi dei più diffusi.

• Gmail — apri il messaggio, menu con i tre puntini in alto a destra del messaggio, Mostra originale. Si apre una scheda con le intestazioni complete e un pulsante Scarica originale che salva il file. Il percorso completo, anche da telefono, è in come scaricare una email da Gmail.
• Outlook per Windows — apri il messaggio in una finestra separata, poi File → Proprietà: le intestazioni sono nel riquadro Intestazioni Internet, in fondo alla finestra. Il riquadro è piccolo e non ridimensionabile: conviene selezionare tutto e incollare altrove.
• Outlook sul web — apri il messaggio, menu con i tre puntini, Visualizza → Visualizza dettagli messaggio.
• Apple Mail — Visualizza → Messaggio → Tutte le intestazioni. L'impostazione resta attiva per tutti i messaggi finché non la disattivi.
• Thunderbird — Ctrl+U (su Mac Cmd+U) apre il sorgente completo del messaggio in una finestra separata.

C'è un'alternativa che funziona indipendentemente dal programma: salvare il messaggio come file .eml e aprirlo nel lettore EML. Il file viene letto interamente nel browser — non esiste un endpoint a cui venga inviato, e lo si verifica dal pannello Rete degli strumenti per sviluppatori — e una Content Security Policy blocca le immagini remote contenute nel messaggio, quindi la semplice lettura non segnala nulla al mittente. È il modo più comodo quando le intestazioni da leggere sono quelle di un messaggio che preferisci non toccare.

Se il messaggio arriva da una casella di posta elettronica certificata, le intestazioni che vedi sono quelle della busta del gestore: quelle del messaggio vero stanno dentro l'allegato postacert.eml, e si leggono come spiegato in aprire postacert.eml e daticert.xml.

Cosa si può dedurre, e cosa no

Dalle intestazioni si ricostruisce il percorso tecnico di un messaggio: quali sistemi l'hanno gestito, quando, con quali esiti di autenticazione. Non si ricostruisce chi ha premuto invio.

Il limite più frequentemente frainteso riguarda l'indirizzo IP nella riga Received più in basso. Se il mittente usa un servizio di posta grande — Gmail, Outlook.com, un provider italiano qualsiasi — quell'IP appartiene ai server del provider ed è lo stesso per milioni di messaggi al giorno. Non indica una città, non indica una persona, non indica nulla sul mittente specifico. Solo su server aziendali o di piccole dimensioni l'IP può dire qualcosa in più, e anche allora identifica un sistema, non un individuo.

Riassumendo, in modo onesto:

• Si può stabilire se il dominio dichiarato nel From coincide con quello che ha realmente immesso il messaggio, quali controlli di autenticazione sono stati superati, quanto tempo è passato fra i vari passaggi e se il messaggio appartiene davvero a una conversazione precedente.
• Si può sospettare, non dimostrare, sulla base di incoerenze: un Reply-To su un dominio estraneo, un X-Mailer che non c'entra col tipo di messaggio, una data di composizione incompatibile con le ore dei passaggi.
• Non si può stabilire l'identità di chi ha scritto, la sua posizione geografica, né se il contenuto sia veritiero. E non si può stabilire nulla con valore legale: un esito letto nelle intestazioni è un dato indicativo, non una perizia.

Questo vale anche per quello che mostra il nostro lettore: gli esiti SPF, DKIM e DMARC vengono riportati così come risultano dalle intestazioni, non ricalcolati. Serve a farsi un'idea rapida e informata, non a produrre una prova.

Domande frequenti