Email catch-all: funzionamento, rischi e alternative

L'email catch-all è una regola che instrada i messaggi per destinatari sconosciuti del dominio verso una destinazione precisa. Per ghost@yourdomain.com, un server può rifiutare il destinatario con 550 senza necessariamente chiudere la connessione. Il catch-all può rispondere 250 OK al destinatario: non è ancora l'accettazione definitiva del contenuto dopo DATA.

Nel 2026 recuperare un errore di battitura resta utile, ma volume, reputazione e dati personali richiedono controlli. Gli effetti dipendono dall'uso e dalla configurazione.

Questa guida spiega SMTP, cinque aree di rischio, autenticazione dell'inoltro e scelte di configurazione.

Che cos'è il catch-all?

L'email catch-all, detta anche accept-all o regola jolly, assegna i destinatari sconosciuti di un dominio valido a un percorso predefinito. Anziché un errore 550 per indirizzo inesistente, il server può ammettere il destinatario e consegnare il messaggio se supera gli altri controlli.

Le interfacce usano accept-all e catch-all per questo comportamento: i destinatari senza corrispondenza in RCPT TO hanno una destinazione predefinita. In TrekMail, verifica Domini → Instradamento, indicato come Connessione nelle interfacce precedenti, → Casella catch-all e scegli un destinatario consentito. Verifica applicazione del cambiamento e percorso reale senza presumere effetti istantanei.

Dalla fine degli anni 1990 al 2026, il traffico automatizzato ha modificato le esigenze di controllo. Il catch-all può nascondere quali indirizzi esistano durante una sonda, ma destinatari inventati possono anche aumentare elaborazione e archiviazione.

Perché attivare il catch-all e cosa valutare

Due motivi comuni sono recuperare contatti mal indirizzati ed evitare licenze aggiuntive. Confrontali con alias espliciti, esigenze reali di caselle e carico di ricezione.

Recuperare gli errori di battitura

Un'azienda può temere di perdere un contatto per suport@ anziché support@. Il catch-all può recuperarlo e ricevere anche traffico inventato. Definisci responsabile e revisione che consentano di trovare la posta utile tra messaggi indesiderati.

Per errori noti, crea alias precisi. Con support@, aggiungi per esempio suport@ alla stessa destinazione. Limita destinatari arbitrari senza sostituire filtri e controlli.

Il costo delle licenze

Un riferimento storico Google Workspace e Microsoft 365 indica licenze a $6-30 per utente al mese. support@, billing@, jobs@ e marketing@ con quattro licenze indipendenti potrebbero costare fino a $120/mese nell'esempio. Alias, caselle condivise e licenze esistenti possono avere altre condizioni: il catch-all non è obbligatorio.

Confronta costo completo, autorizzazioni e controlli. Lo spazio comune può cambiare il calcolo senza eliminare da solo i rischi. Consulta i piani TrekMail e le condizioni attuali.

Come funziona in SMTP

Con RCPT TO, il mittente indica il destinatario prima di trasmettere il contenuto. Il server può ammetterlo o rifiutarlo e poi applicare altri controlli. La sicurezza dipende anche da autenticazione, filtri, percorsi e accettazione definitiva.

Rifiuto del destinatario sconosciuto

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)

Non esiste un destinatario valido ghost e il server risponde 550. L'esempio semplifica lo scambio: la connessione non deve necessariamente chiudersi e comandi SMTP sono già stati trasmessi. Non si accetta contenuto per quel destinatario, ma la transazione può comprendere altri destinatari validi.

Il percorso catch-all

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com

Il percorso ammette il destinatario sconosciuto. L'accettazione definitiva del contenuto segue e può dipendere dai filtri durante DATA. Dopo l'accettazione, il server deve gestire consegna, archiviazione ed errori senza notificare identità falsificate.

Su larga scala, rifiutare destinatari sconosciuti può risparmiare analisi e archiviazione. Il catch-all può aumentare il carico, ma non impone di accettare tutto il contenuto prima di filtrarlo. Verifica limiti e fasi del filtraggio con il provider.

