Capire le intestazioni email: la guida completa per leggere e analizzare ogni campo

⚡TL;DR

• Le intestazioni email sono un registro di bordo invisibile che registra ogni server attraversato, ogni verifica di autenticazione e ogni decisione antispam
• Le intestazioni Received si leggono dal basso verso l'alto: l'hop più vecchio è in basso, il più recente in alto
• Authentication-Results riassume i verdetti SPF, DKIM e DMARC in una sola riga; è il campo più importante per diagnosticare un problema
• I campi From, Return-Path e Reply-To possono puntare a tre indirizzi diversi, segnale potenziale di spoofing
• Uno strumento di analisi automatizzato trasforma decine di righe tecniche in una diagnosi leggibile in pochi secondi

Ricevi un'email sospetta. Il mittente mostra il nome della tua banca, ma qualcosa non torna. Oppure le tue email finiscono in spam nelle caselle dei tuoi clienti e non capisci perché. In entrambi i casi, la risposta si trova nello stesso posto: le intestazioni dell'email. Quando si sa che il 60 % delle violazioni confermate coinvolgono un'azione umana (Verizon DBIR 2025) e che servono in media 207 giorni per rilevare una compromissione da phishing (IBM 2025), saper leggere un'intestazione non è più un lusso tecnico.

Ogni email trasporta un blocco di metadati invisibili. Questo blocco contiene l'itinerario completo del messaggio (quali server ha attraversato, in quale ordine), i risultati delle verifiche di autenticazione (SPF, DKIM, DMARC) e indizi su come i filtri antispam hanno trattato il messaggio. È un registro di bordo completo, ma bisogna saperlo leggere.

Questa guida ti insegna a estrarre queste intestazioni, capire ogni campo, interpretare la catena di instradamento e diagnosticare i problemi più frequenti. Che tu sia amministratore di sistema, responsabile marketing o semplicemente curioso di sapere se un'email è legittima, non è richiesta alcuna conoscenza pregressa: si parte da zero.

Che cos'è un'intestazione email e perché dovresti occupartene?

L'analogia della busta postale

Quando spedisci una lettera, la busta porta l'indirizzo del mittente, quello del destinatario e i timbri postali. Il contenuto della lettera è separato da queste informazioni di instradamento.

Un'email funziona allo stesso modo. Il corpo del messaggio (il testo, le immagini, gli allegati) è separato dalle intestazioni che trasportano i metadati. La differenza: le intestazioni di un'email contengono molte più informazioni di una busta postale. Ogni server che la elabora aggiunge le proprie annotazioni, come un timbro postale con data e ora.

Intestazioni visibili vs intestazioni tecniche

Il tuo client di posta mostra alcune intestazioni in forma leggibile:

• Da (From): l'indirizzo del mittente
• A (To): l'indirizzo del destinatario
• Oggetto (Subject): l'oggetto del messaggio
• Data (Date): il timestamp di invio

Ma sotto questa superficie, decine di intestazioni tecniche restano nascoste. Le più importanti:

Intestazione	Ruolo
Received	Traccia il percorso del messaggio da server a server
Return-Path	Indirizzo di rimbalzo (busta SMTP)
Authentication-Results	Verdetti SPF, DKIM e DMARC
DKIM-Signature	Firma crittografica del messaggio
Message-ID	Identificatore unico del messaggio
X-Spam-Score	Punteggio assegnato dal filtro antispam

Quattro motivi per leggere le intestazioni

1. Diagnosticare un problema di deliverability. Le tue email finiscono in spam? Le intestazioni del messaggio ricevuto ti dicono esattamente perché: fallimento SPF, firma DKIM non valida, policy DMARC non rispettata o punteggio antispam troppo alto.

2. Verificare l'identità di un mittente. Un'email dice di provenire dal tuo direttore finanziario? Confronta il campo From con il Return-Path e verifica che il DKIM sia firmato dal dominio corretto. Una discrepanza tra questi campi è un forte segnale di allarme.

3. Rilevare lo spoofing e il phishing. Gli attaccanti falsificano il campo From per impersonare un dominio legittimo. Le intestazioni di autenticazione rivelano se il messaggio è stato realmente emesso dal server autorizzato. Un dmarc=fail combinato con un spf=fail su un'email che dice provenire dalla tua banca è un indicatore affidabile di frode. E il problema è enorme: l'84,2 % degli attacchi di phishing supera i controlli DMARC (Egress 2024), perché il dominio non ha una policy DMARC o perché la policy è troppo permissiva (p=none).

4. Tracciare un problema di latenza. Ogni intestazione Received contiene un timestamp. Confrontando i timestamp di ogni hop, identifichi il server che introduce un ritardo anomalo nella catena di instradamento.

Come estrarre le intestazioni

Ogni client di posta nasconde le intestazioni tecniche per impostazione predefinita. Ecco come visualizzarle.

Gmail (web)

1. Apri l'email in questione
2. Clicca sul menu dei tre punti verticali (⋮) in alto a destra del messaggio
3. Seleziona "Mostra originale"
4. Si apre una nuova finestra con le intestazioni complete e un riepilogo SPF/DKIM/DMARC in alto

Gmail offre un pulsante "Copia negli appunti" per recuperare l'intero contenuto delle intestazioni. È il metodo più rapido per incollarle in uno strumento di analisi.

Outlook desktop (Windows/Mac)

1. Apri l'email in una finestra separata (doppio clic)
2. Vai su File > Proprietà
3. Le intestazioni compaiono nel campo "Intestazioni Internet" in fondo alla finestra

Il campo è piccolo: seleziona tutto (Ctrl+A) e poi copia (Ctrl+C) per lavorare più comodamente in un editor di testo.

Outlook web (OWA)

1. Apri l'email in questione
2. Clicca sul menu dei tre punti (⋮) in alto a destra
3. Seleziona "Visualizza" poi "Visualizza origine del messaggio"
4. Le intestazioni vengono mostrate in una nuova finestra

Apple Mail (macOS)

1. Seleziona l'email nella lista
2. Nella barra dei menu, vai su Vista > Messaggio > Tutte le intestazioni
3. Le intestazioni tecniche appaiono sopra il corpo del messaggio

