Email catch-all: come funzionano e come rilevarle

CaptainVerify ha verificato oltre 126 milioni di indirizzi email nel 2025. Circa il 2,5% del volume ricade su un dominio catch-all. Rapportata ai soli indirizzi ospitati su un dominio aziendale, escluse le webmail per il grande pubblico che pesano quasi tre quarti del totale verificato, la proporzione si avvicina all’11%, ovvero quasi un indirizzo professionale su 9. Questa misura riguarda indirizzi. I tassi molto più alti che si incontrano altrove contano domini, che è un’altra unità: un solo dominio in catch-all può portare una manciata di indirizzi nel suo database come portarne centinaia. Su un file B2B di 50.000 contatti, questo fa nell’ordine di 5.500 righe la cui validità resta indecidibile prima dell’invio.

Il dominio che ospita questi indirizzi si individua in pochi secondi con un comando SMTP. I 2 livelli si trattano separatamente: il rilevamento del dominio dipende da un test tecnico riproducibile, la decisione di inviare dipende dalle sue soglie di rimbalzo.

Che cos’è un indirizzo catch-all?

Un catch-all è una regola di instradamento posta a livello di dominio: il server di ricezione accetta i messaggi indirizzati a qualsiasi casella del dominio, dichiarata o meno.

La regola vive nella configurazione del dominio ricevente, dietro il suo record MX. Nessuna casella porta l’etichetta in proprio. L’espressione « indirizzo catch-all » circola per scorciatoia e designa qualsiasi indirizzo il cui dominio applica questa modalità di ripiego.

Un esempio rende la meccanica evidente. Il dominio esempio.com dichiara david@esempio.com e attiva un catch-all. Un corrispondente digita daivd@esempio.com, 2 lettere invertite. Su un dominio standard, il server rifiuta questo indirizzo al momento del RCPT TO e restituisce un errore permanente al mittente, uno dei codici di risposta SMTP che bisogna saper leggere. Su esempio.com, il messaggio entra e atterra nella casella di ripiego. L’errore di battitura passa inosservato.

Catch-all, alias, inoltro e sub-addressing: da non confondere

Un alias dichiara un indirizzo supplementare che punta verso una casella esistente. Un inoltro prende un indirizzo dichiarato e fa proseguire la sua posta verso un’altra destinazione. Il sub-addressing aggiunge un suffisso dopo un segno più, del tipo david+stampa@esempio.com, che il server riporta alla casella di base. Questi 3 meccanismi riguardano indirizzi noti al server, che rifiuta tutto ciò che esce dalla sua lista. Il catch-all agisce dopo questa lista, sulle parti locali che nessuna regola dichiara.

A cosa serve l’indirizzo catch-all?

Un catch-all recupera la posta inviata a un indirizzo scritto male e priva un attaccante della risposta che gli direbbe quali indirizzi esistono sul dominio.

Il primo uso è banale. Gli errori di battitura abbondano sui nomi composti e le caselle dei collaboratori usciti dall’azienda restano indirizzate per mesi. Il catch-all recupera questa posta.

Il secondo uso è difensivo. Un server che risponde 550 sugli indirizzi sconosciuti fornisce un oracolo gratuito: l’attaccante sottopone una lista di nomi e conserva quelli che il server accetta. Il dominio in catch-all risponde 250 a tutti e non seleziona più nulla per lui.

Il rovescio arriva nella casella di ripiego. Un dominio che accetta tutto attira le campagne di dizionario, quegli invii massivi che provano contatto@, admin@, assistenza@, hr@ e qualche centinaio di nomi finché qualcosa non resta. La cernita ricade allora sul team che scarica la casella, con il lavoro di pulizia della lista di contatti che questo presuppone lato mittente.

Come rilevare un dominio catch-all

Un dominio catch-all si rileva sottoponendo al server un indirizzo estratto a caso: se il server accetta un indirizzo improbabile, accetta anche tutto il resto.

Il test SMTP passo dopo passo: MX, EHLO, MAIL FROM, RCPT TO

