Guide · Email e domini

Come leggere le intestazioni di un'email e riconoscere il phishing

Scritto da Aldo · threat hunter in un blue team
Ultimo aggiornamento: 9 novembre 2026 · 5 min di lettura

Un'email dice di arrivare dalla tua banca, dal tuo capo o da un fornitore. La riga From visibile è solo un testo scritto dal mittente. Le intestazioni sotto registrano ciò che i server di posta hanno visto davvero, e sono molto più difficili da falsificare.

Apri le intestazioni complete

Tutte le app di posta le nascondono di default. Ecco dove trovarle (i nomi dei menu cambiano tra una versione e l'altra, ma questi sono stabili da tempo):

• Gmail (web): apri l'email, fai clic sui tre puntini accanto a Rispondi, poi Mostra originale.
• Outlook sul web e il nuovo Outlook: apri l'email, seleziona i tre puntini, poi Visualizza → Visualizza dettagli messaggio.
• Outlook classico per Windows: apri l'email in una finestra a parte, poi File → Proprietà; le intestazioni sono in Intestazioni Internet.
• Mail di Apple su Mac: Vista → Messaggio → Tutte le intestazioni.
• Thunderbird: Visualizza → Sorgente messaggio (Ctrl+U).
• Le app di posta per iPhone e Android in genere non mostrano le intestazioni complete. Apri la stessa casella da un computer.

Copia tutto dall'inizio fino alla prima riga vuota. Quel blocco è l'intestazione.

Un esempio concreto: la fattura scaduta

Questo è l'esempio dell'analizzatore di intestazioni di iplover. I domini sono domini di documentazione (example.com, .org, .net) e l'indirizzo d'invio è un nodo di uscita Tor pubblico, quindi non è coinvolta nessuna azienda o persona reale, ma ogni riga è del tipo che incontrerai nel phishing vero:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.org header.s=s1 header.b=Xy12;
       spf=pass (google.com: domain of bounce@mailer.example.org designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@mailer.example.org;
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.com
Return-Path: <bounce@mailer.example.org>
Received: from relay.mailer.example.org (relay.mailer.example.org. [198.51.100.25])
        by mx.google.com with ESMTPS id 5a1b2c3d4e
        for <you@example.net>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Nov 2026 10:14:04 -0800 (PST)
Received: from webmail.example.org (unknown [185.220.101.7])
        by relay.mailer.example.org (Postfix) with ESMTPSA id 7C1A2B3;
        Tue,  3 Nov 2026 16:11:58 +0000 (UTC)
Received: from [10.0.0.12] (localhost [127.0.0.1])
        by webmail.example.org with ESMTP;
        Tue,  3 Nov 2026 16:11:55 +0000 (UTC)
From: "Example Billing" <billing@example.com>
Reply-To: payments-desk@example.net
Subject: Invoice 4471 is overdue
Message-ID: <20261103161152.4471@mailer.example.org>
X-Originating-IP: [185.220.101.7]

(Accorciato; l'esempio completo ha anche le intestazioni ARC, che registrano i controlli fatti dai server lungo il percorso.) Il verdetto dell'analizzatore:

Come leggerla, riga per riga

1. Authentication-Results: il verdetto del server che riceve

Il server che ha ricevuto il messaggio (qui quello di Google) l'ha controllato e ha annotato i risultati. Leggi la riga Authentication-Results più in alto: è quella aggiunta dal tuo provider di posta. Qualsiasi riga più in basso potrebbe averla scritta chiunque, mittente compreso.

Il trucco di questo esempio è che SPF e DKIM sono stati entrambi superati, solo non per il dominio giusto. SPF è passato per mailer.example.org e DKIM per example.org, ma l'indirizzo From dice example.com. DMARC è il controllo che lega il risultato al dominio del From, ed è fallito. Il titolare di example.com aveva persino pubblicato una policy che chiede di rifiutare queste email. Questo schema, tutto superato tranne DMARC, è l'aspetto tipico della posta falsificata.

2. From, Reply-To e Return-Path: chi dice di essere, e dove vanno le risposte

La riga From mostra “Example Billing” su example.com. Il Reply-To invece manda la tua risposta a example.net. Help desk e mailing list lo fanno legittimamente, ma in una fattura inattesa significa: chi l'ha scritta vuole la tua risposta in un posto che la vera azienda non controlla. Il Return-Path è dove vanno i messaggi di mancato recapito; lì il dominio di un servizio di invio è normale.

3. Received: il percorso di consegna, letto dal basso verso l'alto

Ogni server che gestisce un messaggio aggiunge una riga Received in cima, quindi la più vecchia è in fondo. Leggi verso l'alto: un dispositivo su una rete privata (10.0.0.12) ha passato la posta alla webmail, che l'ha ricevuta da 185.220.101.7, un nodo di uscita Tor, prima di passarla al relay e poi a Google. Quel primo indirizzo pubblico è quanto di più vicino al mittente potrai vedere, e qui è anonimo di proposito. X-Originating-IP, che alcuni servizi webmail aggiungono, dice la stessa cosa.

Anche gli orari raccontano qualcosa: due ore tra il relay e Google. I ritardi capitano per motivi innocenti, ma vale la pena notarli.

Se vedi questo, fai questo

Cosa le intestazioni non possono dirti

Le intestazioni dimostrano da dove arriva un messaggio, non cosa vuole. Un messaggio da un account vero ma violato supera ogni controllo. Un dominio sosia supera DMARC per se stesso. E le intestazioni non dicono nulla del link o dell'allegato, che è dove di solito sta il danno. Quindi le intestazioni sono un test tra tanti: una richiesta inattesa di denaro, password o decisioni rapide merita sospetto qualunque cosa dicano.

L'analizzatore di iplover legge i risultati registrati dal tuo provider; non verifica di nuovo le firme DKIM e non scarica i record SPF per ogni passaggio. Lo dice alla fine di ogni report, ed è bene tenerlo a mente con qualsiasi strumento.