I 5 rischi operativi

Ammettere destinatari inventati estende la ricezione e può aumentare il traffico indesiderato. È un cambiamento del server, non una promessa legata alla propagazione DNS. Valuta le aree seguenti prima dell'attivazione.

Rischio 1: sonde della directory e volume

Gli attacchi di raccolta degli indirizzi provano milioni di nomi: admin, david, invoice, hr, webmaster, noreply. Cercano di distinguere destinatari ammessi e rifiutati.

Una risposta 550 può rivelare un indirizzo inesistente senza costringere l'attaccante a fermarsi. Il catch-all rende più difficile distinguere indirizzi creati e inventati. Passare da 50 messaggi giornalieri a 50,000 è comunque uno scenario di carico che può consumare quote e filtri e nascondere posta legittima.

Rischio 2: backscatter e reputazione di invio

Il backscatter nasce da notifiche successive a un'identità di busta falsificata. Un esempio:

1. Un attaccante invia a random-gibberish@yourdomain.com in un dominio con catch-all.
2. Falsifica MAIL FROM, riflesso alla consegna in Return-Path, come una vittima: victim@gmail.com. Un'intestazione fornita dall'attaccante non determina in modo affidabile l'identità di busta.
3. Il server accetta definitivamente il messaggio dopo aver ammesso il destinatario.
4. Un filtro successivo rileva posta indesiderata e segnala un errore interno.
5. Se il server genera un NDR al mittente di busta, riflesso in Return-Path, lo invia a victim@gmail.com.
6. La vittima riceve un avviso non richiesto per un messaggio che non ha inviato.

Questo traffico può danneggiare la reputazione e contribuire a liste come ips.backscatterer.org. Rifiuta durante SMTP quando opportuno o usa quarantena sicura senza risposte a identità falsificate. Consulta come indagare sulla reputazione del dominio.

Rischio 3: responsabilità dei percorsi

Un messaggio per partnerships@company.com può finire nella casella comune. Senza responsabile può restare giorni senza controllo. Definisci proprietario, accessi e revisione secondo l'urgenza del traffico.

Gli alias espliciti permettono di scegliere chi riceve ogni indirizzo. Verifica la destinazione di partnerships@ e documenta la responsabilità: un alias non garantisce da solo una risposta.

Rischio 4: assistenza dei fornitori di servizi gestiti

Per agenzie con 50+ domini, prepara risposte a incidenti come:

• “La casella è piena e lenta”: esamina quota, spazio e volume.
• “Ricevo troppo spam”: esamina filtri e destinatari ammessi.
• “Non trovo il messaggio del cliente”: potrebbe trovarsi, per esempio, a pagina 400 della casella comune.
• “I miei invii finiscono nello spam”: indaga su autenticazione, reputazione e notifiche improprie.

Confrontando catch-all e alias, ridurre gli incidenti del 30-40% può essere un obiettivo indicativo di pianificazione, non un risultato misurato o promesso. Registra volume reale e tempo di revisione prima e dopo il cambiamento.

Rischio 5: minimizzazione e protezione dei dati

L'articolo 5(1)(c) del GDPR richiede minimizzazione per la finalità applicabile. Il catch-all può raccogliere informazioni superflue, ma la valutazione dipende da scopo, base giuridica, accessi e conservazione. Definisci quali dati arrivino e come siano trattati.

Trovare dati tra 500,000 messaggi può complicare richieste di cancellazione. Se doctor@yourclinic.com instrada dati sanitari a una casella comune, esamina ruoli, autorizzazioni, flussi e salvaguardie HIPAA quando applicabili. L'accesso di tecnici non determina da solo una violazione: occorre valutare il trattamento effettivo.

SPF, DKIM e DMARC con catch-all

Il catch-all non compromette direttamente questi protocolli. I risultati dipendono da mittenti, identità, firme e modifiche durante l'inoltro. Separare autenticazione, reputazione e percorsi aiuta nella diagnosi.