1. Risolvere i record MX del dominio e trattenere quello con il valore di preferenza più basso, l’MX primario. In assenza di MX, la posta ricade sul record A del dominio.
2. Aprire una connessione sulla porta 25 verso questo server e salutare con EHLO seguito da un nome host che si risolve in DNS.
3. Annunciare MAIL FROM con una busta vuota o un indirizzo di test realmente raggiungibile.
4. Inviare RCPT TO sull’indirizzo da verificare, poi annotare il codice di ritorno e il testo che lo accompagna.
5. Inviare RCPT TO su un indirizzo casuale dello stesso dominio, del tipo k7v29xq4m@esempio.com.
6. Chiudere la sessione con QUIT, senza mai passare al comando DATA.

Il segnale si legge sull’indirizzo casuale, la prima accettazione serve solo a verificare che la sessione si comporti normalmente. Preveda un RSET tra i 2 comandi RCPT TO, perché un server interrompe spesso la sessione dopo un destinatario errato. Chiudere prima di DATA evita di consegnare un messaggio e non lascia nei registri remoti che la traccia di un’apertura di sessione. L’IP che sonda deve disporre di un record PTR valido, altrimenti un rifiuto di policy si legge per errore come un indirizzo non valido.

250 OK contro 550: leggere la risposta del server

La RFC 5321 dell’ottobre 2008 fissa la regola nella sua sezione 3.3: il server risponde 550 al RCPT TO quando il destinatario non è recapitabile, con un messaggio del tipo « no such user ». La RFC 3463 del gennaio 2003 precisa il codice esteso associato nella sua sezione 3.2: 5.1.1 segnala un indirizzo di destinazione non valido e un fallimento definitivo. Un 250 restituito sull’indirizzo casuale stabilisce che il dominio accetta tutto al RCPT TO. La riserva conta: alcuni gateway antispam posti in frontale accettano anch’essi qualsiasi destinatario a questo stadio senza applicare un catch-all. Il rifiuto differito descritto più avanti produce la stessa risposta. Questi codici riguardano la busta, mentre la forma dell’indirizzo dipende dalla sintassi definita dalle RFC.

Cosa falsa il test: MX condiviso, greylisting, tarpitting e rifiuto differito

L’MX condiviso arriva in testa ai falsi segnali. Centinaia di migliaia di domini puntano verso gli stessi server di posta presso i grandi hoster. La policy dei destinatari si regola dominio per dominio dietro questo MX comune, quindi il nome del server non dice nulla sulla modalità di ripiego.

Il greylisting produce un altro rumore. Il server risponde con un errore temporaneo in 4xx al primo contatto e attende un nuovo tentativo per pronunciarsi. CaptainVerify aspetta fino a 30 minuti e rilancia la verifica prima di concludere. Gli indirizzi che restano muti dopo questo rilancio passano in stato sconosciuto e vengono riaccreditati. Il tarpitting rientra nella stessa famiglia: il server rallenta deliberatamente le sue risposte per scoraggiare le sonde.

Il rifiuto differito complica ancora la lettura. Il server accetta il destinatario al RCPT TO, poi genera un rimbalzo una volta ingoiato il messaggio. Il test vede un 250 netto mentre l’invio reale produrrà un errore permanente qualche minuto più tardi.

Che cosa significa lo stato accept_all in un rapporto di verifica

Lo stato accept_all, chiamato ok4all nei rapporti CaptainVerify, indica che il dominio accetta tutti gli indirizzi e che la verifica si ferma quindi al livello del dominio.

La documentazione CaptainVerify colloca ok4all nella famiglia degli indirizzi rischiosi e annuncia l’effetto senza giri di parole: il tasso di rimbalzo sale e il tasso di apertura scende. Il rapporto dice quindi 2 cose in una riga. Il dominio è qualificato, la persona dietro l’indirizzo resta da confermare con l’invio.

Si può verificare un indirizzo su un dominio catch-all?

Il protocollo non decide, dato che il server restituisce la stessa risposta a tutti gli indirizzi del dominio. Quello che resta possibile è stimare una probabilità e ordinare il segmento di conseguenza.

Guardi prima che cosa si nasconde dietro il record MX del dominio. Quando punta verso un gateway di sicurezza, del tipo Proofpoint, Mimecast, Barracuda o Microsoft Defender per Office 365, è il gateway a rispondere per conto del dominio, prima ancora di interrogare la casella reale. Lo stato accept_all traduce allora un’architettura di filtraggio più che una regola di ripiego decisa dall’azienda. Il caso è frequente sui grandi account.

