Sí. Una dirección de correo con un signo más en la parte local puede ser válida. No la rechaces ni elimines la etiqueta solo porque contiene +. Comprueba la dirección completa: una sintaxis correcta no demuestra que el servidor receptor la acepte.
En un formulario o una integración con una API, conserva la dirección que ha facilitado la persona. Si cambias Alex+orders@example.com por Alex@example.com, verificas otro destinatario y guardas otra dirección de contacto.
Qué significa el signo más
El direccionamiento con signo más añade una etiqueta antes de la @. En Alex+orders@example.com, la parte local es Alex+orders y el dominio es example.com. Un sistema de correo que admita esta función puede entregar los mensajes en el mismo buzón que Alex@example.com.
Ese comportamiento depende del sistema receptor. RFC 5233 indica que la codificación de estas subdirecciones depende del sistema o de su implementación. Ver un + no permite deducir cómo interpreta la dirección un dominio cualquiera.
Exchange Online activa esta función por defecto, pero una organización puede desactivarla. Comprueba la configuración del proveedor receptor cuando necesites saber si la admite. Consulta la documentación de Microsoft sobre el direccionamiento con signo más.
Todas las direcciones de los ejemplos son sintéticas y usan dominios reservados para ejemplos. Muestran cómo tratar los datos, no buzones en funcionamiento.
Permite el carácter y valida toda la dirección
La gramática de la parte local sin comillas permite +. Las demás restricciones siguen vigentes: admitir ese carácter no convierte cualquier cadena en una dirección válida. RFC 5322, sección 3.2.3.
Por ejemplo, el analizador actual de Emvero acepta la estructura de Alex+orders@example.com, pero rechaza Alex..orders@example.com. El problema de la segunda dirección son los puntos consecutivos. Las reglas de sintaxis del correo explican las demás restricciones.
Si el formulario rechaza la primera dirección, revisa tanto el validador del frontend como el analizador del backend. Una lista de caracteres permitidos que solo incluya letras, dígitos, puntos, guiones bajos y guiones en la parte local excluye + antes de que empiece la verificación.
Separa la validación del formato de la evidencia que se obtiene después. La comparación entre validación de sintaxis y verificación SMTP explica qué puede establecer cada método.
Normaliza el dominio y conserva la parte local
El sistema receptor define el significado de la parte local, y los clientes SMTP deben conservar sus mayúsculas y minúsculas. Los dominios no distinguen entre ambas. RFC 5321, secciones 2.3.11 y 2.4.
En una integración general, conserva las mayúsculas, los puntos y el sufijo con signo más de la parte local. No apliques las reglas de alias de un proveedor a todas las direcciones.
El analizador actual de Emvero admite la sintaxis habitual con una etiqueta tras el signo más, conserva la parte local y normaliza el dominio. Para esta entrada sintética, el tratamiento esperado es:
| Entrada o componente | Valor |
|---|---|
| Dirección introducida | Alex+orders@EXAMPLE.COM |
| Parte local conservada | Alex+orders |
| Dominio normalizado | example.com |
| Dirección usada en la comprobación | Alex+orders@example.com |
Verificar la versión sin etiqueta respondería a otra pregunta. Aunque ambas direcciones llegaran al mismo buzón, la aplicación perdería la dirección de contacto y la etiqueta elegidas por la persona.
Comprueba si la codificación convirtió + en un espacio
Al analizar datos application/x-www-form-urlencoded, un + literal se convierte en un espacio. Una serialización correcta codifica el signo más como %2B. Estándar URL de WHATWG.
Usa un serializador para construir el valor en lugar de concatenar una cadena de consulta:
const email = "Alex+orders@example.com";
const body = new URLSearchParams({ email });
console.log(body.toString());
console.log(new URLSearchParams(body.toString()).get("email"));
El resultado es:
email=Alex%2Borders%40example.com
Alex+orders@example.com
Compara el valor del campo con el que recibe el backend. Si este último es Alex orders@example.com, revisa la codificación antes de atribuir el error al validador. Corrige el serializador: sustituir cada espacio por + después de decodificar ocultaría entradas mal formadas.
Para una petición a Emvero, envía JSON a POST /v1/verifications desde el backend. Conserva la dirección completa en el cuerpo de la petición:
{
"email": "Alex+orders@EXAMPLE.COM"
}
Mantén las credenciales de la API en el servidor.
Verifica la dirección con etiqueta y confirma el acceso al buzón
Un signo más por sí solo no demuestra que exista un buzón, que el proveedor ofrezca correo desechable ni que la cuenta sea un duplicado. Verifica toda la dirección introducida y lee los campos action y reason_codes de la respuesta. Según la evidencia, la recomendación puede ser allow, allow_with_email_confirmation o reject.
Si el resultado es unknown, la evidencia disponible no permite llegar a una conclusión sobre la dirección. Si es pending, el trabajo aún no ha terminado. Ninguno justifica un rechazo permanente solo porque la dirección contiene un signo más.
Cuando el acceso a la cuenta depende del control del buzón, envía tu propio mensaje de confirmación a la dirección completa. La verificación de Emvero no envía ese mensaje ni demuestra quién controla el buzón. La guía de validación en formularios de registro sitúa la verificación y la confirmación dentro del flujo completo.
La comparación entre verificación de direcciones y confirmación del buzón explica por qué conviene guardar ambos resultados por separado.
Separa las reglas sobre cuentas duplicadas de los datos de contacto
Eliminar una etiqueta no es una regla de identidad válida para todos los proveedores. Podrías unir direcciones que el sistema receptor trata de forma distinta. Los alias por sí solos tampoco demuestran que dos registros pertenezcan a la misma persona.
Si el producto necesita agrupar direcciones confirmadas según una regla para un proveedor conocido, guarda esa agrupación por separado de la dirección de contacto, confirmación y recuperación de la cuenta. No sobrescribas la dirección de contacto ni unas cuentas automáticamente. La guía sobre el abuso de pruebas gratuitas explica qué puede aportar la evidencia del correo a esa decisión.
Antes de cambiar el validador, añade pruebas de regresión para todo el recorrido por la aplicación:
Alex+orders@example.compasa por validación, transmisión y almacenamiento con la parte local intacta.- El dominio de
Alex+orders@EXAMPLE.COMse puede normalizar sin cambiarAlex+orders. Alex..orders@example.comsigue rechazándose por su sintaxis incorrecta.- La codificación y decodificación de los datos del formulario conservan
+. Quitar una etiqueta de un valor usado para comparar no provoca que se unan cuentas.
Conecta la API de verificación de correo para comprobar la dirección después de que el backend la reciba intacta.