Domande frequenti

echo.email analizza un’email per indirizzo e spiega il risultato. Le risposte qui sotto spiegano come funziona il servizio e cosa significa ogni controllo del report.

Come funziona echo.email?

La pagina iniziale genera un nuovo indirizzo composto da tre parole, come power.file.tube@echo.email. Un messaggio inviato a quell’indirizzo arriva al server di posta di echo.email, che registra la conversazione SMTP e passa il messaggio all’analisi. Pochi secondi dopo, la pagina mostra un report su autenticazione, contenuto, conformità e consegna. Non serve installare nulla e non esistono account.

Per quanto tempo resta valido l’indirizzo?

L’indirizzo resta attivo per tutto il tempo in cui la pagina resta aperta. La pagina contatta il server ogni due secondi, e se la ricarichi entro 10 minuti mantieni lo stesso indirizzo nella stessa scheda. Quando la pagina resta chiusa per più di 10 minuti, il server di posta rifiuta i nuovi messaggi per l’indirizzo con un errore permanente.

Viene considerato solo il primo messaggio che arriva. I messaggi successivi per lo stesso indirizzo vengono rifiutati, quindi ogni report corrisponde esattamente a un’email. I messaggi oltre 10 MB vengono rifiutati durante la conversazione SMTP.

Per quanto tempo vengono conservati i report?

Ogni report, il messaggio salvato e i dati delle immagini scaricate vengono eliminati automaticamente 24 ore dopo l’arrivo del messaggio. Durante queste 24 ore il link del report funziona per chiunque abbia il link. Dopo, il link smette di funzionare. L’unica eccezione è il report di esempio, perché nasce da un messaggio di test inviato apposta.

Cosa succede al contenuto del messaggio?

echo.email salva il messaggio intero, cioè intestazioni, corpo e allegati, insieme ai dati della sessione SMTP, come l’indirizzo IP di invio, il nome HELO e la versione di TLS. I dati restano nell’UE, e il server di posta funziona a Falkenstein, in Germania. Chiunque abbia il link del report vede il messaggio completo, quindi conviene testare con contenuti che puoi condividere. Le newsletter spesso contengono link di tracciamento e un link di disiscrizione legato a un destinatario. Se invii una copia a una lista di test, quei link restano privati.

Due indirizzi arrivano direttamente al gestore del servizio: contact@echo.email per domande e segnalazioni di abuso, e privacy@echo.email per le richieste sui dati. La privacy policy contiene tutti i dettagli.

Cosa verifica il controllo SPF?

SPF elenca i server autorizzati a inviare posta con un dominio nel return path. echo.email prende il dominio del mittente della busta (l’indirizzo MAIL FROM, detto anche return path) e valuta il record SPF di quel dominio per l’indirizzo IP del server che consegna il messaggio. Solo un pass conta come buon risultato. Con softfail, neutral o none il destinatario resta senza una prova SPF del mittente.

Il nome HELO non viene controllato, come fanno i grandi provider di posta quando valutano SPF per gli invii massivi. Il report mostra ogni record e ogni meccanismo lungo il percorso, così si vede come si arriva al risultato finale.

Perché conta il numero di query DNS?

Una valutazione SPF può fare al massimo 10 query DNS. I meccanismi include, a, mx, ptr, exists e redirect contano per questo limite, compresi quelli dentro include annidati. Superare il limite trasforma il risultato in un errore permanente, e i destinatari trattano il messaggio come se non avesse alcun SPF valido. Le query vuote, cioè le query che non restituiscono un record, hanno un limite separato di due. La causa abituale sono lunghe catene di include di terzi, e ridurre l’elenco dei servizi risolve il problema.

Cosa dimostra DKIM?

DKIM aggiunge una firma crittografica alle intestazioni del messaggio. Il dominio che firma pubblica la chiave pubblica nel DNS sotto un selettore. echo.email recupera la chiave e verifica la firma sulle intestazioni e sul corpo così come sono arrivati. Un pass significa che le parti firmate sono arrivate senza modifiche e che il dominio che firma ne risponde.

