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. Sono fondamentali per analizzare ritardi, spoofing, spam e problemi di consegna.
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. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
3. Ritardo tra server
I timestamp Received mostrano dove il messaggio è rimasto in attesa. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
4. Servizio esterno
Newsletter e CRM usano Return-Path o DKIM differenti. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
5. Message-ID anomalo
Il software mittente può generare identificativi non coerenti. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
6. Filtro antispam
Authentication-Results e intestazioni X-Spam indicano valutazioni. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
Diagnosi passo per passo
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Metodo sicuro di intervento
Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.
Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.
Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.
Procedura di risoluzione
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Controlli finali
- Percorso ricostruito.
- SPF DKIM DMARC interpretati.
- Message-ID trovato.
- Ritardo localizzato.
- Dati sensibili protetti.
Prevenzione
- Conserva header per incidenti.
- Configura DMARC.
- Evita forwarding critici.
- Usa client aggiornati.
- Forma gli utenti.
Errori da evitare
- Non pubblicare header completi senza oscurare.
- Non leggere Received dall’alto come primo passaggio.
- Non fidarti soltanto del From.
- Non modificare l’originale.
- Non confondere Date con orario di ricezione.
Come documentare la verifica
Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.
Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.
Controllo incrociato
Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.
Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- header come allegato testuale
- Message-ID
- mittente e destinatario
- data e ora
- problema osservato
Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.
Fonti tecniche ufficiali
Domande frequenti su intestazioni complete email
Dove trovo le intestazioni complete?
Nel client usa funzioni come Mostra originale, Visualizza sorgente o Intestazioni Internet.
Come si leggono le righe Received?
Normalmente dal basso verso l’alto per seguire il percorso iniziale.
Il From prova chi ha inviato?
No. Deve essere confrontato con autenticazione e percorso.
Che cos’è il Message-ID?
Un identificativo del messaggio utile per correlare log e consegna.
Posso inviare uno screenshot al supporto?
È meglio allegare il testo originale o un file .eml, oscurando dati non necessari.