Leggere le intestazioni delle e-mail per riconoscere lo spoofing

Ogni e-mail porta nelle intestazioni una traccia completa: i server attraversati, i risultati dell’autenticazione e il vero mittente di busta. Saperle leggere con scioltezza è il modo più rapido per confermare o smentire un sospetto spoofing, ed è un’abilità chiave nel triage delle segnalazioni di phishing.

Dove trovare le intestazioni grezze

Il messaggio visualizzato nasconde tutto ciò che serve. Recuperate il sorgente grezzo:

• Gmail — Mostra originale.
• Outlook — File → Proprietà → Intestazioni Internet (o Visualizza origine messaggio).
• Apple Mail — Vista → E-mail → Sorgente grezzo.
• Riga di comando — esaminate direttamente il file .eml.

Per il percorso di consegna le intestazioni si leggono dal basso verso l’alto: il salto più vecchio sta in fondo, il Received: del server destinatario in cima.

Le identità che contano

Ci sono due valori «from», e il phishing sfrutta proprio la distanza fra loro:

• Mittente di busta (Return-Path / MAIL FROM) — usato per instradamento e rimbalzi; verificato da SPF.
• From di intestazione (From:) — ciò che l’utente vede nel client.

Uno spoofing mostra tipicamente un From: affidabile mentre il Return-Path punta altrove.

Return-Path: <[email protected]>
From: "IT Helpdesk" <[email protected]>

Il nome visualizzato (IT Helpdesk) è interamente controllato dall’aggressore e non prova nulla.

Leggere Authentication-Results

L’intestazione di gran lunga più importante è Authentication-Results, aggiunta dal vostro server destinatario (fidatevi solo di quella del vostro dominio, in cima):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) [email protected];
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Interpretatela con attenzione:

• spf=pass qui è una trappola: è passato per sketchy-host.ru, non per il visibile yourbank.example. SPF controlla la busta, non il From:.
• dkim=fail — nessuna firma valida allineata con il dominio del From:.
• dmarc=fail (p=reject) — questo è il verdetto che conta: l’autenticazione del dominio visibile non si allinea. Un messaggio che arriva in casella nonostante dmarc=fail merita esame.

Confrontate sempre il dominio che ciascun meccanismo ha davvero autenticato (smtp.mailfrom, header.d) con il dominio del From:. Autenticazione senza allineamento non significa nulla.

Ricostruire il percorso con Received

Ogni salto antepone una riga Received:. Leggete dal basso:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Campanelli d’allarme:

• L’IP del salto d’origine si geolocalizza lontano da dove il mittente dichiara di essere.
• Un HELO falsificato (localhost, o un hostname che non corrisponde al DNS inverso).
• Buchi sospetti o salti di fuso orario nei timestamp.
• Il primo salto fidato è il vostro MX: tutto ciò che sta sotto è fornito dall’aggressore ed è falsificabile, quindi pesatelo di conseguenza.

Altri indizi nelle intestazioni

• Reply-To divergente — il From: sembra un collega, ma Reply-To dirotta le risposte a un indirizzo esterno. Classico nel BEC e nella frode del CEO.
• Dominio del Message-ID che non corrisponde al dominio d’invio.
• Intestazioni X-Mailer / X-PHP-Script che rivelano uno strumento di invio massivo o uno script PHP su un host compromesso.
• Unicode/punycode nel dominio del From: (xn--), un attacco omografo.

Una checklist rapida di triage

1. Dominio del From: == dominio del Return-Path?       (discordanza = sospetto)
2. Authentication-Results: dmarc=pass e allineato?      (fail = sospetto)
3. Quale dominio hanno davvero autenticato SPF/DKIM?    (deve combaciare col From:)
4. Reply-To differisce dal From:?                       (sì = sospetto)
5. Da dove parte il salto Received più in basso?        (geo inattesa = sospetto)
6. Punycode/omoglifi nel dominio del From:?             (sì = sospetto)

Una singola intestazione raramente prova da sola uno spoofing. Il verdetto nasce dall’allineamento: il dominio che ha autenticato corrisponde a quello che la persona vede? DMARC esiste proprio per automatizzare quel confronto, ma sulla posta in arrivo da altri domini dovete comunque leggerlo a mano.

Come aiuta GottaPhish

Leggere le intestazioni è un’abilità reattiva e da specialisti, e la maggior parte degli utenti non le vede mai. GottaPhish e il suo team di esperti colmano questo divario: phishing simulato realistico — divari di allineamento, sostituzioni di Reply-To, domini simili — più cruscotti che riportano esattamente chi ha segnalato, cliccato o inserito credenziali. I nostri esperti seguono l’avvio, disegnano scenari che mettono alla prova proprio i trucchi sulle intestazioni usati dagli aggressori e aiutano a interpretare i risultati, affinando i playbook di triage dei team tecnici mentre la formazione insegna a tutti gli altri i segnali visibili che stanno dietro a quelle intestazioni.