Il report mostra il dominio che firma (d=), il selettore (s=), le intestazioni firmate (h=) e il tipo e la dimensione della chiave. Un limite di lunghezza del corpo (l=) viene segnalato, perché permette di aggiungere contenuto dopo la firma.

Cos’è DMARC?

DMARC collega SPF e DKIM al dominio dell’indirizzo From visibile. Il dominio From pubblica una policy su _dmarc.<domain> che dice ai destinatari come trattare la posta che non passa l’autenticazione: none, quarantine o reject. Un messaggio passa il controllo DMARC quando SPF o DKIM passa per un dominio allineato con il dominio From.

DMARC non aggiunge un’autenticazione propria. Il suo valore sta nel requisito di allineamento e nei report aggregati (rua=) che i destinatari mandano al proprietario del dominio.

Cosa significa allineato?

L’allineamento confronta un dominio autenticato con il dominio From. L’allineamento flessibile richiede lo stesso dominio organizzativo, quindi mail.example.com si allinea con example.com. L’allineamento rigoroso richiede esattamente lo stesso nome host. Il dominio organizzativo viene dalla Public Suffix List, che sa che nomi come example.co.uk contano come un unico dominio registrabile. Quando il report dice allineato senza altre indicazioni, il confronto è con il dominio From.

Cos’è BIMI?

BIMI pubblica il logo di un marchio che i provider di posta mostrano accanto ai messaggi autenticati. Il record si trova su default._bimi.<domain> e punta a un logo SVG (l=) e, per la maggior parte dei provider, a un Verified Mark Certificate (a=). BIMI vale solo per domini con una policy DMARC applicata, cioè quarantine o reject al 100 per cento. echo.email mostra il record e indica se la policy DMARC rispetta il requisito.

Perché conta il DNS inverso?

Ogni indirizzo IP che invia posta ha bisogno di un record PTR che punti a un nome host, e quel nome ha bisogno di un record A o AAAA che punti di nuovo allo stesso indirizzo IP. Questo percorso di andata e ritorno si chiama forward-confirmed reverse DNS, o FCrDNS. I grandi provider di posta considerano FCrDNS il minimo per un server di invio, e la posta da un indirizzo IP senza record PTR viene spesso rifiutata subito.

Cos’è il DNS inverso generico?

Alcuni record PTR seguono uno schema di nomi del provider internet, come 192-0-2-10.dynamic.example.net. Nomi del genere fanno pensare a una connessione domestica o a un server che nessuno ha configurato per la posta, e i filtri li trattano con sospetto. Un nome dedicato nel dominio del mittente, come mail.example.com, indica un server di posta configurato apposta.

Quale nome HELO funziona meglio?

Il server di invio si presenta con un nome HELO o EHLO all’inizio della conversazione SMTP. Un buon nome appartiene al server di invio, si risolve nel DNS e corrisponde al record PTR dell’indirizzo IP di invio. Indirizzi IP senza nome, nomi come localhost e stringhe casuali sono tipici del malware e dello spam snowshoe, e i filtri ne tengono conto.

Perché controllare TLS?

Il TLS opportunistico cifra la conversazione SMTP quando il server di ricezione offre STARTTLS. echo.email offre STARTTLS su ogni connessione e registra la versione di TLS e il cifrario scelti dal mittente. La posta inviata senza TLS viaggia in chiaro tra i due server, e Google e Yahoo richiedono TLS ai mittenti di invii massivi. Il report conta anche i link e le immagini caricati via http semplice, perché anche quelle richieste viaggiano senza cifratura.

Perché controllare IPv6?

Due domande decidono se un messaggio è pronto per IPv6. La prima è se il mittente raggiunge server di posta che usano solo IPv6. Un messaggio che arriva via IPv6 risponde sì direttamente. Un messaggio che arriva via IPv4 conta comunque come compatibile con IPv6 quando l’host di invio ha un record AAAA, il DNS inverso di quell’indirizzo IPv6 punta allo stesso host e SPF passa per quell’indirizzo. La maggior parte dei server di posta sceglie IPv4 o IPv6 a ogni connessione, quindi il messaggio successivo dallo stesso host spesso arriva via IPv6. La seconda domanda è se ogni host che serve immagini e link del messaggio ha un record AAAA, così un lettore su una rete solo IPv6 o dietro un NAT dell’operatore (CGNAT) carica comunque il contenuto. Il report segna il messaggio come pronto per IPv6 quando entrambe le risposte sono sì.