Per tornare alla visualizzazione normale: Vista > Messaggio > Intestazioni predefinite.

Thunderbird

1. Seleziona l'email
2. Menu Visualizza > Sorgente del messaggio (o scorciatoia Ctrl+U, Cmd+U su Mac)
3. Il codice sorgente completo si apre in una nuova finestra, intestazioni incluse

Thunderbird mostra anche un riepilogo delle intestazioni direttamente nel riquadro di lettura se attivi Visualizza > Intestazioni > Tutte.

Yahoo Mail

1. Apri l'email in questione
2. Clicca sul menu dei tre punti (⋮) accanto al pulsante Rispondi
3. Seleziona "Visualizza messaggio non elaborato"
4. Le intestazioni complete e il corpo del messaggio vengono mostrati in una nuova scheda

ProtonMail

1. Apri l'email in questione
2. Clicca sul menu dei tre punti (⋮) in alto a destra del messaggio
3. Seleziona "Visualizza intestazioni"
4. ProtonMail mostra le intestazioni in una finestra modale. Usa il pulsante copia per recuperare l'intero contenuto

Nota: essendo ProtonMail un servizio crittografato lato client, le intestazioni visibili sono quelle aggiunte durante il transito SMTP. Le intestazioni interne all'infrastruttura ProtonMail restano limitate.

Consiglio pratico

Qualunque sia il metodo, copia l'intero contenuto delle intestazioni e incollale in uno strumento di analisi delle intestazioni. Lo strumento scompone automaticamente ogni campo, calcola i ritardi tra gli hop e mette in evidenza i problemi di autenticazione.

Copia TUTTO il contenuto. Le intestazioni di un'email professionale contengono spesso tra 50 e 200 righe. Se copi solo le prime righe, perdi gli hop Received più vecchi (che si trovano in basso) e spesso le informazioni più rivelatrici.

Errore frequente: non confondere "Visualizza sorgente" (che mostra il messaggio completo, intestazioni + corpo codificato) con "Visualizza intestazioni" (solo i metadati). Per una diagnosi completa, è preferibile l'intera sorgente: contiene le firme DKIM verificabili.

Formato e struttura delle intestazioni (RFC 5322)

Il formato chiave: valore

Ogni intestazione segue un formato semplice definito dalla RFC 5322:

Nome-Del-Campo: valore del campo

Il nome del campo non è sensibile alle maiuscole (From e from sono identici), seguito dai due punti, poi dal valore. Esempi:

From: contact@captaindns.com
To: support@captaindns.com
Subject: Report di monitoring DNS - Marzo 2026
Date: Sat, 29 Mar 2026 10:15:00 +0100
Message-ID: <20260329101500.abc123@mail.captaindns.com>

Il folding (continuazione su più righe)

Quando un valore è troppo lungo per stare su una sola riga, continua sulla riga successiva con un'indentazione (spazio o tabulazione). È ciò che si chiama folding. Esempio con un'intestazione Received:

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Queste tre righe formano una sola intestazione Received. La regola: ogni riga che inizia con uno spazio bianco è la continuazione dell'intestazione precedente.

L'ordine di lettura: dal basso verso l'alto per i Received

Ecco la particolarità più importante delle intestazioni email: le intestazioni Received si leggono dal basso verso l'alto.

Ogni server SMTP che elabora il messaggio aggiunge la sua intestazione Received sopra le intestazioni esistenti. Il risultato: il primo hop (il server di origine) è in basso, l'ultimo hop (il server di ricezione) è in alto.

Le altre intestazioni (From, To, Subject, Date, Message-ID) vengono aggiunte una sola volta dal server di origine. La loro posizione nel blocco è fissa.

I campi chiave spiegati uno per uno

From

From: Marie Dupont <contact@captaindns.com>

Descrizione: identifica il mittente visualizzato nel client di posta. È il campo che vede il destinatario.

Cosa rivela: il From è l'intestazione più visibile, ma anche la più facile da falsificare. Qualsiasi server SMTP può inviare un'email con un From arbitrario. È proprio per questo che esistono SPF, DKIM e DMARC: verificare che il From corrisponda effettivamente al server che ha inviato il messaggio.

Attenzione al display name. Il campo From contiene due elementi distinti: il nome visualizzato (display name) e l'indirizzo reale tra parentesi angolari. In From: Marie Dupont <contact@captaindns.com>, il tuo client di posta mostra "Marie Dupont" in grassetto e l'indirizzo contact@captaindns.com in dimensione più piccola. Il problema: il display name è un testo libero, senza alcuna verifica. Un attaccante può scrivere From: Direttore Finanziario <attaccante@dominio-malevolo.com> e molti client mobili mostrano solo il nome, non l'indirizzo. Verifica sempre l'indirizzo tra parentesi angolari, non il nome visualizzato.

To e Cc

To: support@captaindns.com
Cc: tech@captaindns.com

Descrizione: To elenca i destinatari principali. Cc (copia carbone) elenca i destinatari in copia visibile.

Cosa rivela: se il tuo indirizzo non compare né in To né in Cc, il messaggio ti è stato inviato in copia nascosta (Bcc) o tramite una lista di distribuzione. Le campagne di phishing di massa usano spesso un To generico o vuoto.

Subject

Subject: =?utf-8?B?UmFwcG9ydCBkZSBtb25pdG9yaW5n?=

Descrizione: l'oggetto del messaggio. Può essere codificato in Base64 o Quoted-Printable quando contiene caratteri non ASCII (accenti, caratteri speciali).

Cosa rivela: nella sua forma decodificata, è il testo che vedi nella tua casella di posta. La codifica grezza nelle intestazioni è normale e non segnala alcun problema.

Date

Date: Sat, 29 Mar 2026 10:15:00 +0100

Descrizione: timestamp definito dal client del mittente al momento dell'invio. Il formato segue la RFC 5322: giorno, data, ora e scostamento UTC.

Cosa rivela: confronta questa data con i timestamp delle intestazioni Received. Uno scarto di diverse ore tra il Date e il primo Received può indicare un'email inviata da uno script mal configurato o un tentativo di manipolazione temporale.

