Email catch-all spiegate: cosa nascondono i domini accept-all alla verifica

Prima o poi ogni mittente B2B si scontra con lo stesso enigma. La lista è passata dalla verifica, gli indirizzi sono risultati a posto e la campagna è rimbalzata lo stesso. Molto spesso la causa è un dominio catch-all: un server di posta aziendale che dice sì a qualsiasi indirizzo, per cui il controllo che doveva proteggere la tua reputazione di mittente non aveva nulla di reale da segnalare.

Questa guida spiega cosa significa catch-all, perché la verifica non riesce a vedere oltre, come BounceIntel rileva e valuta questi indirizzi e quali regole decidono a quali conviene inviare.

Cosa significa catch-all (accept-all)

Un dominio catch-all, detto anche accept-all, è un dominio il cui server di posta accetta messaggi per qualsiasi indirizzo di quel dominio. jane.doe@, j.doe@, sales-team@ e xq7k2@ ricevono tutti la stessa accoglienza, che una casella con quel nome esista o no.

Le aziende lo configurano per motivi che sembrano ragionevoli:

• Non perdere posta. Un cliente che sbaglia il nome di un dipendente raggiunge comunque qualcuno, perché gli indirizzi sconosciuti finiscono in una casella condivisa.
• Il turnover del personale. La posta per chi ha lasciato l’azienda continua ad arrivare da qualche parte invece di tornare indietro ai clienti.
• I gateway di sicurezza. Alcuni servizi di filtraggio posti davanti alle caselle di un’azienda accettano tutto prima e smistano dopo.
• Una vecchia configurazione che nessuno guarda da anni.

Le configurazioni catch-all sono comuni sui domini aziendali e rare presso i grandi provider consumer, ed è per questo che il problema emerge soprattutto nelle liste B2B.

Perché SMTP dice sempre «sì»

La vera verifica email si basa su un’unica domanda posta via SMTP. Il verificatore si collega al server di posta del dominio, indica l’indirizzo con RCPT TO e legge la risposta. Un server normale cerca la casella e la accetta oppure la rifiuta come sconosciuta. Per la sequenza completa, leggi come funziona la verifica email.

Un server catch-all salta questa ricerca, o la rimanda. Risponde 250, accettato, per ogni destinatario. Cosa succede poi a un messaggio reale dipende dalla configurazione:

• Viene consegnato in una casella condivisa che qualcuno forse leggerà.
• Viene accettato e poi rimbalzato, minuti o ore dopo, come messaggio di rimbalzo separato, molto dopo la fine della conversazione del verificatore.
• Viene scartato in silenzio.

Il secondo caso è quello pericoloso. Un rimbalzo che arriva in ritardo conta comunque contro di te presso il tuo servizio di email marketing, e dice comunque ai provider di posta che scrivi a indirizzi inesistenti. Il tuo report di verifica era pulito, e la tua reputazione ha pagato lo stesso.

Come lo rilevano i verificatori

Dato che il server dice sì all’indirizzo reale, il verificatore gli chiede di un indirizzo che sicuramente non esiste. BounceIntel lo fa sulla stessa connessione SMTP usata per l’indirizzo che hai inviato: manda un secondo RCPT TO per una parte locale casuale di 15 caratteri sullo stesso dominio. In nessuno dei due casi viene inviato un messaggio.

• Se l’indirizzo casuale viene rifiutato, il server controlla davvero le caselle, e il fatto che abbia accettato il tuo indirizzo significa qualcosa.
• Se l’indirizzo casuale viene accettato, il dominio è catch-all, e l’accettazione del tuo indirizzo non dice nulla su quella casella.

Per alcuni provider di posta i cui server hanno un comportamento particolare noto, la sonda viene saltata e si applicano regole specifiche del provider.

Nella risposta dell’API, un catch-all rilevato appare così. È un risultato reale per un nome inventato sul nostro dominio, che accetta posta per qualsiasi indirizzo:

{
  "input": "[email protected]",
  "is_reachable": "risky",
  "smtp": {
    "can_connect_smtp": true,
    "is_deliverable": true,
    "is_catch_all": true,
    "is_disabled": false,
    "has_full_inbox": false
  },
  "score": {
    "reason_codes": ["catch_all", "catch_all_high_risk"],
    "catch_all": {
      "severity": "high",
      "confidence": 55,
      "factors": ["catch_all:corporate_domain", "website:present", "auth_records:present"]
    }
  },
  "bounce_risk": { "action": "verify_manually" }
}