Viene poi la forma dell’indirizzo. Su un dominio le cui caselle seguono una convenzione visibile, nome.cognome per esempio, un indirizzo che rispetta questa convenzione porta una probabilità di validità molto più alta di una stringa arbitraria. Confronti le sue righe tra loro: quelle che escono dallo stampo partono in segmento di test, le altre passano in priorità.

Un verificatore aggiunge infine i propri segnali: l’anzianità del dominio, la reputazione del fornitore di posta, la dimensione dell’organizzazione e lo storico osservato su invii precedenti. Il risultato dà un indice di fiducia che serve a ordinare un segmento prima dell’invio.

Creare o disattivare un catch-all a seconda dell’hoster

La commutazione si regola nella console di amministrazione del dominio: modalità del dominio accettato su Microsoft 365, regola di instradamento su Google Workspace, indirizzo predefinito su cPanel.

Google Workspace

Google Workspace non propone alcuna funzione catch-all nativa. Google pubblica invece una pagina di aiuto dedicata alla casella di raccolta e chiama il tipo di account interessato Unrecognized o Catch-all. La configurazione passa da una regola di instradamento, sotto Apps poi Gmail poi Routing, con l’azione Change envelope recipient applicata agli account inattivi e non riconosciuti. La posta indirizzata a una casella sconosciuta parte allora verso un indirizzo di raccolta designato. Per tornare indietro, elimini questa regola di instradamento: il dominio ricomincia subito a rifiutare i destinatari che non conosce.

Microsoft 365

Il comportamento dipende dalla modalità del dominio accettato, sotto Mail flow poi Accepted domains. In modalità Authoritative, il dominio rifiuta i destinatari sconosciuti e attiva il Directory-Based Edge Blocking, che taglia il messaggio alla frontiera del servizio. La modalità Internal relay fa proseguire la posta dei destinatari sconosciuti verso un altro server e produce di fatto un comportamento di ripiego.

cPanel

La funzione si chiama Default Address. Propone di restituire un errore al mittente durante la sessione SMTP, comportamento predefinito ed esatto contrario del catch-all. Può anche instradare la posta degli indirizzi sconosciuti verso una casella esistente, oppure eliminarla in silenzio. La documentazione cPanel etichetta essa stessa l’opzione che elimina il messaggio in silenzio come Not Recommended, per una ragione di fondo: il mittente non viene mai a sapere che il suo messaggio è sparito.

Con che cosa sostituire un catch-all

L’uscita passa da indirizzi dichiarati più che da una regola di ripiego. Crei alias sugli errori di battitura più frequenti dei suoi nomi di dominio e tenga una casella generica di contatto realmente consultata. Il sub-addressing prende il cambio per tracciare i suoi moduli senza moltiplicare le caselle. Il dominio ritrova una lista di destinatari pulita. I suoi corrispondenti recuperano un errore immediato quando si sbagliano.

Catch-all con o senza bounce

2 configurazioni distinte si nascondono dietro questa domanda. Il catch-all accetta il destinatario sconosciuto al RCPT TO e consegna il messaggio in una casella di ripiego, senza rimbalzo di alcun tipo. Il rifiuto differito accetta anch’esso al RCPT TO, poi fabbrica un rapporto di mancata consegna dopo aver ingoiato il messaggio.

Questa seconda modalità ha un costo per tutti. Quando la busta di origine è falsificata, cosa che è la norma nello spam, il rapporto di mancata consegna parte verso un terzo innocente il cui indirizzo è servito da esca. Il fenomeno porta un nome, il backscatter. Alimenta le liste di blocco. Comprenderlo aiuta anche a ordinare i suoi ritorni, tra hard bounce e soft bounce.

Deve includere gli indirizzi catch-all nelle sue campagne?

Inviare su indirizzi catch-all fa salire il tasso di rimbalzo e scendere il tasso di apertura, 2 curve che le piattaforme di invio sorvegliano per decidere il seguito. È da lì che la reputazione del mittente si degrada, messaggio dopo messaggio.

Il rischio reale: soglia di rimbalzo, tasso di reclamo, reputazione del mittente e spam trap