Return-Path

Return-Path: <bounces@mail.captaindns.com>

Descrizione: l'indirizzo a cui vengono inviati i messaggi di rimbalzo (bounce). È l'indirizzo della busta SMTP (MAIL FROM), aggiunto dal server di ricezione finale.

Cosa rivela: il Return-Path può differire dal From. È normale quando un servizio di terze parti invia email per tuo conto. Per esempio, un'email inviata tramite SendGrid mostrerà Return-Path: <bounces+12345@em.sendgrid.net> anche se il From è contact@captaindns.com. Lo stesso vale per Mailgun (bounces@mailgun.org) o Amazon SES (0123abcd@amazonses.com). Questi servizi gestiscono i rimbalzi attraverso la propria infrastruttura.

È anomalo quando un'email dice provenire da contact@captaindns.com ma ha un Return-Path verso un dominio sconosciuto che non ha alcuna relazione con un provider di invio legittimo. DMARC verifica l'allineamento tra il dominio del From e il dominio del Return-Path (o del DKIM). Un disallineamento senza DKIM valido provoca un fallimento DMARC.

Reply-To

Reply-To: risposte@captaindns.com

Descrizione: l'indirizzo a cui il client di posta invierà la risposta quando il destinatario clicca su "Rispondi". Opzionale.

Cosa rivela: un Reply-To diverso dal From è comune per le newsletter (invio da un servizio marketing, risposta al supporto). È sospetto quando il Reply-To punta a un dominio completamente diverso dal From, tipico delle truffe CEO fraud (Business Email Compromise).

Message-ID

Message-ID: <20260329101500.abc123@mail.captaindns.com>

Descrizione: identificatore unico del messaggio, generato dal server di invio. Il formato abituale è un timestamp o un identificatore casuale seguito dal nome host del server, il tutto tra parentesi angolari.

Cosa rivela: il dominio nel Message-ID indica quale server ha realmente creato il messaggio. Se un'email dice provenire da captaindns.com ma ha un Message-ID contenente un dominio diverso, è un indizio di impersonificazione. È anche un indicatore prezioso del servizio di invio reale: un Message-ID in @amazonses.com rivela un invio tramite Amazon SES, @smtpservice.net indica SendGrid, @mail.gmail.com indica Google Workspace. Il Message-ID è una delle intestazioni più difficili da falsificare in modo convincente, perché viene generato automaticamente dal server SMTP.

MIME-Version e Content-Type

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary123abc"

Descrizione: MIME-Version indica che il messaggio usa il formato MIME (quasi sempre 1.0). Content-Type descrive il formato del corpo: text/plain (testo semplice), text/html (HTML), multipart/alternative (entrambe le versioni), multipart/mixed (con allegati).

Cosa rivela: un'email che dichiara di essere testo semplice ma contiene un Content-Type: multipart/mixed con un allegato eseguibile è sospetta. Il Content-Type aiuta a capire la struttura reale del messaggio.

Received

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Descrizione: ogni server SMTP che elabora il messaggio aggiunge un'intestazione Received. È la traccia di instradamento del messaggio.

Cosa rivela: l'itinerario completo del messaggio, server per server. I dettagli di ogni hop (identità del server, protocollo utilizzato, timestamp) permettono di verificare la legittimità dell'instradamento. Sezione dedicata più avanti.

Il protocollo indicato dopo with è un segnale di sicurezza importante. with ESMTPS significa che la connessione tra i due server era crittografata tramite TLS: è lo standard atteso nel 2026. with ESMTP (senza la S) significa che il messaggio è transitato in chiaro, senza crittografia. Se vedi with ESMTP su un hop esterno (tra due organizzazioni diverse), è un problema: il contenuto del messaggio, allegati compresi, è circolato leggibile da chiunque intercetti il traffico di rete. with ESMTPSA indica una connessione autenticata e crittografata (tipicamente un client di posta che si connette al server SMTP con utente/password + TLS).

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=captaindns.com; s=s202603; t=1743238500;
    h=from:to:subject:date:message-id;
    bh=LjIq2t4u3qH0OwZ1E4fDn5t3nVz2Ay+KqR0kbD1XXXA=;
    b=dGVzdCBzaWduYXR1cmUgZXhhbXBsZQ==...

Descrizione: firma crittografica aggiunta dal server di invio. Il server di ricezione verifica questa firma tramite la chiave pubblica pubblicata nel DNS.

Cosa rivela: i tag chiave sono d= (dominio firmatario), s= (selettore della chiave), a= (algoritmo, rsa-sha256 è lo standard), h= (intestazioni coperte dalla firma), bh= (hash del corpo del messaggio) e b= (la firma stessa). Se d=captaindns.com e Authentication-Results mostra dkim=pass, il messaggio è autenticato dal dominio.

Il tag bh= (body hash) è un riassunto crittografico del corpo del messaggio. Il server di ricezione ricalcola questo hash e lo confronta con il valore nell'intestazione. Se il corpo è stato modificato in transito (da una mailing list che aggiunge un piè di pagina, per esempio), l'hash non corrisponde più e DKIM fallisce. Il tag c= (canonicalization) definisce la tolleranza alle modifiche minori: relaxed/relaxed è il più permissivo (ignora gli spazi superflui), simple/simple è rigoroso.

Authentication-Results

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject) header.from=captaindns.com

Descrizione: riepilogo delle verifiche di autenticazione effettuate dal server di ricezione. Un'unica intestazione che raggruppa i verdetti SPF, DKIM e DMARC.

Cosa rivela: è il campo più importante per diagnosticare un problema di autenticazione email. Sezione dedicata più avanti.

X-Mailer e User-Agent

X-Mailer: CaptainDNS Mailer 2.1

Descrizione: identifica il software client utilizzato per inviare il messaggio. Campo opzionale e non standardizzato.

Cosa rivela: un'email professionale inviata da un X-Mailer insolito (uno script Python grezzo, uno strumento di invio massivo) può essere sospetta. È un indizio complementare, mai un criterio decisivo.

