---
title: "Verificación y confirmación de correo: cuándo usar cada una | Emvero"
description: "Compara la verificación de direcciones con la confirmación del buzón. Un resultado entregable no sustituye al enlace de confirmación: guarda ambos estados por separado."
url: https://emvero.io/es/blog/email-verification-vs-email-confirmation/
language: es
updated: 2026-10-10
---

Blog

# Verificación de correo y confirmación de la dirección

La verificación comprueba la dirección. La confirmación demuestra acceso a un mensaje. Aprende a separar ambos resultados en el registro.

Publicado 2026-10-06

La verificación de correo comprueba si una dirección parece utilizable antes de enviarle un mensaje. La confirmación pide que alguien use un enlace o un código recibido en esa dirección. Si el acceso a la cuenta depende del control del buzón, hace falta confirmar la dirección incluso después de un resultado positivo.

Es fácil confundir ambos pasos porque a menudo se llaman «verificar el correo». Decide qué necesita saber tu sistema: qué revela la infraestructura de correo sobre la dirección, o si alguien puede acceder a un mensaje enviado a ella.

## Qué demuestra cada paso

| Pregunta | Verificación de correo antes del envío | Confirmación de la dirección |
| --- | --- | --- |
| ¿Qué ocurre? | Se comprueban la sintaxis, el dominio y la ruta de correo. Una verificación completa también puede obtener evidencia SMTP sobre el destinatario. | Tu aplicación envía un mensaje y valida el token del enlace o el código recibido. |
| ¿Emvero envía un mensaje durante la comprobación? | No. El sondeo SMTP termina antes de `DATA`; una comprobación de dominio no abre ninguna sesión SMTP. | Tu aplicación o proveedor de correo envía el mensaje de confirmación por separado. |
| ¿Qué puede demostrar un resultado positivo? | La evidencia disponible respalda aceptar la dirección para el siguiente paso. | Alguien accedió al mensaje y completó la confirmación en ese momento. |
| ¿Qué queda sin demostrar? | El control del buzón, la identidad personal y la entrega futura. | La titularidad exclusiva o permanente, la identidad personal y la entrega futura. |

