Colori verifica email in TOM: cosa significano davvero verde, giallo e rosso

La versione breve

Due cose da notare subito. Primo, la mappa è ordinata: TOM legge le fasce di punteggio dall'alto verso il basso, così ogni indirizzo finisce in esattamente una riga. Secondo, ci sono sette verdetti dietro tre luci — il rosso copre quattro situazioni diverse (unknown, disposable, risky, invalid) che falliscono per motivi completamente diversi. Il resto di questa guida li analizza uno per uno.

Prima del colore: cosa controlla davvero la verifica

La luce è l'ultimo passo di una pipeline in sei fasi. Conoscere le fasi è importante perché ogni colore è in realtà una dichiarazione su dove l'indirizzo ha superato o fallito il controllo:

1. Controllo sintassi. L'indirizzo è ben formato (una @, parte locale e dominio validi)? Un indirizzo malformato non supera mai questa fase — diventa invalid con reason invalid_syntax.
2. Controllo dominio. Il dominio esiste e si risolve nel DNS? Un dominio morto o non registrato diventa invalid (no_mx_records, oppure spf_reject_all quando il dominio rifiuta esplicitamente tutta la posta in ingresso).
3. Controllo record MX. Il dominio pubblica i server di posta che possono ricevere email? Senza record MX non esiste alcuna inbox — di nuovo invalid.
4. Rilevamento usa e getta. Il dominio è nella lista di oltre 5.000 provider di email temporanee noti (Mailinator, 10MinuteMail, Guerrilla Mail e simili, aggiornata ogni giorno)? Una corrispondenza diventa disposable, indipendentemente dal fatto che la casella esista tecnicamente.
5. Controllo SMTP. Il passo decisivo: BillionVerify si connette al server di posta del destinatario e chiede, tramite RCPT TO, se la specifica casella esiste. Un 250 OK la conferma (valid); un 550 user unknown la boccia (invalid, mailbox_not_found). Tutto ciò che è ambiguo — timeout, greylisting, limiti di frequenza, probe bloccati — diventa unknown o catchall.
6. Calcolo del punteggio. Tutti i risultati delle fasi sono combinati in un punteggio di confidenza da 0.0 a 1.0. La conferma SMTP pesa di più (circa il 30%), seguita da record MX, esistenza del dominio, stato usa e getta e segnali di reputazione.

Oltre a questa pipeline ci sono due rilevamenti ortogonali: i pattern di ruolo (è una inbox condivisa?) e lo screening di reputazione contro la Spamhaus Domain Blocklist (questo dominio è una fonte confermata di spam, phishing, malware o botnet?). Producono rispettivamente i verdetti role e risky.

Verde: valid

Il verde è l'unico verdetto che conferma la singola casella, non solo il dominio. La sintassi è valida, il dominio esiste, i record MX sono pubblicati, l'indirizzo non è usa e getta e il server ricevente ha accettato esplicitamente il destinatario. La confidenza è alta — nella scala di BillionVerify questa è la fascia 0.9–1.0, «altamente confidente valid».

Cosa fare: includi nelle campagne cold senza esitare. Gli indirizzi verdi sono la spina dorsale di ogni invio; la soglia di qualità per campagna in TOM esiste proprio per mantenerne alta la quota.

Giallo: catch-all

Il catch-all è una proprietà del dominio, non dell'indirizzo. Piccole aziende e setup self-hosted configurano spesso il proprio server di posta — o un gateway di sicurezza come Mimecast o Proofpoint in modalità accept-all, o un relay interno di Microsoft 365 — per accettare ogni destinatario invece di rifiutare quelli sconosciuti. La conversazione SMTP quindi non prova nulla sul fatto che marco@ funzioni davvero lì.

Tipici codici reason dietro un catch-all includono catch_all_domain (probe casuale accettata), catch_all_deliverable (dominio catch-all dove anche lo specifico indirizzo ha restituito 250 OK), gateway_accept_all e m365_internal_relay. Anche i servizi di alias con forwarding (SimpleLogin, Firefox Relay, Duck.com) e alcuni domini consumer regionali finiscono qui.