X-MS-Exchange-Organization-SCL

X-MS-Exchange-Organization-SCL: 1

Descrizione: Spam Confidence Level assegnato da Microsoft Exchange. Scala da -1 (messaggio affidabile) a 9 (spam certo). La soglia predefinita di quarantena è 5.

Cosa rivela: se usi Exchange o Microsoft 365, questo punteggio ti dice direttamente come il filtro antispam di Microsoft ha valutato il messaggio. Un SCL di 5 o più spiega perché un'email è stata classificata come posta indesiderata.

Le intestazioni ARC

ARC-Seal: i=1; a=rsa-sha256; d=captaindns.com; s=arc202603; cv=none; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=captaindns.com; ...
ARC-Authentication-Results: i=1; mx.captaindns.com;
    spf=pass; dkim=pass; dmarc=pass

Descrizione: ARC (Authenticated Received Chain) preserva i risultati di autenticazione quando un messaggio attraversa intermediari (mailing list, inoltri automatici). Tre intestazioni lavorano insieme: ARC-Authentication-Results (risultati al punto di passaggio), ARC-Message-Signature (firma del messaggio a quel punto) e ARC-Seal (sigillo della catena).

Cosa rivela: quando un'email viene inoltrata e SPF/DKIM falliscono a causa della modifica in transito, ARC permette al server finale di verificare che l'autenticazione era valida all'origine. Il campo cv= (chain validation) indica se la catena è intatta: none (primo hop), pass (catena valida) o fail (catena spezzata). Per saperne di più sul funzionamento di ARC, consulta la nostra guida su Authenticated Received Chain.

Le intestazioni che rivelano un servizio di terze parti

Quando un'azienda invia un'email tramite un servizio di terze parti (piattaforma marketing, CRM, strumento transazionale), le intestazioni conservano la traccia dell'infrastruttura reale di invio. È uno strumento potente per identificare chi invia davvero un'email, anche se il From mostra un dominio aziendale.

Tabella delle firme per provider