Come si misura la dimensione dell’email?

La dimensione dell’email è il numero di byte trasmessi: tutte le intestazioni, ogni parte MIME, gli allegati e l’aumento dovuto alla codifica base64 o quoted-printable. Gmail taglia i messaggi con più di circa 102 KB di HTML e nasconde il resto dietro un link. La parte tagliata contiene spesso il link di disiscrizione e il pixel di tracciamento.

Cos’è il peso delle immagini?

Il peso delle immagini è la dimensione totale delle immagini remote richiamate nei tag <img>, misurata scaricando ogni immagine una volta. Il numero è un minimo, perché le immagini negli attributi srcset e gli sfondi CSS non vengono contati. Un messaggio pesante si carica lentamente sulle connessioni mobili e consuma i dati del lettore.

Cos’è l’eccesso delle immagini?

L’eccesso delle immagini stima i byte che un mittente risparmierebbe servendo ogni immagine più vicina alla dimensione con cui il messaggio la mostra. Un’immagine fino al doppio della dimensione visualizzata conta come eccesso zero, perché gli schermi ad alta densità usano i pixel in più. Oltre il doppio della dimensione visualizzata, i pixel in più aggiungono byte senza aggiungere dettagli. Le immagini sotto 1 KB, come gli spaziatori, restano fuori dal conteggio.

Come gestisce echo.email le immagini?

L’analisi scarica ogni immagine remota una volta e registra lo stato HTTP, i reindirizzamenti, la dimensione, il tipo di contenuto e le dimensioni in pixel. Poi confronta queste dimensioni con la dimensione dichiarata nell’HTML. Scaricare un’immagine è ciò che fa un programma di posta quando un lettore apre il messaggio, quindi il tracciamento delle aperture registra un’apertura. I download partono dalla rete di Cloudflare, e le richieste verso indirizzi privati o interni vengono rifiutate.

I link vengono estratti dall’HTML e raggruppati per host, con i parametri della query decodificati per renderli leggibili. echo.email non segue mai i link normali, perché seguire un link può confermare un’iscrizione, avviare un’azione o registrare un clic. L’unica eccezione è l’URL di disiscrizione con un clic descritto più sotto.

Cos’è List-Unsubscribe?

List-Unsubscribe è un’intestazione definita nella RFC 2369. L’intestazione contiene uno o più modi per lasciare la lista, come un indirizzo mailto:, un URL https: o entrambi. I provider di posta usano l’intestazione per mostrare un proprio pulsante di disiscrizione accanto al nome del mittente. Gli URL in http semplice sono superati, e oggi ci si aspetta https.

Cos’è la disiscrizione con un clic?

La RFC 8058 aggiunge una seconda intestazione, List-Unsubscribe-Post, con il valore fisso List-Unsubscribe=One-Click. Con entrambe le intestazioni presenti, il provider di posta invia una richiesta POST all’URL https e il destinatario lascia la lista senza visitare alcuna pagina. Google e Yahoo richiedono la disiscrizione con un clic ai mittenti di invii massivi.

echo.email invia la stessa richiesta POST e mostra la risposta. Qualsiasi stato 2xx conta come successo. La richiesta disiscrive solo l’indirizzo temporaneo di echo.email.

Cosa significa disiscrizione senza interazione?

Una disiscrizione senza interazione si completa senza che il destinatario apra un browser o confermi qualcosa. Il one-click della RFC 8058 è il metodo preferito. Anche un indirizzo mailto: in List-Unsubscribe conta, ma disiscriversi via email è più lento e non dà conferma al destinatario, quindi i provider trattano mailto come alternativa di riserva.

Perché serve ancora un link di disiscrizione nel messaggio?

