---
title: "Dirección de correo con signo más: cómo validarla | Emvero"
description: "El signo más es válido en la parte local de una dirección de correo. Aprende a conservar la etiqueta al validar, codificar, verificar y guardar la dirección."
url: https://emvero.io/es/blog/email-address-with-plus-sign/
language: es
updated: 2026-10-10
---

Blog

# ¿Es válida una dirección de correo con signo más?

Una dirección de correo con signo más puede ser válida. Conserva toda la parte local, verifica la dirección que se ha introducido y trata las reglas de las cuentas por separado.

Publicado 2026-09-18

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](https://www.rfc-editor.org/rfc/rfc5233.html#section-4) 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](https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/plus-addressing-in-exchange-online).

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](https://www.rfc-editor.org/rfc/rfc5322.html#section-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](https://emvero.io/es/glossary/email-syntax/) 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](https://emvero.io/es/compare/smtp-vs-syntax-validation/) 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](https://www.rfc-editor.org/rfc/rfc5321.html#section-2.3.11).

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](https://url.spec.whatwg.org/#urlencoded-parsing).

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](https://emvero.io/es/guides/signup-form-validation/) 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](https://emvero.io/es/blog/email-verification-vs-email-confirmation/) 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](https://emvero.io/es/guides/saas-trial-abuse/) 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.com` pasa por validación, transmisión y almacenamiento con la parte local intacta.
- El dominio de `Alex+orders@EXAMPLE.COM` se puede normalizar sin cambiar `Alex+orders`.
- `Alex..orders@example.com` sigue 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](https://emvero.io/es/email-verification-api/) para comprobar la dirección después de que el backend la reciba intacta.

## Términos que aparecen aquí

### Sintaxis de una dirección

Las reglas de formato de una dirección de correo, que se comprueban antes de consultar DNS o contactar con un servidor.

### Dirección de correo desechable

Una dirección de un servicio de correo temporal que puede abandonarse con facilidad.

## 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.

### Frenar el abuso de la prueba gratuita sin bloquear clientes

Aquí la decisión vive en los reason codes y no en el resultado, porque las direcciones que quiere rechazar y las que no puede permitirse rechazar comparten resultado.

[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