Nell'inoltro verifica IP intermediario e identità effettive. I rapporti DMARC riguardano il dominio From originale, non sempre quello dell'intermediario. Google Postmaster Tools fornisce dati aggregati ammissibili per Gmail personale, non un registro completo del catch-all o di ogni errore di autenticazione.

Il problema dell'inoltro

Inoltrare tutto a Gmail personale può sembrare comodo, ma richiede controllo di mittenti, filtri, autenticazione e accessi. Un destinatario sconosciuto non deve creare inoltro indiscriminato.

Perché l'autenticazione può fallire

Il destinatario vede una connessione dal tuo IP intermediario, mentre From: può conservare bank@chase.com. SPF valuta l'identità SMTP, non questa intestazione da sola. Esamina busta e firme:

1. SPF: con MAIL FROM del dominio originale, l'IP intermediario deve essere autorizzato da quel dominio.
2. DKIM: piè di pagina, oggetto o allegato modificato può invalidare la firma se tocca parti firmate; esistono altre cause.
3. DMARC: basta SPF o DKIM riuscito e allineato. Se nessuno soddisfa il criterio, il destinatario applica le politiche pertinenti.

Il risultato può essere rifiuto, ritardo, quarantena, spam o altro trattamento, non sempre cancellazione silenziosa. Per p=reject, verifica risultato reale, registri e notifiche. La guida alla diagnosi e configurazione dell'inoltro dettaglia le verifiche.

SRS e ARC quando occorre inoltrare

Per migrazioni o vecchi flussi, esamina due meccanismi: SRS riscrive la busta e ARC trasmette risultati precedenti firmati. L'esigenza dipende dal percorso: DKIM originale valido e allineato può soddisfare DMARC senza entrambi.

SRS (Sender Rewriting Scheme)

SRS riscrive il mittente di busta per valutare SPF sul dominio usato dall'intermediario, eventualmente il tuo dominio. Il suo SPF deve autorizzare l'IP reale dell'inoltro.

Prima di SRS
Envelope From: alice@example.com

Dopo SRS
Envelope From: SRS0=HASH=TT=example.com=alice@your-forwarder.com

Il destinatario valuta SPF per your-forwarder.com. Verifica autorizzazione dell'IP e risultato effettivo della valutazione.

SRS da solo non risolve l'allineamento DMARC. From: mantiene alice@example.com mentre la busta usa your-forwarder.com, senza allineamento tra questi domini. DKIM originale valido e allineato può soddisfare DMARC; modificare parti firmate può impedirlo. Consulta l'inoltro con SRS.

ARC (Authenticated Received Chain)

ARC consente agli intermediari di trasmettere risultati precedenti di autenticazione in intestazioni firmate. Una dichiarazione non stabilisce automaticamente fiducia: catena e identità del firmatario vanno verificate.

Il destinatario può considerare una catena ARC valida di un intermediario attendibile. RFC 8617 definisce il meccanismo; la consegna dipende ancora dalle politiche del destinatario.

Validità crittografica, fiducia nel firmatario e reputazione d'invio sono collegate ma distinte. Ricevere migliaia di messaggi non dimostra da solo che un intermediario non sia attendibile. Evita backscatter e inoltro abusivo e verifica decisioni reali senza promettere consegna grazie ad ARC.

Configurare il catch-all con controlli

Per recuperare errori, migrare o mantenere compatibilità, definisci ambito, responsabili e filtri. Queste tre strategie danno criteri, non isolamento o sicurezza automatici.

Strategia A: destinazione di revisione separata

Usa ricezione controllata con permessi e revisione adeguati. Una casella di quarantena non è da sola una sandbox di sicurezza.

1. Crea catchall-quarantine@yourdomain.com con accesso limitato e senza Send As, inoltri o risposte automatiche.
2. Instrada solo i destinatari sconosciuti del dominio autorizzato verso quella casella.
3. In Microsoft 365, assegnare SCL 9 richiede di classificare il messaggio come spam altamente probabile; la politica determina spam, quarantena e notifiche. Non applicarlo ciecamente a tutto il catch-all: verifica l'effetto con l'amministratore.
4. La revisione settimanale può essere una base; adattala a traffico e urgenza senza ignorare posta legittima in attesa.