Provider	Intestazioni rivelatrici	Return-Path tipico	Message-ID / DKIM
SendGrid	X-SG-EID, X-SG-ID	@sendgrid.net o @em.sendgrid.net	DKIM d=sendgrid.net (se non c'è DKIM personalizzato)
Amazon SES	X-SES-Outgoing	@amazonses.com	Message-ID: @amazonses.com, DKIM d=amazonses.com
Mailgun	X-Mailgun-Sid, X-Mailgun-Variables	@mailgun.org	DKIM d=mailgun.org
Google Workspace	Received: from mail-*.google.com	@*.google.com	Message-ID: @mail.gmail.com
Microsoft 365	X-MS-Exchange-Organization-*, X-MS-Has-Attach	@*.outlook.com	DKIM d=*.onmicrosoft.com
Brevo (ex-Sendinblue)	X-Mailin-EID, X-Mailin-*	@mail-sib.com	DKIM d=sendinblue.com o personalizzato
Postmark	X-PM-Message-Id	@pm.mtasv.net	DKIM d=pm.mtasv.net
Mailchimp	X-MC-User, X-Mailer: MailChimp Mailer	@mcsv.net o @mail*.suw*.mcdlv.net	DKIM d=*.mcsv.net

Come usare questa tabella

Quando analizzi un'email sospetta, cerca le intestazioni X-* non standard e il dominio del Return-Path. Se un'email dice provenire da contact@captaindns.com e le intestazioni contengono X-SG-EID con un Return-Path in @sendgrid.net, sai che l'email è transitata da SendGrid. Non è necessariamente sospetto: basta verificare che captaindns.com utilizzi effettivamente SendGrid come provider di invio.

Al contrario, se un'email dice provenire dalla tua banca ma le intestazioni rivelano un invio da un piccolo provider SMTP sconosciuto, con un DKIM firmato da un dominio di terze parti senza relazione, è un segnale di allarme.

Leggere la catena Received (dal basso verso l'alto)

La catena delle intestazioni Received è la colonna portante dell'instradamento email. Ogni server che tocca il messaggio lascia la sua traccia.

Il principio: ogni server aggiunge in cima

Immagina una pila di timbri postali. L'ufficio postale di origine appone il primo timbro. Ogni ufficio intermedio aggiunge il suo sopra. L'ufficio di destinazione si trova in cima alla pila.

È esattamente ciò che accade con le intestazioni Received: il server di ricezione finale aggiunge la sua intestazione in cima. Il server di origine è in fondo. Per ricostruire il percorso cronologico del messaggio, leggi le intestazioni Received dal basso verso l'alto.

Anatomia di un hop

Ogni intestazione Received contiene quattro informazioni chiave:

Elemento	Significato	Esempio
from	Server che ha trasmesso il messaggio	mx-out.captaindns.com
by	Server che ha ricevuto il messaggio	mx-in.captaindns.com
with	Protocollo utilizzato	ESMTPS (SMTP crittografato TLS)
Timestamp	Data e ora di ricezione	Sat, 29 Mar 2026 10:15:02 +0100

Il protocollo with è rivelatore:

• ESMTPS: SMTP con TLS (crittografato, è lo standard atteso)
• ESMTP: SMTP senza TLS (non crittografato, problema potenziale)
• LMTP: protocollo di consegna locale (ultimo hop, normale)

Esempio concreto con 4 hop

Ecco una catena Received realistica per un'email ricevuta da captaindns.com, inviata da un collaboratore esterno tramite Gmail e filtrata da Mimecast. Le intestazioni sono presentate nell'ordine in cui compaiono nel messaggio grezzo (dal più recente al più vecchio):

(1) Received: from mx2.captaindns.com (10.0.0.5)
        by exchange.captaindns.com (10.0.0.10) with ESMTP;
        Fri, 29 Mar 2026 10:42:15 +0100

(2) Received: from gateway.mimecast.com (91.220.42.50)
        by mx2.captaindns.com with ESMTPS id A1B2C3D4;
        Fri, 29 Mar 2026 10:42:13 +0100

(3) Received: from mail-sor-f41.google.com (209.85.220.41)
        by gateway.mimecast.com with ESMTPS id E5F6G7H8;
        Fri, 29 Mar 2026 10:42:11 +0100

(4) Received: from [192.168.1.100] by smtp.gmail.com with ESMTPSA
        id I9J0K1L2; Fri, 29 Mar 2026 10:42:09 +0100

Lettura dal basso verso l'alto (ordine cronologico):

1. Hop 4 (10:42:09, il più vecchio, in basso): il mittente invia dal suo PC (IP privato 192.168.1.100) tramite il server SMTP di Gmail. Il protocollo ESMTPSA conferma una connessione autenticata e crittografata
2. Hop 3 (10:42:11): Gmail trasmette il messaggio al gateway Mimecast. ESMTPS indica una connessione TLS tra Google e Mimecast (filtro antispam/sicurezza del destinatario)
3. Hop 2 (10:42:13): Mimecast, dopo l'analisi del messaggio, lo trasmette al server MX di captaindns.com. Connessione ESMTPS, crittografia mantenuta
4. Hop 1 (10:42:15, il più recente, in alto): il MX interno trasmette al server Exchange finale per la consegna nella casella del destinatario. ESMTP senza TLS tra server interni, accettabile in una rete privata

Tempo totale di transito: 6 secondi. È normale. Oltre 30 secondi tra due hop consecutivi, c'è probabilmente un problema di prestazioni sul server responsabile del ritardo.

Rilevare le anomalie nella catena

Timestamp incoerenti. Un hop 3 datato prima dell'hop 2? È un orologio non sincronizzato (frequente su server mal configurati) oppure un'intestazione Received iniettata manualmente da un attaccante. Verifica se il server in questione è legittimo.

Hop mancanti. Il messaggio passa dal tuo server direttamente a un server sconosciuto, senza passare dal tuo gateway? Un intermediario non autorizzato potrebbe aver inoltrato il messaggio, oppure un server della catena non genera intestazioni Received (raro ma possibile).

Server sconosciuti. Un nome host o un IP che non riconosci nella catena? Verifica il DNS inverso dell'IP. Un server legittimo ha un PTR coerente con il suo nome host. Un server compromesso o un relay aperto ha spesso un PTR generico o inesistente.

IP privati in mezzo alla catena. Indirizzi in 10.x.x.x o 192.168.x.x sono normali per il primo hop (rete interna del mittente). Sono sospetti se compaiono più avanti nella catena, perché suggeriscono un instradamento anomalo.

Authentication-Results: SPF, DKIM, DMARC

L'intestazione Authentication-Results è il cruscotto della sicurezza email. Riassume in una riga i risultati dei tre protocolli di autenticazione. È la prima intestazione da verificare quando diagnostichi un problema.

Struttura del campo

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass (2048-bit key) header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject dis=none) header.from=captaindns.com

Il primo elemento (mx.captaindns.com) identifica il server che ha effettuato le verifiche. Ogni verdetto è separato da un punto e virgola.

Campo	Risultato	Significato
spf=pass	✓	Il server mittente è autorizzato dal record SPF
dkim=pass	✓	La firma crittografica è valida (selettore: s202603)
dmarc=pass	✓	SPF e DKIM sono allineati con il dominio From (policy: reject)

SPF: il server è autorizzato?

SPF (Sender Policy Framework) verifica se l'indirizzo IP del server di invio è autorizzato dal record DNS SPF del dominio.

Verdetto	Significato	Azione tipica
pass	L'IP è esplicitamente autorizzato	Accettato
fail	L'IP è esplicitamente vietato (-all)	Rifiutato o spam
softfail	L'IP non è autorizzato ma non è esplicitamente vietato (~all)	Accettato con diffidenza
neutral	Il dominio non si esprime (?all)	Nessun impatto
none	Nessun record SPF pubblicato	Nessuna verifica possibile
temperror	Errore DNS temporaneo	Nuovo tentativo successivo
permerror	Errore di sintassi nel record SPF	Varia a seconda del server

Il dettaglio tra parentesi (sender IP is 203.0.113.10) ti dà l'IP che è stato verificato. Il campo smtp.mailfrom indica il dominio della busta SMTP.

DKIM: il messaggio è integro?

DKIM verifica la firma crittografica del messaggio. Se la firma è valida, il contenuto non è stato modificato in transito e il dominio firmatario è autenticato.

Verdetto	Significato	Azione tipica
pass	Firma valida	Autenticato
fail	Firma non valida (messaggio modificato o chiave errata)	Sospetto
none	Nessuna firma DKIM presente	Nessuna verifica possibile
neutral	Firma presente ma non verificabile	Nessun impatto
temperror	Errore DNS temporaneo durante il recupero della chiave	Nuovo tentativo
permerror	Errore nel record DKIM	Varia

I dettagli importanti: header.d= indica il dominio firmatario, header.s= indica il selettore utilizzato. Queste informazioni ti permettono di verificare quale dominio ha realmente firmato il messaggio e con quale chiave.

DMARC: l'allineamento è corretto?

DMARC verifica che il dominio del From (visibile al destinatario) sia allineato con i domini autenticati da SPF e/o DKIM. È il livello che impedisce lo spoofing del campo From.

Verdetto	Significato	Azione tipica
pass	Allineamento SPF o DKIM verificato	Accettato
fail	Nessun allineamento valido	Applica la policy p=
bestguesspass	Nessuna policy DMARC pubblicata, ma il server ritiene che il messaggio sia legittimo	Accettato
none	Nessuna policy DMARC pubblicata	Nessuna azione

I dettagli DMARC includono:

• p=: la policy pubblicata dal dominio (none, quarantine, reject)
• dis=: la disposizione effettivamente applicata dal server
• header.from=: il dominio del From verificato

Esempio combinato: lettura completa

Ecco un Authentication-Results problematico:

Authentication-Results: mx.captaindns.com;
    spf=softfail (sender IP is 198.51.100.42) smtp.mailfrom=notifications.captaindns.com;
    dkim=fail (signature verification failed) header.d=captaindns.com header.s=s202603;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Diagnosi:

• SPF softfail: l'IP 198.51.100.42 non è nel record SPF di notifications.captaindns.com. Forse un nuovo server di invio non ancora dichiarato
• DKIM fail: la firma non è valida. Cause possibili: chiave DNS obsoleta, messaggio modificato in transito o rotazione della chiave mal sincronizzata
• DMARC fail: né SPF né DKIM passano con allineamento. La policy quarantine viene applicata: il messaggio viene messo in spam

Questo tipo di risultato segnala un problema di configurazione lato mittente, non un attacco. La correzione passa dall'aggiornamento del record SPF e dalla verifica della chiave DKIM.

Le intestazioni antispam

Oltre a SPF/DKIM/DMARC, i filtri antispam aggiungono le proprie intestazioni per giustificare le loro decisioni.

X-Spam-Score e X-Spam-Status

X-Spam-Status: No, score=-2.1 required=5.0
    tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_PASS
X-Spam-Score: -2.1

SpamAssassin utilizza un sistema di punteggio cumulativo. Ogni test aggiunge o sottrae punti. Un punteggio sopra la soglia (generalmente 5.0) classifica il messaggio come spam.

I test comuni:

Test	Punteggio tipico	Significato
BAYES_00	-1.9	Il contenuto assomiglia a ham (non spam) secondo il filtro bayesiano
DKIM_VALID_AU	-0.1	DKIM valido e allineato con il dominio autore
SPF_PASS	-0.0	SPF superato
HTML_MESSAGE	+0.0	Il messaggio contiene HTML (neutro)
URIBL_BLOCKED	+0.0	Le liste di URL non sono state consultabili
BAYES_99	+3.5	Il contenuto assomiglia molto a spam
MISSING_MID	+0.5	Nessun Message-ID (sospetto)

Il punteggio SCL di Exchange

L'intestazione X-MS-Exchange-Organization-SCL assegna un punteggio da 0 a 9:

SCL	Classificazione	Azione predefinita
-1	Mittente affidabile (lista bianca)	Consegna diretta
0-1	Non spam	Posta in arrivo
2-4	Probabilmente non spam	Posta in arrivo
5-6	Spam probabile	Cartella posta indesiderata
7-9	Spam certo	Rifiuto o quarantena

Le intestazioni di Google

Gmail non espone un punteggio antispam nelle intestazioni grezze. Tuttavia, troverai:

• X-Google-DKIM-Signature: firma DKIM aggiunta da Google in aggiunta a quella del mittente
• X-Gm-Message-State: stato interno del messaggio nell'infrastruttura Google (codificato, non interpretabile)
• X-Google-Smtp-Source: identificatore del server Google che ha elaborato il messaggio

La vista "Mostra originale" di Gmail mostra un riepilogo SPF/DKIM/DMARC in cima alla pagina, più leggibile rispetto alle intestazioni grezze.

Come interpretare i verdetti

Quando un filtro antispam classifica un messaggio come spam, cerca prima l'intestazione Authentication-Results. Se SPF, DKIM e DMARC sono tutti in pass, il problema viene probabilmente dal contenuto (parole chiave sospette, rapporto testo/immagine, link accorciati). Se uno dei tre fallisce, correggi prima l'autenticazione prima di intervenire sul contenuto.

Per capire come gli attaccanti sfruttano le falle nelle intestazioni per aggirare i filtri, consulta il nostro articolo sui segnali di allarme nelle intestazioni email.

6 scenari pratici di diagnostica

Scenario 1: la mia email finisce in spam

Intestazioni da verificare: Authentication-Results, X-Spam-Score (o SCL)

Metodo:

1. Chiedi al destinatario di estrarre le intestazioni del messaggio ricevuto in spam
2. Verifica Authentication-Results: se spf=fail o dkim=fail, è la causa probabile
3. Se SPF/DKIM/DMARC sono tutti in pass, guarda il punteggio antispam. Un X-Spam-Score superiore a 5.0 o un SCL di 5+ indica un filtraggio basato sul contenuto
4. Verifica la reputazione del tuo IP di invio tramite uno strumento di verifica delle blacklist

Esempio concreto: ecco l'intestazione che spiega perché un'email legittima finisce in spam.

Authentication-Results: mx.destinatario.com;
    spf=pass smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Qui, SPF e DKIM passano, ma DMARC fallisce. La causa probabile: il dominio SPF (mail.captaindns.com) non è allineato con il dominio From (captaindns.com) e DMARC richiede un allineamento rigoroso (aspf=s). La disposizione dis=quarantine conferma che il messaggio è stato messo in spam.

Correzione rapida: pubblica o correggi il tuo record SPF, verifica la tua firma DKIM e implementa una policy DMARC almeno in p=none per iniziare a ricevere rapporti.

Scenario 2: questa email viene davvero dal mio direttore?

Intestazioni da verificare: From, Return-Path, DKIM-Signature, Authentication-Results

Esempio concreto: un'email che sembra provenire dal tuo CEO ma è una truffa CEO fraud.

From: Jean-Marc Duval - CEO <jm.duval@captaindns.com>
Return-Path: <jmduval.ceo@gmail.com>
Reply-To: jmduval.urgent@protonmail.com
Authentication-Results: mx.captaindns.com;
    spf=pass smtp.mailfrom=gmail.com;
    dkim=pass header.d=gmail.com;
    dmarc=fail header.from=captaindns.com

Il display name mostra "Jean-Marc Duval - CEO" e l'indirizzo From mostra captaindns.com. Ma il Return-Path punta a un account Gmail, il Reply-To a ProtonMail, e DMARC fallisce perché DKIM è firmato da gmail.com, non da captaindns.com. È una classica truffa CEO fraud.

Metodo:

1. Confronta il From con il Return-Path. Se puntano a domini diversi senza ragione legittima (nessun servizio di invio di terze parti noto), è un segnale di allarme
2. Verifica Authentication-Results: un dmarc=fail su un'email che dice provenire dal dominio della tua azienda conferma un'impersonificazione
3. Esamina DKIM-Signature: il d= dovrebbe corrispondere al dominio della tua azienda
4. Guarda il Reply-To: se punta a un dominio esterno (gmail.com, protonmail.com), è una classica truffa CEO fraud

Regola d'oro: se From dice una cosa e Authentication-Results ne dice un'altra, fidati dei risultati di autenticazione. Solo il 4 % dei domini applica una policy DMARC p=reject (Valimail 2025), il che lascia la porta aperta a questo tipo di impersonificazione sulla grande maggioranza dei domini.

Scenario 3: da quanto tempo è in transito la mia email?

Intestazioni da verificare: i timestamp di ogni intestazione Received

Metodo:

1. Elenca tutte le intestazioni Received dal basso verso l'alto
2. Annota il timestamp di ogni hop
3. Calcola il ritardo tra ogni coppia di hop consecutivi
4. L'hop con il ritardo maggiore è il collo di bottiglia

Soglie indicative:

• Meno di 5 secondi tra due hop: normale
• Da 5 a 30 secondi: accettabile per un server sotto carico
• Più di 30 secondi: problema di greylisting, coda satura o DNS lento
• Più di 5 minuti: il server ha probabilmente messo il messaggio in coda e lo ha ritentato

Scenario 4: il mio DKIM è firmato correttamente?

Intestazioni da verificare: DKIM-Signature, Authentication-Results

Metodo:

1. Localizza l'intestazione DKIM-Signature nel messaggio grezzo
2. Verifica che d= corrisponda al tuo dominio di invio
3. Annota il selettore s= e verifica che il record DNS corrispondente sia pubblicato
4. Guarda il verdetto DKIM in Authentication-Results: dkim=pass conferma che tutto funziona

Cause frequenti di fallimento DKIM:

• Chiave DNS eliminata o pubblicata in modo errato
• Rotazione della chiave senza aggiornamento del server di invio
• Modifica del messaggio in transito (da una mailing list o uno strumento di riscrittura URL)
• Intestazione h= che non copre tutte le intestazioni modificate

Scenario 5: questo link è phishing?

Intestazioni da verificare: From, Reply-To, Return-Path, Authentication-Results, ARC-*

Metodo:

1. Verifica il From: il dominio è esattamente quello atteso? Attenzione agli omoglifi (captaindns.com vs captaindnss.com vs captaindns.co)
2. Confronta con il Return-Path: un dominio completamente diverso è sospetto
3. Verifica Authentication-Results: spf=fail + dkim=fail + dmarc=fail su un'email presumibilmente legittima è un segnale forte di phishing
4. Se il messaggio è stato inoltrato, verifica le intestazioni ARC-Authentication-Results per vedere se l'autenticazione era valida al punto di origine
5. Un Reply-To verso un dominio gratuito (gmail.com, yahoo.com) su un'email aziendale è un classico del phishing

Per approfondire le tecniche di spoofing durante l'instradamento email, leggi la nostra analisi sullo spoofing tramite l'instradamento email e l'avviso Microsoft.

Scenario 6: un fornitore dice di aver inviato un'email mai ricevuta

Intestazioni da verificare: i timestamp Received, Authentication-Results

Contesto: il tuo fornitore afferma di aver inviato una fattura il 15 marzo. Non l'hai mai ricevuta. Chi ha ragione?

Metodo:

1. Chiedi al fornitore di inviarti le intestazioni complete del messaggio originale (non un inoltro, ma le intestazioni del messaggio inviato)
2. Verifica il primo Received (in basso): contiene il timestamp dell'invio iniziale. Se il timestamp corrisponde al 15 marzo, il messaggio è stato effettivamente inviato al server SMTP
3. Segui la catena Received hop per hop. Se l'ultimo hop mostra una consegna al tuo server MX, il messaggio è stato ricevuto dalla tua infrastruttura e il problema è nel filtraggio
4. Se la catena si interrompe prima del tuo MX, verifica Authentication-Results: un spf=fail o dmarc=fail può aver provocato un rifiuto silenzioso da parte del tuo server

Consiglio: i timestamp delle intestazioni Received costituiscono una prova tecnica con marca temporale del transito del messaggio. In caso di contestazione, documentano oggettivamente se l'email è stata inviata, quando e fino a dove è arrivata nella catena di instradamento.

Piano d'azione: 5 passi per padroneggiare le intestazioni

Ora hai le conoscenze teoriche. Ecco come metterle in pratica.

Passo 1: estrarre e analizzare una prima email

Scegli un'email che hai inviato tu stesso (o un'email di test). Estrai le intestazioni con il metodo adatto al tuo client di posta. Incollale nello strumento di analisi delle intestazioni e confronta il risultato automatico con la tua lettura manuale.

