Comprobar una dirección nunca le envía un correo. Ni una sola vez, ni por accidente. Por qué es así

Empezar gratis

Verificación en tiempo real

Decide mientras siguen en la página.

Una petición por dirección. La respuesta dice qué encontramos y qué sugerimos hacer al respecto, así que tu formulario de registro puede dejarla pasar, pedir confirmación, añadir un paso o rechazarla sin que tengas que escribir esas reglas desde cero.

No se envía ningún mensaje a la direcciónCódigos de motivo estables

Crear cuenta
Correo

person@example.com

Dirección verificada — continúa

Vista previa del producto, no interactiva.

POST /v1/verifications
{ "status":       "deliverable",
  "action":       "allow",
  "confidence":   0.92,
  "checks":       { "accept_all": "no",
                    "disposable": false },
  "reason_codes": ["MX_FOUND",
                    "SMTP_RCPT_ACCEPTED"] }

Dónde encaja

Cuatro sitios por donde entra una dirección a tu producto.

Registro

Verifica antes de que exista la cuenta, para que un dominio mal escrito nunca acabe siendo un ticket de soporte.

Captación de leads

Mantén las direcciones desechables y los buzones compartidos fuera del pipeline ya en el formulario, mientras todavía no te cuesta nada.

Checkout

El recibo tiene que llegar. Detecta la errata mientras el cliente sigue ahí para corregirla.

Entrada de datos interna

Formularios de CRM y back-office, donde la dirección la teclea alguien que no es su dueño.

La forma de una integración

Una llamada, una decisión.

  1. 01

    Alguien teclea una dirección

    En tu formulario, en tu dominio.

  2. 02

    Tu servidor llama a la API

    Desde el servidor, con tu clave. Nunca llega al navegador.

  3. 03

    Reunimos las pruebas

    Sintaxis, el dominio, su enrutado, y un sondeo del buzón cuando merece la pena.

  4. 04

    Vuelve la respuesta

    Estado, recomendación, comprobaciones y códigos de motivo. O pending, con un intervalo para volver.

  5. 05

    Tu flujo decide

    Dejarlos entrar, pedirles que confirmen, añadir un paso, o parar ahí. Con tus reglas, si lo prefieres.

La respuesta

El estado es lo que vimos. La acción es lo que sugerimos.

Son dos campos separados a propósito. Productos distintos pueden aplicar reglas completamente distintas a pruebas idénticas, y nada del sondeo cambia por ello.

Estado y acción recomendada
EstadoSignificadoAcción recomendada
deliverableEl buzón la aceptó y no hubo señales de alertaallow
riskyPuede que funcione, pero las pruebas son escasaschallenge
undeliverableUn fallo definitivo, y no va a cambiarreject
unknownEl servidor de correo no quiso decirloallow_with_email_confirmation
pendingLas pruebas más lentas todavía están llegandoconsultar tras retry_after_ms

Salvo un fallo definitivo, aquí todo se inclina por dejar pasar a la persona hacia un correo de confirmación. Ese correo es lo único que demuestra de verdad que alguien tiene un buzón.

Vías de integración

Tres vías, según quién lo construya.

API en el servidor

Ideal para equipos de producto que ya tienen backend.
Esfuerzo un endpoint, una credencial.
Seguridad la clave se queda en tu servidor; el acceso anónimo no se ofrece.

Plataforma de automatización

Ideal para equipos sin tiempo de ingeniería.
Esfuerzo conectar la cuenta, mapear un campo.
Seguridad la credencial vive en el almacén de la plataforma.

Importación por lotes

Ideal para la limpieza periódica de un almacén que ya es tuyo.
Esfuerzo subir y exportar, sin código.
Seguridad el mismo tratamiento y la misma conservación que todo lo demás.

Enlazaremos la documentación aquí el día que el portal público de desarrolladores esté en marcha. Hasta entonces no hay nada que enlazar, y preferimos decirlo a mandarte a una página que no existe.

Tiempos, sin adornos

No es instantáneo, y no vamos a llamarlo así.

Las respuestas que salen de la sintaxis, el DNS y el enrutado llegan rápido. Las que necesitan sondear un buzón dependen de que descuelgue otro, y unos cuantos proveedores retrasan el primer contacto a propósito.

Vía rápida

Los fallos de análisis, los dominios que no existen y las declaraciones null MX se resuelven todos sin contactar con nadie.

Vía con sondeo

Donde el sondeo está justificado, la respuesta puede volver como pending con un retry_after_ms explícito, así que la consulta está acotada en vez de ser a ciegas.

Cifras publicadas

Latencia mediana y p95, límites de peticiones y disponibilidad: [CIFRAS MEDIDAS]. Aparecerán aquí en cuanto estén medidas, y ni un día antes.

Manejar la incertidumbre

Qué pasa cuando la respuesta no es limpia.

Una marca verde y una cruz roja son la parte fácil. Lo que dice si un verificador vale algo es qué hace cuando SMTP no da una respuesta clara.

Dominios que aceptan todo

Un dominio que acepta a cualquier destinatario no dice nada sobre ese buzón concreto. La aceptación se puntúa a la baja y se informa como con riesgo con ACCEPT_ALL_DOMAIN, nunca se asciende a entregable.

Greylisting y limitación

Un rechazo temporal no es una negativa. Se registra con su propio código de motivo para poder programar un reintento en vez de dar la espalda por error a una persona real.

Tiempos agotados

Una conexión que nadie contesta te da unknown, nunca undeliverable. No responder no es lo mismo que decir que no.

Bloqueos por política del proveedor

Algunos proveedores rechazan los sondeos por principio, y parte de esos rechazos apuntan a nuestra identidad de envío, no a tu destinatario. Esos los seguimos por separado, porque no dicen absolutamente nada sobre la dirección.

El derecho a rechazar hay que ganárselo.Las pruebas de sondeo solo pueden producir un rechazo donde hemos medido su precisión para ese proveedor. Donde no, lo predeterminado es a prueba de fallos y no se rechaza a nadie. Rechazar con pruebas no medidas es exactamente cómo la política general de un proveedor se convierte en una persona real que no puede registrarse en tu producto.

Credenciales y abuso

En el servidor, por diseño.

Claves

Las peticiones se autentican con una credencial bearer. Una cuenta puede tener varias, cada una asociada a una integración con nombre, así que una clave puede rotarse o revocarse sin tumbar a todos los llamantes. El acceso anónimo no es una opción configurable.

Límites

El volumen de peticiones está acotado por llamante y por red de origen. Un rechazo lleva una pista explícita de reintento para que el cliente se retire en vez de insistir a ciegas.

Lo que nunca cruza la frontera

El texto de respuesta del servidor remoto se queda dentro del sistema. Filtra detalles de la infraestructura de destino, puede llevar caracteres de control no fiables y cambia cada vez que un proveedor reescribe un mensaje.

Idempotencia

Una verificación repetida de la misma dirección devuelve la misma conclusión bajo el mismo identificador, en vez de hacer el trabajo dos veces y escribir un segundo registro.

Ponlo delante de tu formulario de registro.

Empieza gratis. Ven a hablar con nosotros cuando el volumen o las compras necesiten algo distinto.