Come leggere le intestazioni complete di una email

In breve: Le intestazioni complete email mostrano il percorso tecnico del messaggio, i server attraversati, gli orari, l’identificativo Message-ID, il Return-Path e i risultati SPF, DKIM e DMARC.

Intestazioni complete email: obiettivo e requisiti

Questa guida approfondisce intestazioni complete email con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.

Che cosa significa

Il campo From visibile non dimostra da solo l’origine del messaggio. Return-Path, Received e Authentication-Results forniscono informazioni più utili.

Le righe Received vengono aggiunte da ogni server e si leggono normalmente dal basso verso l’alto per ricostruire il percorso.

Come riconoscere il problema

• Un messaggio sembra falso.
• La consegna è arrivata in ritardo.
• SPF o DKIM risultano fail.
• Il mittente visibile differisce dal Return-Path.
• Serve correlare il messaggio con Track Delivery.

Cause più frequenti

1. Spoofing

Il From è stato falsificato senza autenticazione valida. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

2. Forwarding

SPF può fallire dopo inoltro mentre DKIM resta valido.

3. Ritardo tra server

I timestamp Received mostrano dove il messaggio è rimasto in attesa.

4. Servizio esterno

Newsletter e CRM usano Return-Path o DKIM differenti.

5. Message-ID anomalo

Il software mittente può generare identificativi non coerenti.

6. Filtro antispam

Authentication-Results e intestazioni X-Spam indicano valutazioni.

Diagnosi passo per passo

1. Mostra l’originale. Usa la funzione del client per visualizzare sorgente o intestazioni complete. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
2. Salva il contenuto in modo sicuro. Oscura indirizzi e IP quando lo condividi pubblicamente. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
3. Trova Authentication-Results. Leggi SPF, DKIM e DMARC. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
4. Confronta From e Return-Path. Valuta l’allineamento. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
5. Leggi Received dal basso. Ricostruisci server e tempi. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
6. Trova Message-ID. Usalo per Track Delivery e log. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
7. Controlla Date e timezone. Distingui ritardo reale da fuso orario. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.

Procedura di risoluzione

1. Correggi autenticazione. Aggiorna SPF, DKIM e DMARC del servizio legittimo. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
2. Contatta il provider giusto. Individua il server che ha introdotto il ritardo. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
3. Segnala spoofing. Fornisci header completi oscurando dati non necessari. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
4. Verifica inoltri. Controlla se forwarding ha alterato SPF o DKIM. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
5. Correla Track Delivery. Usa Message-ID, destinatario e orario. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
6. Conserva una copia originale. Non inoltrare soltanto uno screenshot. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
7. Forma gli utenti. Spiega che nome e logo non provano l’identità. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.

Domande frequenti

Guide Xlogic correlate

• DMARC p=none, quarantine e reject: differenze
• Email Deliverability in cPanel: controllare SPF, DKIM e DMARC
• DKIM body hash did not verify: cause e soluzioni

Fonti tecniche

• IETF RFC 5322: Internet Message Format