Passo 2: verificare la tua autenticazione

Invia un'email dal tuo dominio a un indirizzo Gmail. Apri le intestazioni e verifica che SPF, DKIM e DMARC mostrino tutti pass. Se uno dei tre fallisce, identifica e correggi la causa prima di passare al passo successivo.

Passo 3: imparare a individuare le anomalie

Allenati con email legittime per calibrare il tuo senso della normalità. Quando sai com'è un'email "sana", le anomalie in un'email sospetta diventano evidenti: server sconosciuti nella catena Received, domini che non corrispondono tra From e Return-Path, firme DKIM non valide.

Passo 4: automatizzare la sorveglianza

Non verificare le intestazioni manualmente per ogni email. Configura DMARC con rua= per ricevere rapporti aggregati quotidiani. Questi rapporti ti avvisano automaticamente quando le email falliscono l'autenticazione per il tuo dominio.

Passo 5: documentare i tuoi flussi di invio

Elenca tutti i servizi che inviano email per tuo conto (CRM, strumento marketing, ticketing, fatturazione). Per ciascuno, verifica che SPF e DKIM siano configurati correttamente. Un flusso di invio dimenticato è la causa più frequente di fallimenti DMARC inattesi.

Conserva un documento condiviso con il tuo team che elenchi ogni servizio, l'IP o il dominio di invio, il selettore DKIM utilizzato e la data dell'ultima verifica. Questo riferimento ti eviterà di cercare la causa di un fallimento DMARC per ore quando un collega aggiunge un nuovo strumento di invio senza avvisare il team tecnico.

