Come leggere gli header di un’email e scoprire da dove arriva

Cosa sono gli header di un’email

Gli header, o intestazioni, sono campi nella forma Nome: valore che compongono la prima parte di ogni messaggio di posta, prima del corpo. Il formato è definito dalla RFC 5322: alcuni li scrive il programma del mittente, come From, To, Subject e Date, altri li aggiungono i server lungo il percorso, come Received e Authentication-Results.

Il client di posta ne mostra solo tre o quattro. Gli altri restano nascosti, ma sono quelli che servono quando un messaggio sembra falso, finisce nello spam o arriva in ritardo. Attenzione però: i campi scritti dal mittente, compreso il From, possono contenere qualsiasi cosa. Puoi fidarti solo dei campi aggiunti dal tuo server di posta: le righe Received più in alto e l’Authentication-Results del tuo provider.

Come scoprire da dove arriva un’email

1. Apri gli header completi del messaggio: in Gmail dal menu Altro, voce “Mostra originale”.
2. Leggi l’intestazione Authentication-Results e controlla l’esito di spf, dkim e dmarc.
3. Scorri le righe Received partendo dal fondo e trova il primo server esterno, con il suo indirizzo IP tra parentesi quadre.
4. Controlla quell’IP con la verifica IP e il controllo blacklist, e il dominio del mittente con il Whois.

Come visualizzare gli header in Gmail, Outlook e Apple Mail

Ogni client ha un comando diverso per mostrare il messaggio originale con tutte le intestazioni. La tabella riporta i percorsi indicati dalle guide ufficiali.

Le app di posta per smartphone spesso non mostrano gli header completi. In quel caso apri lo stesso messaggio dalla webmail su un computer.

I campi principali e cosa dicono

Nel testo completo di un messaggio ci sono spesso decine di intestazioni, molte aggiunte da filtri antispam e piattaforme di invio. Quelle utili per capire chi ha spedito sono poche.

Come leggere le righe Received

Le righe Received sono il registro di viaggio del messaggio: ogni server che lo inoltra aggiunge la sua riga in cima a quelle esistenti. La RFC 5321, alla sezione 4.4, lo impone in modo esplicito: i server SMTP devono anteporre le righe Received al messaggio e non possono cambiare l’ordine di quelle già presenti né inserirle altrove. Per ricostruire il percorso in ordine cronologico, quindi, leggile dal basso verso l’alto. Una riga tipica ha questa forma:

Received: from mail.example.com (mail.example.com [203.0.113.25]) by mx.example.net with ESMTPS; Mon, 5 Oct 2026 10:12:03 +0200

Dopo from c’è il server che ha consegnato il messaggio, con il nome che ha dichiarato e, tra parentesi quadre, l’indirizzo IP che il server ricevente ha visto davvero. Dopo by c’è il server che ha scritto la riga. In fondo, data e ora.

• Fidati solo delle righe in alto, quelle aggiunte dai server del tuo provider. Quelle più in basso le ha scritte chi ha spedito, e uno spammer può inventarle.
• Il primo IP pubblico che trovi risalendo dal fondo, nella prima riga scritta da un server affidabile, è di solito il server da cui il messaggio è partito. Gli indirizzi privati come 10.x o 192.168.x appartengono alla rete interna del mittente e non dicono nulla.
• Gli orari di righe consecutive mostrano dove il messaggio si è fermato: un salto di ore tra due server spiega un’email arrivata in ritardo.

Trovato l’IP, la verifica IP ne mostra provider e paese, il reverse IP lookup il nome associato e il controllo blacklist se è segnalato come fonte di spam. Se il messaggio arriva da un grande servizio come Gmail o Outlook.com, l’IP sarà del servizio e non del computer di chi ha scritto.

Authentication-Results: SPF, DKIM e DMARC

L’intestazione Authentication-Results riassume in una riga i controlli fatti dal server che ha ricevuto il messaggio. Un esempio:

Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

• spf=pass: il server di invio è autorizzato dal dominio indicato in smtp.mailfrom, il Return-Path.
• dkim=pass: la firma è valida per il dominio in header.d.
• dmarc=pass: almeno uno dei due controlli è passato con un dominio allineato al From visibile, indicato in header.from.

Oltre a pass, tra i valori possibili ci sono fail, softfail, neutral, none, temperror e permerror. Un dmarc=fail su un messaggio che dice di arrivare dalla tua banca è un segnale serio. Un spf=pass per un dominio diverso da quello del From, invece, è normale con le piattaforme di invio: quello che conta è l’allineamento verificato dal DMARC. Se il problema riguarda il tuo dominio, controlla i record con la verifica SPF, DKIM e DMARC e confrontali con i valori per Aruba, Register.it, Google e Microsoft.

Come riconoscere un’email falsa dagli header

Gli header non danno un verdetto automatico, ma alcune combinazioni sono tipiche del phishing. I controlli da fare:

1. DMARC: se l’Authentication-Results riporta dmarc=fail per il dominio del From, il messaggio non è stato spedito da quel dominio.
2. From e Reply-To: un From con il nome di un’azienda e un Reply-To su un dominio sconosciuto o su una casella gratuita indica che le risposte vanno a qualcun altro.
3. Nome visualizzato: “Servizio Clienti Banca” con un indirizzo che non ha nulla a che fare con la banca. Molti client mostrano solo il nome.
4. Domini simili: lettere scambiate, trattini aggiunti, estensioni diverse. Il Whois mostra la data di registrazione, e un dominio creato pochi giorni prima è un campanello d’allarme.
5. Origine: un IP in blacklist o un percorso che non passa dai server dell’azienda che dice di scriverti.

Se il messaggio è legittimo ma finisce nello spam, le cause sono di altro tipo: le trovi nella guida sulle email nello spam.