Le leggi sul marketing della maggior parte dei paesi richiedono un modo visibile per lasciare la lista dentro il messaggio stesso, di solito un link nel piè di pagina. Le intestazioni servono al provider di posta, e il link nel piè di pagina serve al lettore. echo.email cerca un link con un testo di disiscrizione o un URL che ha l’aspetto di una disiscrizione. Il rilevamento è euristico e a volte sceglie il link sbagliato. Un parametro di tracciamento dedicato sul link nel piè di pagina distingue, nelle statistiche del mittente, le disiscrizioni dal piè di pagina da quelle dall’intestazione.

Cos’è List-Id?

List-Id (RFC 2919) dà un nome alla mailing list a cui appartiene un messaggio, per esempio News <news.example.com>. Google e Yahoo non richiedono questa intestazione. I server di ricezione e i destinatari la usano per ordinare e filtrare la posta per flusso di invio, quindi aggiungerla è una buona pratica.

Cos’è l’elenco delle buone pratiche?

L’elenco segue i requisiti che Google e Yahoo hanno pubblicato nel 2024 per i mittenti di invii massivi: SPF allineato, DKIM allineato, DNS inverso con conferma diretta (FCrDNS), TLS, un dominio From che non sia di posta gratuita e che non fallisca DMARC, una policy DMARC pubblicata, almeno un metodo di autenticazione allineato, la disiscrizione con un clic e un link di disiscrizione visibile. Ogni riga dice sì o no. Una riga rossa è una causa probabile di un peggior posizionamento nella posta in arrivo dei grandi provider, e il punteggio pieno è la base per gli invii massivi.

Alcune righe contano solo quando si applicano. Le due righe sulla disiscrizione contano quando il messaggio ha un’intestazione da invio massivo: List-Unsubscribe, List-Unsubscribe-Post, List-Id o Precedence con il valore bulk, list o junk. In un messaggio personale senza nessuna di queste intestazioni, quelle righe non contano. L’allineamento SPF resta fuori dal punteggio quando il mittente della busta è stato riscritto con SRS e DMARC passa con DKIM allineato. Dopo una riscrittura SRS, SPF controlla il dominio del server che ha riscritto l’indirizzo invece del dominio From. I servizi di inoltro usano SRS come impostazione predefinita, e alcuni server di invio applicano SRS a tutta la posta in uscita, perdendo così l’allineamento SPF. Il punteggio mostra quante delle righe conteggiate sono rispettate.

Come viene visualizzato il messaggio?

La vista visualizzata mostra la parte HTML in un riquadro isolato (sandbox). È il browser a eseguire la visualizzazione, quindi il risultato corrisponde a un browser desktop e non a un programma di posta o a un dispositivo specifico. Script, moduli e link sono disattivati nell’anteprima. Altre viste mostrano il messaggio con le immagini bloccate e con il testo alternativo al posto di ogni immagine, cioè come molti lettori vedono un messaggio la prima volta.

Cosa mostra la sezione MIME?

MIME è la struttura interna di un messaggio: le parti, i tipi di contenuto, i set di caratteri, le codifiche di trasferimento e i delimitatori che separano le parti. Una newsletter tipica ha un contenitore multipart/alternative con una parte text/plain e una parte text/html. Una parte di testo mancante, un delimitatore di chiusura mancante o un annidamento insolito saltano all’occhio nell’albero.

Cosa mostra la sezione Messaggio grezzo?

La sezione Messaggio grezzo mostra il messaggio così come è stato ricevuto, con alcune statistiche: dimensione totale, numero di righe, la riga più lunga, caratteri non ASCII e interruzioni di riga senza CR. La RFC 5322 limita una riga a 998 caratteri, e alcuni server spezzano o rifiutano le righe più lunghe. Le interruzioni di riga senza ritorno a capo (CR) sono una causa comune di errori DKIM, perché i server lungo il percorso li riscrivono.

La vista del messaggio grezzo inizia con le intestazioni di tracciamento che mx.echo.email registra alla consegna: Return-Path, Authentication-Results, Received-SPF e Received. Sotto c’è il messaggio esattamente come è stato ricevuto, e il link di download fornisce il file .eml senza modifiche.

Quali blocklist verifica il report?

