Leggere le intestazioni: da dove proveniva questa mail?

Modulo 1: Come funziona la posta elettronica · Tempo di lettura: 11 minuti

Obiettivo della lezione: dopo questa lezione sarà in grado di aprire le intestazioni di una mail, leggere le righe Received nell'ordine corretto e capire, a partire da Authentication-Results, se SPF, DKIM e DMARC erano corretti.

Concetti chiave: intestazioni (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, intestazioni X, fonte o messaggio originale

Ciò che normalmente non vede

Il Suo programma di posta mostra di una mail solo poche informazioni: mittente, oggetto, data, destinatari. In realtà ogni mail ha decine di intestazioni (headers) in cima, prima del testo. Vengono aggiunte dal programma del mittente e da ogni server che la mail incontra lungo il percorso. Insieme formano il resoconto del viaggio della mail.

Chi sa leggere le intestazioni può rispondere da solo a molte domande: questa mail proviene davvero dalla mia banca? Perché è arrivata solo dopo due ore? Perché è finita nello spam? Il mio DKIM è corretto? Molti esercizi di questo corso Le chiederanno di esaminare le intestazioni. In questa lezione imparerà come fare.

Aprire le intestazioni

Ogni programma ha un pulsante diverso per farlo:

Su un telefono di solito non è possibile. In tal caso, inoltri la mail a Lei stesso come allegato, oppure la apra nella webmail.

Un esempio

Jan riceve una mail da Anna. Ecco come appaiono le principali intestazioni (abbreviate):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Righe Received: dal basso verso l'alto

Ogni server che inoltra la mail aggiunge una riga Received: in cima. La più vecchia si trova quindi in fondo, la più recente in cima. Le legga dal basso verso l'alto per seguire il percorso:

1. Riga più in basso: il portatile di Anna (IP 198.51.100.77, la sua connessione domestica) consegna a out.hosting.example, con ESMTPSA (la A sta per authenticated: si era autenticata) e TLS 1.3. Alle 10:15:04.
2. Riga centrale: out.hosting.example (192.0.2.25) consegna a mx1.mailprovider.example, l'MX di example.net. Alle 10:15:07.
3. Riga più in alto: il server di posta inserisce internamente la mail nella mailbox di Jan (LMTP). Alle 10:15:09.

Una riga Received ha sempre la forma from <chi l'ha offerta> by <chi l'ha ricevuta> with <protocollo>; <orario>. Tra parentesi dopo from compare ciò che il server ricevente ha effettivamente rilevato: il nome reale (PTR) e l'indirizzo IP reale. Questa parte è affidabile nella misura in cui Lei si fida di quel server ricevente. Ciò che il mittente stesso ha dichiarato (helo=) non è verificabile.

Due trucchi pratici:

• Individuare un ritardo: confronti gli orari. Se tra due righe ci sono due ore, la mail è rimasta così a lungo in una coda. Faccia attenzione ai fusi orari (+0100, +0000).
• Trovare il vero server mittente: cerchi la riga Received più in alto scritta da un server del destinatario stesso, e guardi cosa compare lì dopo from. Tutto ciò che sta sotto è stato scritto dal lato mittente e, in teoria, potrebbe essere stato falsificato. Nell'esempio, 192.0.2.25 è il server che ha consegnato presso il destinatario; su quello vengono valutati l'SPF e la reputazione.

Gli indirizzi

Un trucco noto dei truffatori: un From che assomiglia a quello della Sua banca, con un Reply-To verso un indirizzo del tutto diverso. In caso di dubbio, guardi sempre il dominio in From e in Return-Path, e Authentication-Results.

Authentication-Results: il giudizio del destinatario

Il server ricevente inserisce in Authentication-Results (RFC 8601) l'esito dei propri controlli:

• spf=pass smtp.mailfrom=example.com: l'IP del server che ha consegnato la mail compare nel record SPF del dominio presente in Return-Path.
• dkim=pass header.d=example.com header.s=x: la firma DKIM del dominio example.com, con chiave (selector) x, è corretta.
• dmarc=pass header.from=example.com: il dominio in From è allineato con un SPF o un DKIM riuscito, quindi il DMARC è superato.

Altri esiti che può incontrare: fail (non corretto), softfail (l'SPF termina con ~all e l'IP non vi compare), neutral, none (nessun record), temperror (errore DNS temporaneo) e permerror (record non valido, ad esempio due record SPF). Cosa significano esattamente e come ripararli è spiegato nel modulo 4.

Attenzione: si fidi solo dell'Authentication-Results del server del destinatario stesso (il nome in testa, qui mx1.mailprovider.example). Una mail falsificata può includere un proprio Authentication-Results inventato. I server ben configurati lo rimuovono, ma non tutti.

DKIM-Signature: la firma

L'intestazione DKIM-Signature è la firma stessa. Due campi Le servono spesso:

• d= il dominio che firma (qui example.com);
• s= il selector, il nome della chiave (qui x).

Con questi dati trova la chiave pubblica nel DNS: x._domainkey.example.com. Negli esercizi e nella risoluzione dei problemi dovrà spesso cercare esattamente questi due valori. Una mail può avere più firme DKIM, ad esempio una del Suo dominio e una del servizio di invio. Nella lezione 4.3 approfondiremo questo aspetto.

A volte vede anche ARC-Seal, ARC-Message-Signature e ARC-Authentication-Results. ARC (RFC 8617) è un metodo con cui le stazioni intermedie, come una mailing list o un server di reindirizzamento, registrano quali erano i controlli prima che esse modificassero la mail. Per ora non deve saperle interpretare.

Intestazioni X

Le intestazioni che iniziano con X- non sono standardizzate. I filtri antispam vi inseriscono il proprio punteggio, ad esempio X-Spam-Status: No, score=1.2 o X-Spam-Flag: YES. Questo aiuta a capire perché qualcosa è finito nello spam. Variano a seconda del fornitore.

Riepilogo

• Le intestazioni sono il resoconto del viaggio di una mail. Le apra con "visualizza originale", "sorgente del messaggio" o funzioni simili.
• Legga le righe Received dal basso verso l'alto. La riga scritta dal server del destinatario indica quale IP ha consegnato la mail.
• Return-Path è il mittente di busta (SPF), From il mittente visibile (DMARC), Reply-To indica dove vanno le risposte.
• Authentication-Results riporta il giudizio su SPF, DKIM e DMARC; si fidi solo di quello del server ricevente.
• In DKIM-Signature compaiono d= (dominio) e s= (selector); insieme indicano la posizione della chiave: s._domainkey.d.

Quiz

Esercizio

Opdracht Z1.5: Trovare il primo server di posta. Si invii una mail da un indirizzo diverso (ad esempio dal Suo indirizzo di lavoro a quello privato, o viceversa), apra le intestazioni e le incolli nel modulo. Se non ha un secondo indirizzo, usi il file di esempio kopregels-1.txt allegato all'esercizio. Compili poi Lei stesso: l'indirizzo IP del server che ha consegnato presso il destinatario, il dominio nel Return-Path, il dominio e il selector della firma DKIM, e l'esito di SPF, DKIM e DMARC. Il programma analizza le stesse intestazioni, cerca in tempo reale la chiave DKIM e mette a confronto il proprio risultato con il Suo. Le Sue intestazioni non vengono conservate.

Per saperne di più

I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri fornitori il funzionamento è simile.

• Verificare se un'e-mail è stata consegnata con il tracciamento e-mail in DirectAdmin
• Guida DirectAdmin 9.3: Tracciamento Email: dove è finita la mia mail?
• Questa email è davvero di WebOké? Riconoscere il phishing e utilizzare il codice promozionale
• Corso gratuito DNS 4.4: DKIM: la firma sotto la Sua posta
• RFC 5322 (struttura di una mail), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)