Una ruta de correo que funciona corresponde al dominio. Incluso la aceptación del destinatario puede deberse al comportamiento catch-all, así que no identifica a la persona que introdujo la dirección. El artículo sobre [cómo funcionan las comprobaciones](https://emvero.io/es/blog/how-email-verification-works/) explica el proceso completo.

La [documentación sobre el alcance de Emvero](https://docs.emvero.io/) lo indica expresamente: el servicio no envía mensajes y una comprobación positiva no sustituye a la confirmación del control del buzón.

## Una dirección entregable puede seguir sin confirmar

Imagina que alguien introduce `alex@example.com`. Es un ejemplo ficticio: no se comprobó ningún buzón ni se envió ningún mensaje.

Tu aplicación recibe un resultado completo con `deliverable` y `allow`. Eso permite continuar el registro. No revela si la persona se equivocó e introdujo una dirección que funciona, pero pertenece a otra persona. Marcarla como confirmada a partir de la comprobación daría por hecho un acceso al buzón que nadie ha demostrado.

Guarda el resultado de verificación por separado de un campo de la aplicación como `email_confirmed_at`. Este campo de ejemplo pertenece a tu aplicación, no a la API de Emvero. Asígnale un valor solo cuando el servidor acepte una confirmación válida para esa cuenta y esa dirección. Conserva también el resultado de verificación para poder explicar ambas decisiones.

Si la dirección corresponde a un equipo o una función, consulta la [política de registro para direcciones genéricas](https://emvero.io/es/blog/block-role-based-email-signups/) para decidir si debe usarse para acceder a la cuenta o como contacto separado.

La verificación y la confirmación pueden dar respuestas distintas para una misma dirección:

| Evidencia sobre la dirección | Confirmación en la aplicación | Qué puedes concluir |
| --- | --- | --- |
| `deliverable` | Sin completar | La comprobación respalda la dirección; el control del buzón sigue sin confirmar. |
| `unknown` | Completada | La persona accedió al mensaje de confirmación aunque la comprobación previa no fue concluyente. Conserva ambos resultados. |
| `risky` | Completada | La confirmación aporta evidencia de acceso; no elimina la señal que llevó a clasificar la dirección como de riesgo. |
| `pending` | Sin completar | La comprobación del destinatario sigue en curso y el control del buzón no está confirmado. Son estados independientes. |

Lee `status`, `action` y `reason_codes` juntos. En Emvero, `risky` puede ir acompañado de `allow` o `allow_with_email_confirmation`, según la causa. `unknown` indica que la evidencia no es concluyente; `undeliverable` respalda el rechazo según las reglas actuales de evaluación. La guía para [interpretar un resultado de verificación](https://emvero.io/es/blog/reading-a-verification-result/) explica la diferencia entre un estado y una recomendación.

## Usa ambos pasos si el acceso a la cuenta depende del correo

La comprobación previa puede detectar un problema de formato o de dominio mientras la persona aún puede corregirlo. La confirmación aporta después la evidencia de acceso que la comprobación no puede obtener.

En el registro, aplica la acción devuelta y las reglas de tu producto. Si recibes `reject`, pide una corrección. Con `allow_with_email_confirmation`, continúa el proceso con la confirmación como requisito. Mantén ese paso incluso con `allow` si necesitas demostrar el control del buzón. Una recomendación técnica para continuar no autoriza el acceso a la cuenta de otra persona.

Si el resultado es `pending`, recupera el resultado final o aplica la alternativa prevista en tu formulario. Distingue el trabajo en curso de un enlace de confirmación caducado, un mensaje sin respuesta y un resultado final `unknown`. La [guía de validación en formularios de registro](https://emvero.io/es/guides/signup-form-validation/) cubre la implementación completa.

Para una lista de contactos existente, la verificación puede aportar evidencia actual sobre las direcciones sin escribir a cada persona. Esa tarea no exige enviar mensajes de confirmación no solicitados a toda la lista. Tu aplicación debe registrar por separado si alguien aceptó recibir una campaña.

## Vincula la confirmación a la dirección correspondiente

Si alguien corrige la dirección antes de confirmarla, comprueba el nuevo valor e impide que una confirmación de la dirección anterior confirme la nueva. El registro de confirmación debe identificar la dirección que realmente se confirmó.

Usa tokens aleatorios generados de forma criptográficamente segura, de un solo uso y con caducidad, como recomienda la [guía de OWASP sobre confirmación de correo](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html#email-ownership-verification). Valida la confirmación en el servidor antes de registrarla.

Si un intento de confirmación caduca o queda sin completar, guarda ese resultado por separado. Ese intento no ha demostrado acceso, pero tampoco ha demostrado que la dirección sea `undeliverable`. Ofrece una opción para corregir la dirección o reenviar el mensaje según las reglas de tu aplicación.

Ninguno de los dos pasos demuestra identidad personal, permiso para enviar marketing, interés o llegada futura a la bandeja de entrada. El mensaje de confirmación también puede llegar a un buzón compartido o reenviarse a otra dirección. Una confirmación completada es evidencia de acceso en ese momento.

Para añadir la comprobación de la dirección, usa la [API de verificación de correo](https://emvero.io/es/email-verification-api/) desde tu servidor. El envío de mensajes y el estado de confirmación quedan en tu aplicación.

## Términos que aparecen aquí

### Handshake SMTP

El intercambio de órdenes y respuestas con un servidor de correo antes de transmitir el mensaje.

### Dominio catch-all

Un dominio cuyo servidor acepta destinatarios aunque no exista un buzón para cada dirección.

### Greylisting

Una política antispam que aplaza un intento SMTP y puede permitirlo más adelante.

## Situaciones a las que se aplica

### Validar una dirección en un formulario de registro

Alguien espera al otro lado de la petición, así que la latencia define el diseño y un rechazo equivocado le cuesta el cliente.

[Todos los artículos](https://emvero.io/es/blog/)

## Elige qué comprobar ahora.

Haz una consulta desde tu cuenta y examina los datos del resultado.

Empezar gratis