Nota smtp.is_deliverable: true. Il server ha davvero accettato l’indirizzo, ed è proprio la risposta che non si può prendere alla lettera.

Perché «valido» qui è una bugia

Molti strumenti di verifica segnalano un indirizzo catch-all accettato come valido o consegnabile, perché tecnicamente il server ha detto sì. Ma il server dice la stessa cosa di un dipendente vero e di un nome che hai inventato trenta secondi fa. Un’etichetta che dà a entrambi la stessa risposta non è un’informazione. È un’ipotesi travestita da risultato.

Il danno è prevedibile. Una lista supera la verifica, il tasso di rimbalzo sale comunque e la colpa ricade sul verificatore. È ancora peggio con le liste costruite per tentativi, quando qualcuno ha generato [email protected] per ogni nome trovato su un sito o ha comprato un file di indirizzi del genere. Su un dominio catch-all ogni tentativo «si verifica», e la lista sembra perfetta fino al momento dell’invio.

BounceIntel non classifica mai un indirizzo catch-all come sicuro. is_reachable è risky, score.safe_to_send è false e il codice motivo catch_all spiega perché, così nessuna parte del tuo codice può scambiarlo per una casella confermata.

Valutare i catch-all e send_with_caution

Definire rischiosi tutti gli indirizzi catch-all è onesto, ma da solo serve a poco: nel B2B una buona parte di una lista perfettamente sana può trovarsi su domini catch-all. Per questo BounceIntel valuta ogni indirizzo in base alle prove che lo circondano e lo riporta in score.catch_all, con una severity (low, medium o high), un valore di confidence e i factors che li motivano.

Il punto di partenza dipende dal dominio. Un dominio aziendale parte da gravità alta; un provider consumer gratuito da gravità bassa. Poi le prove la spostano:

La gravità è ripetuta come codice motivo su cui il tuo codice può decidere: catch_all_low_confidence, catch_all_medium_confidence o catch_all_high_risk. Il consiglio in bounce_risk.action segue poi il rischio complessivo dell’indirizzo. Un indirizzo catch-all con buone prove alle spalle tende a tornare come send_with_caution, uno con poche prove come verify_manually, e uno che porta anche altri segnali negativi, come un indirizzo generico su un dominio senza sito web, come do_not_send.

send_with_caution significa proprio questo. L’indirizzo probabilmente va bene, ma va comunque usato in modo da limitare il danno se così non fosse.

Regole B2B: tenere o escludere

La verifica ti dà le prove. Cosa fare con un indirizzo catch-all è una scelta di policy, e conviene metterla per iscritto perché tutto il team la applichi allo stesso modo. Queste sono le regole che consigliamo.

Tieni l’indirizzo, e inviagli in un segmento a parte, quando:

• arriva da un modulo compilato dalla persona stessa, idealmente con double opt-in, o da una conversazione reale;
• il contatto ha aperto, cliccato o risposto negli ultimi mesi;
• la sua gravità è low o medium, oppure segue uno schema di nome già verificato in quell’azienda;
• appartiene a una persona con nome e cognome su un dominio con sito web e SPF o DMARC configurati.

Escludilo quando:

• è un indirizzo generico come info@ o sales@ in una lista fredda, dove i codici catch_all e role_account compaiono insieme;
• è stato ipotizzato, raccolto con scraping o acquistato, qualunque cosa dica un verificatore;
• la sua gravità è high e non hai alcuno storico di interazioni con esso;
• ha già generato un hard bounce, anche una sola volta. Non ritentare mai un hard bounce.

Quando invii a indirizzi catch-all:

1. Tienili in un segmento separato dagli indirizzi confermati, così un problema resta circoscritto.
2. Parti con un piccolo lotto e guarda il tasso di rimbalzo prima di inviare il resto.
3. Fermati e analizza se i rimbalzi salgono, invece di spingere fuori l’intero segmento.
4. Rimuovi subito ogni hard bounce, da tutte le liste.
5. Verifica di nuovo il segmento prima della campagna successiva, perché le prove sugli schemi di nome su cui si basa il punteggio crescono a ogni controllo.

Controlla tu stesso un indirizzo catch-all

Nel tuo codice, leggi smtp.is_catch_all dalla risposta di POST /v1/check_email, o da ogni riga di un job in blocco, e decidi in base a score.catch_all.severity e bounce_risk.action. La documentazione dell’API descrive ogni campo e la verifica in blocco mostra come far passare un’intera lista attraverso gli stessi controlli.