Intercetta le e-mail di registrazione usa e getta, digitate male o senza server di posta

Offri al tuo modulo di registrazione un controllo tempestivo di ogni indirizzo: sintassi, domini usa e getta/temporanei noti, se il dominio ha almeno un server di posta, probabili refusi e indirizzi di ruolo — restituito come verdetto accept, review o reject con i relativi motivi. Chiama POST /v1/email/validate dal JavaScript del tuo modulo, oppure verifica liste in blocco dal tuo backend o dalla dashboard.

Leggi il riferimento della verifica email Vedi il flusso di prevenzione degli abusi in registrazione →

Richiesta e autenticazione

Invia un body JSON { "email": "user@example.com" } a POST /v1/email/validate con una chiave pubblicabile limitata per origine nell'header X-Api-Key — lo stesso tipo di chiave e lo stesso modello di origini consentite di GET /v1/geo, quindi è sicuro chiamarlo direttamente da un modulo di registrazione mentre il visitatore digita o invia. Lato server, la tua chiave segreta sblocca POST /v1/email/batch (fino a 100 indirizzi per richiesta), job di lista asincroni fino a 100.000 indirizzi (via API o dalla pagina Email lists della dashboard, CSV in ingresso e in uscita) e POST /v1/signup/check, che combina la verifica e-mail con gli indicatori di rete dell'IP che si registra in un unico punteggio.

Leggi il verdetto, poi i motivi

verdict è l'esito più grave: reject per sintassi non valida, un dominio inesistente, un dominio senza server di posta o un dominio usa e getta; review per un sospetto refuso, un indirizzo di ruolo come info@, un dominio con solo un server di posta implicito o una ricerca DNS non completata; altrimenti accept. reasons elenca ogni condizione riscontrata, così il tuo modulo può mostrare un messaggio specifico — e quando didYouMean è valorizzato, proponi la correzione invece di un errore.

Quando chiamarlo

Chiamalo all'uscita dal campo o all'invio anziché a ogni tasto premuto — verificare un indirizzo ancora incompleto a ogni carattere aggiunge richieste senza un segnale utile e può far lampeggiare un messaggio di errore mentre il visitatore sta ancora digitando. Ogni chiamata conta come una richiesta.

Se la richiesta fallisce

Fallisci in modo aperto: lascia proseguire la registrazione se la richiesta di rete va in errore o in timeout, anziché bloccare ogni visitatore per un'interruzione lato client. Lato server, una ricerca DNS fallita viene segnalata con il motivo dns_unavailable (verdetto review), mai come errore o reject. Conserva ciò che il visitatore ha già digitato, così una verifica fallita non gli fa mai perdere quanto inserito.

Come vengono rilevati i domini usa e getta

I domini usa e getta/temporanei noti derivano dall'unione di tre liste open source mantenute dalla community (vedi fonti dei dati), aggiornate ogni poche ore, con una allowlist affinché una voce errata a monte non possa mai segnalare un grande provider. Corrispondono anche i sottodomini di un dominio in lista. I nuovi domini usa e getta non ancora presenti in alcuna lista vengono spesso intercettati tramite il loro server di posta: i servizi usa e getta puntano molti domini verso gli stessi pochi host di posta, e un dominio il cui server di posta è noto per servire domini in lista viene segnalato con disposableSource: mx_host. Un provider molto recente su un nuovo server di posta potrebbe non essere ancora segnalato.

Utilizzo e quota

Ogni indirizzo verificato conta come una richiesta nel limite mensile condiviso del tuo piano — una verifica singola, ogni indirizzo di un batch, ogni indirizzo distinto di un job di lista — insieme al resto del tuo traffico, con lo stesso limite di frequenza al minuto. Non esiste un piano né un prezzo e-mail separato. Il limite di frequenza al minuto conta le chiamate HTTP, non gli elementi: un batch fino a 100 IP o indirizzi email conta come una sola richiesta, mentre ogni elemento continua a contare separatamente nel limite mensile di richieste.