I destinatari cercano l’indirizzo IP di invio e i domini del mittente nelle blocklist DNS, e comparire in una lista molto usata porta a posta rifiutata o filtrata. Il report controlla le stesse liste di scan.mx: Spamhaus ZEN e AuthBL per l’indirizzo IP, Spamhaus DBL e ZRD per il dominio From e il dominio della busta, più SpamCop, GBUdb Truncate e PSBL per gli indirizzi IPv4. Ogni riga dice elencato o non elencato, con un link alla pagina di rimozione del gestore della lista.

Un inserimento per policy nella Spamhaus PBL indica un intervallo di indirizzi che non deve inviare posta direttamente, come una connessione domestica. La posta da un indirizzo del genere deve passare dal server di posta del provider. I risultati restano in cache per due ore, quindi una correzione compare in un nuovo test al massimo due ore dopo.

Cosa significa il punteggio SpamAssassin?

SpamAssassin è un filtro antispam open source che molti server di ricezione usano. Il server di posta assegna un punteggio a ogni messaggio di test con SpamAssassin e le regole standard, aggiornate ogni giorno. Il report mostra il totale, la soglia di spam di 5 e ogni regola che è scattata, a partire da quelle con più punti. I punti negativi vanno a favore del messaggio, per esempio una firma DKIM valida.

I test di rete cercano l’indirizzo IP di invio e i domini dei link su Spamhaus (tramite DQS), URIBL, SURBL e le altre liste delle regole standard. L’apprendimento bayesiano e le reti di hash condivisi Razor, Pyzor e DCC sono disattivati, quindi il punteggio dipende solo dal messaggio e il server non invia all’esterno nessun dato del messaggio per l’apprendimento.

Il punteggio è indicativo e non conta nel punteggio delle buone pratiche. Ogni destinatario usa il proprio filtro, con regole e soglie proprie, e Gmail e Outlook non usano SpamAssassin. Un punteggio sopra zero è normale. Le regole con più punti mostrano dove una modifica aiuta di più. I messaggi oltre 500 KB non ricevono un punteggio.

Perché i domini del mittente hanno bisogno di server di posta?

Le risposte vanno al dominio From, e i rimbalzi vanno al dominio del mittente della busta. Entrambi hanno bisogno di un record MX, o almeno di un record di indirizzo, che i server di posta usano come alternativa. Un null MX, cioè un unico MX che punta a un punto (RFC 7505), dichiara che un dominio non accetta posta, e alcuni destinatari rifiutano i messaggi da un dominio del genere.

Quali elementi HTML contano come a rischio?

Script, moduli, iframe, object ed embed raramente hanno senso in un’email. La maggior parte dei programmi di posta li rimuove, e i filtri antispam li considerano un segnale di phishing. Link e immagini semplici fanno lo stesso lavoro senza questa penalità. La sezione sul contenuto mostra anche la dimensione dell’HTML e quanto testo visibile contiene l’HTML, perché un messaggio fatto quasi solo di markup o di immagini sembra sospetto ai filtri.

Perché segnalare gli accorciatori di link?

Gli accorciatori pubblici come bit.ly nascondono la vera destinazione. Le campagne di phishing li usano molto, quindi i filtri trattano con sospetto i link che passano da lì. I link che puntano direttamente al dominio del mittente costruiscono reputazione.

Cosa mostra la sezione DNS?

Ogni query DNS fatta per il report compare nella sezione DNS, raggruppata per scopo: DNS inverso, SPF, DKIM, DMARC, BIMI, server di posta e il controllo IPv6. Le query alle blocklist restano fuori, perché i nomi di quelle query contengono una chiave di accesso. Ogni voce mostra il nome, il tipo di record, il codice di risposta, le risposte con il loro TTL e gli eventuali record di autorità. L’elenco mostra quali record hanno prodotto ogni risultato, e questo aiuta quando una modifica recente al DNS non ha ancora raggiunto tutti i resolver.

Altri strumenti gratuiti

scan.mx
Controlla la configurazione email di un dominio: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Controlla quali porte TCP sono aperte su un indirizzo IP, compresa la porta 25.