In TrekMail, verifica destinazione dedicata e viste disponibili. Una vista filtrata non isola spazio o permessi: esamina accessi, filtri, quota e ricerca dei messaggi mal indirizzati.

Strategia B: Microsoft 365, DBEB e Internal Relay

Per domini autoritativi, DBEB (Directory-Based Edge Blocking) può rifiutare destinatari sconosciuti secondo la directory. Verifica configurazione e presenza di tutti gli indirizzi validi.

Internal Relay Mode disattiva DBEB senza creare catch-all da solo. Directory, connettori, percorsi e prevenzione dei cicli devono corrispondere alla topologia. Non cambiare il tipo del dominio soltanto per ammettere sconosciuti: un amministratore autorizzato deve verificare schema e carico.

Strategia C: pattern limitati in Postfix

I pattern parziali richiedono una mappa compatibile, come PCRE o regexp, verificata e correttamente ancorata. In una normale mappa hash, l'esempio seguente è letterale, non un pattern jolly funzionante:

# /etc/postfix/virtual
sales-*@yourdomain.com    sales-bucket@yourdomain.com

Un pattern reale verificato potrebbe coprire sales-q1@, sales-webinar@ e sales-2026@ senza ammettere admin@ o hr@. La mappa hash mostrata non lo fa automaticamente. Verifica ancoraggio, dominio, espansione degli alias e cicli prima di un'altra implementazione.

Alias e percorsi espliciti come alternativa

Gli alias espliciti definiscono indirizzi e responsabili e limitano destinatari arbitrari. Possono coprire molte esigenze senza catch-all, ma non eliminano spam, errori d'autenticazione o obblighi di protezione dei dati.

Alias, caselle e catch-all: criteri di scelta

Includi filtraggio, archiviazione, assistenza e monitoraggio della reputazione nel confronto. L'impatto dipende da traffico e servizio. Per scegliere alias o casella, consulta definizione, configurazione e utilizzi degli alias email.

Quali indirizzi creare?

Elenca gli indirizzi realmente utilizzati. Questi cinque esempi non sono un massimo sufficiente per ogni azienda:

• hello@ o info@: richieste generali al responsabile designato.
• support@: assistenza a helpdesk o casella condivisa.
• billing@: fatture e pagamenti all'amministrazione.
• jobs@ o careers@: selezione al personale o a un'integrazione ATS autorizzata.
• noreply@: invio transazionale; definisci la gestione delle risposte legittime senza cancellarle indiscriminatamente.

Cinque alias possono coprire l'esempio, ma altre aziende ne richiedono di più. Per helo@ anziché hello@, un rifiuto 550 può consentire al mittente di correggere, senza assicurare che lo faccia. Evita di lasciare posta utile tre settimane senza revisione in una casella comune.

Il modello TrekMail per catch-all

Verifica quali piani TrekMail permettano catch-all e le destinazioni, i limiti e i prezzi attuali. La fatturazione può facilitare indirizzi espliciti senza rendere catch-all necessario o eliminare i rischi.

Esempio di licenze per utente

Con un riferimento storico di $6-30/mese per casella, support@, billing@ e jobs@ con tre nuove licenze potrebbero aggiungere fino a $90/mese. Verifica prezzi e alternative di alias o risorse condivise prima di cambiare percorsi per risparmiare.

Confrontare il piano TrekMail

Esamina spazio comune per account, domini, caselle e limiti. Come riferimenti storici, Starter a $3.50/mese menziona 50 domini e Pro a $10/mese ne menziona 100. Verifica condizioni attuali e costi degli indirizzi aggiuntivi, senza presumere capacità illimitata o gratuità universale.