Le soglie di rimbalzo vengono dalle piattaforme di invio. Amazon SES mette il suo contatore sotto revisione oltre il 5% di rimbalzo e può sospendere gli invii al 10%. La documentazione Microsoft per Dynamics 365 Customer Insights, aggiornata nell’agosto 2026, distingue 2 livelli: un tasso di rimbalzo accettabile non supera il 2% nella maggior parte dei casi. Il prodotto stesso tollera fino all’8% prima di reagire. Il 2% rientra quindi nella buona pratica, l’8% nella soglia realmente applicata. Riprendiamo il file di 50.000 contatti e le sue circa 5.500 righe in catch-all. Se la metà rimbalza, il contatore supera il 5% prima ancora di aver contato il resto del database, sopra la barra che innesca la revisione dell’account. Le soglie di rimbalzo applicate dalle piattaforme di invio variano poi da un attore all’altro.

Le soglie di reclamo vengono dai provider di posta e si contano a parte. Le regole Google per i mittenti, applicabili dal 1° febbraio 2024, chiedono un tasso di reclamo sotto lo 0,10% e fissano un limite da non raggiungere mai allo 0,30%, per ogni mittente di più di 5.000 messaggi al giorno verso Gmail. Il Sender Hub di Yahoo chiede di restare sotto lo 0,3%. Questi 2 attori pubblicano soglie di reclamo e nessuna soglia di rimbalzo.

Resta il tema delle spam trap. Spamhaus ha documentato il ciclo nel febbraio 2022: un indirizzo abbandonato rimbalza in errore permanente spesso per 12 mesi o più, poi il dominio lo riaccende come trappola. Un database lasciato senza pulizia da 2 anni contiene quindi, statisticamente, indirizzi che hanno cambiato natura nel frattempo.

Ridurre l’incertezza prima dell’invio

La verifica preliminare della lista fa la prima cernita. Toglie gli indirizzi non validi e isola gli ok4all in un segmento dedicato. Resta una base su cui il rimbalzo torna prevedibile. Osservi poi l’origine della raccolta: una lista costruita in opt-in semplice o in double opt-in produce nettamente meno rimbalzi di un file acquistato. Consideri infine l’anzianità, dato che il ciclo descritto da Spamhaus corre su tutti gli indirizzi dormienti. Questa panoramica degli strumenti di verifica email dettaglia gli approcci disponibili.

Convalidare con l’engagement dopo il primo invio

Il segmento ok4all si tratta come un test. Invii prima sul 5-10% del segmento. Misuri il rimbalzo e l’apertura, poi confronti questi 2 valori con quelli del resto della campagna. Uno scarto debole autorizza ad alzare la percentuale al prossimo invio. Uno scarto netto indica un segmento da lasciare da parte o da rilavorare.

Dopo 2 invii senza aperture né clic, un indirizzo in catch-all ha dato prova della sua inutilità ed esce dalla lista. Prima della sua prossima campagna, isoli le righe ok4all di un campione del suo database e confronti il loro tasso di rimbalzo con quello del resto: il verdetto cade in un’ora e vale tutte le stime.

Domande frequenti

Un dominio catch-all è rilevabile?

Sì, in pochi secondi. Un comando RCPT TO su un indirizzo casuale del dominio basta: una risposta 250 su un indirizzo improbabile rivela la modalità di ripiego. La validità di ogni singolo indirizzo, invece, resta indecidibile con questo test.

Quale parte di un database B2B è interessata?

Su oltre 126 milioni di indirizzi verificati da CaptainVerify nel 2025, circa il 2,5% è risultato in catch-all. Il perimetro dei soli domini aziendali porta questa proporzione a quasi l’11%. Un database B2B di 100.000 contatti contiene quindi nell’ordine di 11.000 righe di questo tipo, da isolare prima dell’invio.

Il catch-all protegge dallo spam?

Aumenta lo spam ricevuto, dato che ogni indirizzo inventato sul dominio trova una casella. Il suo beneficio si situa altrove: il server non risponde più 550 sugli indirizzi sconosciuti e priva l’attaccante dell’oracolo che gli permetterebbe di enumerare gli indirizzi validi.

Bisogna eliminare gli indirizzi catch-all dalla propria lista?

L’eliminazione pura si giustifica quando la sua piattaforma di invio applica una soglia di rimbalzo bassa, sull’esempio del 5% che innesca una revisione dell’account presso Amazon SES. Su un IP dedicato che lei pilota, un segmento separato e un invio a lotti restano un’opzione ragionevole.

Che fare di uno stato sconosciuto in un rapporto?

Segnala un server rimasto muto malgrado il rilancio automatico effettuato entro i 30 minuti. CaptainVerify riaccredita queste verifiche. Un nuovo passaggio più tardi decide nella grande maggioranza dei casi.