FAQ

Che cos'è un'intestazione email?

Un'intestazione email è una riga di metadati nel formato "Nome: Valore" che accompagna ogni messaggio. Le intestazioni contengono le informazioni di instradamento (server attraversati), i risultati di autenticazione (SPF, DKIM, DMARC), l'identità del mittente e del destinatario, e annotazioni aggiunte dai filtri antispam. Il corpo del messaggio (testo, immagini, allegati) è separato dalle intestazioni da una riga vuota.

Come vedere le intestazioni in Gmail?

Apri l'email in questione, clicca sul menu dei tre punti verticali in alto a destra del messaggio e seleziona "Mostra originale". Gmail apre una nuova pagina con le intestazioni complete e un riepilogo dei risultati SPF, DKIM e DMARC in alto. Puoi copiare l'intero contenuto delle intestazioni con il pulsante "Copia negli appunti".

Perché le intestazioni Received si leggono dal basso verso l'alto?

Ogni server SMTP che elabora un'email aggiunge la sua intestazione Received sopra le intestazioni esistenti. Il primo server (origine) si trova quindi in basso e l'ultimo server (ricezione) in alto. Per ricostruire il percorso cronologico del messaggio, bisogna leggere le intestazioni Received dal basso verso l'alto. È un meccanismo definito dalla RFC 5321.