Perché giallo e non verde? Perché il rischio di bounce è strutturalmente più alto: stai inviando a un indirizzo che il verificatore non ha potuto confermare individualmente. Perché giallo e non rosso? Perché molti indirizzi catch-all sono persone reali in aziende reali — scartarli tutti significherebbe buttare prospect legittimi, soprattutto nel segmento SMB.

Giallo: role-based

Una sottigliezza dalla documentazione: gli indirizzi di ruolo ereditano il codice reason dal controllo SMTP sottostante — non esistono codici reason dedicati per questo stato. Un indirizzo di ruolo che ha superato SMTP mostra reason: smtp_deliverable, esattamente come un indirizzo verde. Il flag role (is_role: true) è ciò che lo distingue.

Non tutti gli indirizzi di ruolo comportano lo stesso rischio. Come regola pratica dal riferimento di BillionVerify:

Perché giallo? La casella esiste, quindi il rosso sarebbe sbagliato — ma una cold email a info@ compete con ogni altro messaggio in ingresso a quell'azienda, e alcuni provider limitano del tutto gli indirizzi di ruolo. Va bene per le email transazionali; per il cold outreach, usali con intenzione e aspettati tassi di risposta più bassi.

Rosso: unknown

Unknown è il verdetto più frainteso, perché «sconosciuto» suona neutro mentre TOM mostra rosso. Il rosso è intenzionale: un indirizzo la cui validità non può essere confermata comporta lo stesso rischio di invio di uno cattivo finché non si dimostra il contrario. Per questo TOM ti guida a fare cold outreach correttamente e blocca gli indirizzi rossi invece di lasciarti scommettere un bounce su di essi.

Le cause comuni si dividono in due gruppi:

• Temporanee e ritentabili — vale la pena riverificare: smtp_timeout, smtp_rate_limited, smtp_greylisted (inclusa la variante Mimecast), lookup asincroni di Proofpoint, rifiuti temporanei di Google e Microsoft 365, timeout DNS ed errori interni transitori.
• Strutturali e non ritentabili — riprovare non cambierà il risultato: provider che bloccano le probe SMTP per policy (Apple iCloud, posta consumer Microsoft, Proton, Tuta, domini di operatori giapponesi), server che hanno inserito la connessione di prova in blocklist, configurazioni DMARC disallineate, caselle piene o disabilitate e account configurati per saltare la verifica SMTP.

Regola pratica: riverifica una volta dopo un intervallo — greylisting e limiti di frequenza spesso si risolvono, e l'indirizzo può diventare verde o giallo e quindi selezionabile. Finché resta unknown, rimane escluso di default e non può essere aggiunto a una campagna cold.

Rosso: disposable e risky

Disposable (is_disposable: true, reason disposable_domain) copre Mailinator, 10MinuteMail, Guerrilla Mail, TempMail e migliaia di generatori più piccoli. Questi indirizzi raramente interagiscono, sono spesso usati per spam o frodi e segnalano un lifetime value quasi zero — particolarmente dannoso nei flussi di registrazione.

Risky è il verdetto che manca nella maggior parte dei riassunti, quindi merita una spiegazione completa. Significa che la casella molto probabilmente accetta email (is_deliverable: true), ma il dominio destinatario è elencato nella Spamhaus Domain Blocklist per spam, phishing, distribuzione di malware o comando e controllo botnet. L'array risk_reasons ti dice quale: spamhaus_dbl_spam, spamhaus_dbl_phish, spamhaus_dbl_malware o spamhaus_dbl_botnet_cc. Inviare lì può danneggiare la tua reputazione di mittente, quindi l'azione consigliata è identica a disposable: rimuovi dalla lista. Riprovare non cambia mai un risultato risky.

Una rassicurazione dalla documentazione: i domini segnalati da Spamhaus come siti legittimi compromessi — il sito di un'azienda normale che è stato hackerato — non producono mai un risultato risky. Un sito hackerato non significa che le caselle di quell'azienda siano cattive.

Rosso: invalid

