Scegliere un servizio di validazione email senza credere a nessuno sulla parola.

La catena è più o meno standard nella categoria. Cambia quanto in profondità scende ciascun fornitore e cosa fa quando un passaggio resta senza risposta.

• La sintassi, secondo le regole reali degli indirizzi e non secondo un’espressione regolare trovata su un forum. Molti indirizzi legittimi sembrano sbagliati e molti illegittimi sembrano corretti.
• Il dominio e il DNS, che intercettano il provider scritto male, il dominio scaduto e quello che non ha mai accettato posta.
• I record MX, cioè il fatto che il dominio abbia dove consegnare. Un dominio con un sito e senza MX non può ricevere email.
• I provider usa e getta, recapitabili oggi e spariti la settimana prossima.
• Gli indirizzi di ruolo come info, fatturazione o supporto. Sono caselle reali e sono anche quelle che segnalano più volentieri una campagna come spam.
• La casella stessa, chiedendo al server destinatario se accetterebbe posta per quell’indirizzo. È questo passaggio a separare un servizio di validazione da una semplice consultazione.

Buona parte dei domini aziendali accetta posta per ogni indirizzo e smista dopo. Chiedete se vendite@ esiste e il server dice di sì. Chiedete di una stringa a caso e dice ancora di sì.

Significa che nessun servizio al mondo può stabilire dall’esterno se una casella di un dominio catch-all è reale. Qualsiasi fornitore che lasci intendere il contrario sta indovinando da schemi o si appoggia a dati raccolti altrove.

Un buon servizio lo dice, contrassegna il dominio come catch-all e vi lascia la decisione con il contesto necessario. Uno cattivo arrotonda la supposizione a valido e lascia che sia il vostro tasso di rimbalzo a scoprire la verità.

Immaginate che l’indirizzo che avete approvato rimbalzi durante la campagna di un cliente e che vi chiedano conto. Se la vostra esportazione contiene la parola valido e nient’altro, non avete niente da dire.

È la ragione pratica per preferire i servizi che pubblicano codici di motivo. Non è una comodità da sviluppatori. È la differenza tra un rapporto consegnabile a un cliente e un colore da difendere per fiducia. Conta di più, non di meno, se lavorate per conto terzi.

Confrontare due servizi di validazione è facile da fare male. Gli errori tipici sono provare su indirizzi inventati, provare in giorni diversi e provare solo gli indirizzi già sospetti.

Usate un campione reale di 500 o 1.000 indirizzi dalla lista a cui scriverete, passate ogni servizio nelle stesse ore e conservate le esportazioni grezze invece delle schermate di riepilogo.

• Contate sconosciuti e catch-all per servizio, e leggete cosa dice ciascuno di essi.
• Estraete le righe su cui i servizi divergono. Quell’insieme è piccolo ed è tutta la decisione.
• Inviate a una parte degli indirizzi contesi e leggete il registro dei rimbalzi il giorno dopo.
• Cronometrate un lotto di dimensione realistica. Un servizio veloce su mille indirizzi può essere lentissimo su mezzo milione.
• Guardate cosa conserva l’esportazione. Le vostre colonne devono tornare intatte e nell’ordine in cui le avete inviate.

Cinque domande coprono quasi tutte le sorprese sgradevoli di questa categoria, e a tutte e cinque si risponde leggendo la documentazione del fornitore prima di parlare con qualcuno.

• I crediti scadono, e una quota mensile non usata viene riportata?
• L’accesso all’API è incluso nel piano che state guardando o parte più in alto?
• Cosa succede se riverificate un indirizzo controllato il mese scorso?
• Per quanto tempo viene conservato l’indirizzo dopo un lavoro, e potete cancellarlo prima?
• Cosa viene addebitato esattamente per un risultato sconosciuto?

BounceIntel restituisce la prova insieme al verdetto. Ogni risultato porta un punteggio da 0 a 100, i codici di motivo dietro e un’azione consigliata, e lo stesso motore risponde al pannello, al lotto e all’API, così un controllo puntuale e un file grande non si contraddicono mai.

La forma commerciale è volutamente semplice. Crediti alla registrazione senza carta, piani mensili che si azzerano con il periodo, pacchetti a consumo che aspettano di essere usati, e una chiave API con qualsiasi piano a pagamento invece che solo con quelli grandi.