Che cosa significa spf=softfail in Authentication-Results?

Un verdetto spf=softfail significa che l'indirizzo IP del server di invio non è esplicitamente autorizzato dal record SPF del dominio, ma non è nemmeno esplicitamente vietato. Corrisponde al meccanismo ~all (tilde) nel record SPF. Il server di ricezione generalmente accetta il messaggio ma lo tratta con diffidenza. È spesso il segno di un server di invio dimenticato nella configurazione SPF.

Come rilevare un'email oggetto di spoofing tramite le intestazioni?

Confronta tre elementi: il campo From (indirizzo visualizzato), il Return-Path (indirizzo di rimbalzo) e il dominio in DKIM-Signature (d=). Se il From mostra un dominio legittimo ma il Return-Path punta a un dominio diverso e Authentication-Results mostra dmarc=fail, il messaggio è probabilmente oggetto di spoofing. Un SPF fail combinato con un DKIM fail conferma che il server di invio non è autorizzato dal dominio visualizzato.

Le intestazioni possono essere falsificate?

Alcune intestazioni possono essere falsificate dal mittente: From, Reply-To, Subject e persino alcune intestazioni Received. Al contrario, le intestazioni aggiunte dal server di ricezione (Authentication-Results, Received del server finale, X-Spam-Score) sono affidabili perché generate dalla tua stessa infrastruttura. Ecco perché bisogna sempre basarsi sui risultati di autenticazione del server di ricezione, non sulle intestazioni definite dal mittente.

Qual è la differenza tra From e Return-Path?

Il From è l'indirizzo visualizzato nel client di posta, definito dal mittente nel corpo delle intestazioni del messaggio. Il Return-Path è l'indirizzo della busta SMTP (MAIL FROM), utilizzato per le notifiche di rimbalzo. Possono legittimamente differire quando un servizio di terze parti invia email per tuo conto. DMARC verifica l'allineamento tra questi due indirizzi: se i domini sono troppo diversi senza ragione valida, il messaggio può fallire la verifica DMARC.

Come automatizzare l'analisi delle intestazioni?

Incolla le tue intestazioni grezze in uno strumento di analisi come quello di CaptainDNS. Lo strumento scompone ogni campo, calcola i ritardi tra gli hop Received, verifica i risultati di autenticazione e mette in evidenza le anomalie. Per una sorveglianza continua, configura DMARC con un indirizzo rua= per ricevere rapporti aggregati quotidiani sull'autenticazione di tutte le email inviate dal tuo dominio.

Glossario

• Intestazione email (header): riga di metadati nel formato "Nome: Valore" che accompagna ogni messaggio, contenente le informazioni di instradamento, autenticazione ed elaborazione.
• Received: intestazione aggiunta da ogni server SMTP attraversato, che forma la traccia di instradamento del messaggio. Si legge dal basso verso l'alto per ricostruire l'ordine cronologico.
• Return-Path: indirizzo della busta SMTP (MAIL FROM) a cui vengono inviati i messaggi di rimbalzo. Aggiunto dal server di ricezione finale.
• Authentication-Results: intestazione aggiunta dal server di ricezione che riassume i verdetti delle verifiche SPF, DKIM e DMARC.
• SPF (Sender Policy Framework): protocollo che verifica se l'indirizzo IP del server di invio è autorizzato dal DNS del dominio mittente (RFC 7208).
• DKIM (DomainKeys Identified Mail): protocollo di autenticazione tramite firma crittografica che verifica l'integrità e l'origine di un messaggio (RFC 6376).
• DMARC (Domain-based Message Authentication, Reporting and Conformance): protocollo che verifica l'allineamento del dominio From con i domini autenticati da SPF e DKIM (RFC 7489).
• ARC (Authenticated Received Chain): meccanismo che preserva i risultati di autenticazione quando un messaggio attraversa intermediari come le mailing list.
• Folding: tecnica di continuazione di un'intestazione su più righe, identificata da un'indentazione (spazio o tabulazione) all'inizio della riga successiva.
• SCL (Spam Confidence Level): punteggio spam assegnato da Microsoft Exchange, da -1 (affidabile) a 9 (spam certo).
• Hop: passaggio di un messaggio da un server SMTP a un altro nella catena di instradamento. Ogni hop è documentato da un'intestazione Received.
• ESMTPS: Extended SMTP con TLS, che indica una trasmissione crittografata tra due server.

Fonti

• RFC 5322 - Internet Message Format
• RFC 7601 - Message Header Field for Indicating Message Authentication Status
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Google Support - Visualizzare le intestazioni complete del messaggio
• Verizon 2025 Data Breach Investigations Report (DBIR)
• IBM Cost of a Data Breach Report 2025
• Egress Email Security Risk Report 2024
• Valimail Email Authentication Report 2025