Invalid è il verdetto negativo più confidente (punteggio intorno a 0.1). Tipici codici reason: invalid_syntax (indirizzo malformato), no_mx_records (dominio senza server di posta), spf_reject_all (dominio che rifiuta esplicitamente tutta la posta in ingresso), mailbox_not_found (il server ha restituito 550 / utente sconosciuto) e host_not_found (l'host MX stesso è irraggiungibile).

Qui non c'è nessun «forse» e nessuna logica di retry che aiuti: un indirizzo invalid farà bounce ogni volta. Nel cold outreach è puro costo — un bounce, un colpo alla reputazione e un prospect mai esistito.

Punteggio vs stato: cosa decide il colore?

Entrambi — e non sono mai in disaccordo. Ogni stato porta un punteggio fisso, quindi le due letture sono equivalenti:

Pensa al punteggio come alla forma machine-readable dello stato, e al colore come alla forma human-readable del punteggio. TOM valuta le fasce dall'alto verso il basso — vince la prima soglia raggiunta dal punteggio — ed è per questo che un indirizzo può avere una sola luce. Il flag is_deliverable segue la stessa logica: true per valid (e tecnicamente per risky), false per invalid, null per unknown e catch-all dove la recapitabilità è davvero indeterminata.

Cosa fare con ogni colore in TOM

La verifica è utile solo se cambia ciò che invii. In TOM lo fa per design: gli indirizzi rossi sono esclusi di default e non possono essere selezionati per una campagna cold — guidarti a fare cold outreach correttamente significa non lasciarti inviare a indirizzi che farebbero sicuramente bounce. Verdi e gialli sono selezionabili; la soglia di qualità per campagna decide poi quanto giallo può contenere un invio.

In TOM questo si gioca in tre punti: la luce per indirizzo ti dice quanto vale ogni contatto, la soglia minima di qualità per campagna mantiene alta la quota verde tra gli indirizzi selezionabili, e il pre-flight check prima del lancio ferma una campagna la cui qualità di lista brucerebbe il dominio. Gli indirizzi rossi non arrivano mai a quel punto — sono filtrati prima della selezione. I crediti di verifica non scadono mai, quindi riverificare un indirizzo unknown la prossima settimana — o pulire una lista ferma da 90 giorni — non costa nulla in più, e un indirizzo che diventa verde o giallo diventa selezionabile.

Quando il risultato ti sorprende: i codici reason

Ogni verdetto arriva con un campo reason — un identificatore stringa stabile che spiega perché l'indirizzo ha ricevuto il suo stato. Quando una luce sembra sbagliata, la reason è dove guardare. I più utili da riconoscere:

• Sembra rosso ma ti aspettavi verde: mailbox_not_found (refuso nell'indirizzo o dipendente uscito), no_mx_records (dominio senza posta), smtp_blocked o smtp_unverifiable (il provider rifiuta le probe — comune con iCloud, posta consumer Microsoft, Proton e Tuta).
• Sembra giallo ma ti aspettavi verde: catch_all_domain o gateway_accept_all (il dominio accetta tutto), oppure uno smtp_deliverable ereditato con is_role: true (una inbox funzionante ma condivisa).
• Bloccato su unknown: controlla se la reason è ritentabile (smtp_timeout, smtp_rate_limited, smtp_greylisted, google_rate_limit, dns_timeout) o strutturale (smtp_unverifiable, carrier_blocked, mailbox_full). Solo il primo gruppo migliora al retry.
• Punteggio 0.3 senza causa evidente: controlla risk_reasons. Una voce spamhaus_dbl_* significa che il dominio è blocklisted — l'indirizzo non è «di bassa qualità», è attivamente pericoloso per la tua reputazione.

Due flag compagni aiutano con la segmentazione oltre la recapitabilità: is_free (Gmail, Yahoo, Outlook — utile per lo scoring B2B vs B2C e il rilevamento frodi) e smtp_check (se la probe SMTP profonda è davvero partita, o se il verdetto si basa su euristiche a livello di dominio).

FAQ

Questa guida fa parte del blog di TOM. Stati e punteggi di verifica seguono la documentazione verification-types di BillionVerify e il riferimento verification-reasons. Da leggere anche: i 12 framework di cold email, 12 alternative software cold email a confronto e il warmup come comportamento di piattaforma.