Per migrazione o compatibilità, configura una destinazione separata con accessi e filtri adeguati. Caselle distinte non assicurano isolamento della quota o delle risorse comuni. Leggi la documentazione della casella catch-all TrekMail e verifica la configurazione attuale.

Esamina due possibilità secondo il piano attuale: inoltro della casella a più destinazioni con copia locale facoltativa e destinazione catch-all esterna quando consentita. Pro e Agency sono citati per la seconda opzione, ma autorizzazioni, percorsi e condizioni vanno verificati. Un dominio parcheggiato richiede comunque ricezione e autenticazione controllate. Consulta l'instradamento di un dominio senza casella locale.

Per confrontare le opzioni, consulta un'eventuale prova gratuita di 14 giorni e i requisiti attuali, compresa la carta quando necessaria. Nel modello Nano con SMTP proprio, configura quel servizio per tutti gli invii e le risposte.

Domande frequenti

Queste domande aiutano a valutare o rimuovere il catch-all e a preparare le verifiche necessarie.

Che cos'è l'email catch-all?

È una regola del server che assegna destinatari sconosciuti del dominio a una destinazione predefinita. Anziché rifiutare con 550, può ammettere il destinatario e poi applicare filtri e accettazione definitiva del messaggio. Accept-all e instradamento jolly sono nomi di interfaccia: verifica il comportamento concreto.

È sicuro usare il catch-all?

Dipende da scopo, filtri, accessi, volume, conservazione e destinazione. Può aumentare carico o notifiche improprie senza provocare da solo errori di autenticazione o violazioni. Usa una destinazione controllata e revisione adeguata all'urgenza, senza applicare indiscriminatamente punteggi massimi o ignorare posta legittima.

Può incidere sulla consegna della posta in uscita?

Indirettamente, se notifiche raggiungono identità falsificate o si inoltra traffico abusivo. L'autenticazione richiede verifica di busta, firme e From originale; i rapporti non riguardano sempre l'intermediario. Indaga sui risultati concreti invece di presumere un deterioramento inevitabile.

Qual è la differenza tra catch-all e alias?

Un alias definisce indirizzo e percorso. Il catch-all ammette destinatari sconosciuti del dominio secondo i criteri e li instrada al percorso predefinito. Cinque alias possono coprire un esempio semplice: le esigenze reali determinano quanti crearne.

Si può usare con Google Workspace o Microsoft 365?

Verifica funzioni attuali e permessi. In Google Workspace, prepara una regola in entrata in Gmail → Instradamento per destinatari inattivi o sconosciuti che sostituisca il destinatario di busta con la casella scelta, senza includere utenti attivi o gruppi. In Microsoft 365, Internal Relay disattiva DBEB senza creare catch-all da solo: richiede directory, connettori e percorsi compatibili senza cicli. Un amministratore autorizzato deve validare la topologia prima di cambiarla. Alias e caselle condivise possono evitare licenze aggiuntive secondo le condizioni.

Come disattivare il catch-all?

Identifica prima i destinatari legittimi e prepara alias o caselle. In cPanel/WHM, verifica Home → Email → Indirizzo predefinito e scegli il rifiuto SMTP con errore, non l'accettazione seguita da cancellazione silenziosa. In Google Workspace, esamina Gmail → Instradamento, oppure Instradamento predefinito se contiene una vecchia regola, e rimuovi la regola dopo verifica dei percorsi. In Microsoft 365, usa il modo autoritativo soltanto con directory completa e connettori verificati. In TrekMail, controlla Domini → dominio → Instradamento, Connessione nelle vecchie interfacce, → Casella catch-all → Nessun catch-all. Una finestra di 24-48 ore può orientare il monitoraggio, non è un termine obbligatorio di stabilizzazione.

Cosa usare al suo posto?

Definisci alias e percorsi per gli indirizzi realmente utilizzati. Cinque o meno possono bastare per un caso semplice, non per tutti. Confronta caselle condivise, licenze e piani attuali. Scegli secondo ricezione, responsabili e controlli senza presumere che una fatturazione elimini problemi di autenticazione o reputazione.