Cosa questo non verifica

Ogni controllo è a livello di dominio o di indirizzo. Watch-IP non contatta mai il server di posta del destinatario, quindi un risultato non stabilisce che la casella esista, che la posta vi arriverà o che appartenga alla persona che si registra. Un verdetto accept significa «nessun problema rilevato», non un indirizzo di cui è confermato il funzionamento — per questo usa un'e-mail di conferma.

Campi della risposta

syntaxValid: Se l'indirizzo è sintatticamente valido.
isDisposable: Se il dominio corrisponde a un provider usa e getta/temporaneo noto, direttamente, tramite un dominio padre o tramite il suo server di posta. Sempre false quando syntaxValid è false.
disposableSource: list, parent_domain o mx_host — perché isDisposable è true; altrimenti null.
mx: Lo stato del server di posta del dominio (found, implicit, none, null_mx, no_domain o unknown) e il suo host MX principale.
didYouMean: Una probabile correzione del refuso come gmial.com → gmail.com, oppure null.
isRoleAccount / isFreeProvider: Indicatori di indirizzo di ruolo (admin@, info@, noreply@…) e di provider di posta per consumatori. Il provider gratuito è solo informativo.
normalizedEmail / canonicalEmail: L'indirizzo in minuscolo e lo stesso senza +tag (e senza i punti di Gmail) per individuare gli account duplicati.
verdict / reasons: accept, review o reject, più ogni codice motivo riscontrato — vedi il riferimento per l'elenco completo.

Agisci in base al verdetto

JavaScript del modulo di registrazione

async function checkEmail(email) {
  const response = await fetch('https://api.watch-ip.com/v1/email/validate', {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_PUBLISHABLE_KEY', 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  });
  if (!response.ok) return { state: 'unknown' }; // fail open — non bloccare la registrazione per un errore di rete

  const result = await response.json();
  if (result.didYouMean) return { state: 'suggest', suggestion: result.didYouMean };
  if (result.verdict === 'reject') return { state: 'reject', reasons: result.reasons };
  return { state: 'ok' }; // accept o review: lascia passare la registrazione e segnalala sul tuo backend
}

Mostra un messaggio distinto per ogni motivo — invalid_syntax, disposable_domain e no_mail_server richiedono azioni correttive diverse da parte del visitatore — e proponi didYouMean come correzione con un clic.

Domande frequenti

Verifica che la casella di posta esista?

No. Verifica la sintassi, le liste e i record DNS del server di posta del dominio, e la forma dell'indirizzo. Non contatta mai il server di posta né conferma che la singola casella esista — un reject per no_mail_server riguarda l'intero dominio.

Un accept dimostra che l'e-mail funziona?

No. accept significa che nessun controllo ha rilevato problemi, non che l'indirizzo riceverà sicuramente posta o che appartenga alla persona che si registra. Usa un'e-mail di conferma quando ti serve questa garanzia.

Gli utenti possono aggirare la convalida da browser?

Sì. Qualsiasi controllo lato browser, compreso questo, può essere aggirato disattivando JavaScript o chiamando direttamente il tuo endpoint di registrazione. Applica sul tuo backend ogni decisione che conta — POST /v1/signup/check è pensato proprio per questo.

Posso ripulire una lista esistente?

Sì. Carica un CSV nella pagina Email lists della dashboard, oppure invia fino a 100.000 indirizzi a POST /v1/email/jobs con la tua chiave segreta, quindi scarica un CSV di risultati con verdetto e motivi per ogni riga. I duplicati sono addebitati una volta, e caricamenti e risultati vengono eliminati dopo 7 giorni.

Come vengono conteggiate le richieste?

Una richiesta per indirizzo verificato, conteggiata nel limite mensile condiviso del tuo piano. I duplicati all'interno di un job di lista contano una volta; una verifica della registrazione conta come una richiesta.