Sí. Una dirección de correo con un apóstrofo puede ser válida si el carácter aparece antes de la @. En o'neil@example.com, el nombre anterior a la @ es la parte local. El apóstrofo ASCII recto es uno de los caracteres permitidos por RFC 5322.
Si un formulario rechaza esta dirección, averigua en qué paso de validación o almacenamiento falla. Borrar el carácter cambia la dirección. Un formato permitido no demuestra que un proveedor ofrezca ese buzón ni que pueda recibir mensajes.
Comprueba el carácter y su posición
El apóstrofo recto ' es U+0027; el carácter curvo ’ es U+2019. Pueden parecer similares en un campo, pero son caracteres distintos. El segundo queda fuera del conjunto ASCII que usa la gramática habitual de la parte local.
| Ejemplo | Qué indica |
|---|---|
o'neil@example.com |
El apóstrofo recto está permitido en esta estructura de la parte local |
o’neil@example.com |
Se ha introducido otro carácter Unicode; comprueba por separado la compatibilidad con direcciones internacionalizadas |
o'neil@exam'ple.com |
El dominio contiene un carácter no permitido en las etiquetas habituales de los dominios de correo |
o'neil..sales@example.com |
Los puntos consecutivos hacen que esta parte local sin comillas sea inválida |
La gramática de direcciones de SMTP define las reglas del dominio y los segmentos de la parte local separados por puntos. Los ejemplos usan un dominio reservado para documentación y no representan buzones operativos.
Si el campo contiene el carácter curvo, pide a la persona que confirme cómo se escribe su dirección. No lo sustituyas sin avisar ni elimines signos de puntuación. La referencia sobre sintaxis de correo explica otras restricciones de formato.
Localiza el paso que rechaza el valor
Empieza por el campo del navegador. Un <input type="email"> de HTML permite el apóstrofo recto en la parte local. Un pattern propio, un validador de JavaScript o una biblioteca de formularios pueden añadir una regla más restrictiva. La especificación HTML del campo de correo define una gramática que difiere de la sintaxis SMTP.
Ejecuta este código en la consola del navegador para probar solo la comprobación de formato incorporada. Crea un campo fuera del documento y no envía ninguna petición:
const field = document.createElement("input");
field.type = "email";
field.required = true;
console.table([
"o'neil@example.com",
"o’neil@example.com",
"o'neil@exam'ple.com",
"o'neil..sales@example.com"
].map(value => {
field.value = value;
return { value, formatAccepted: field.checkValidity() };
}));
Los resultados son true, false, false, true, en ese orden. El último muestra por qué importa la distinción: el navegador acepta puntos consecutivos antes de la @, aunque la gramática SMTP de una parte local sin comillas no los permite. Pasar la comprobación del campo no sustituye la validación del servidor.
Si el primer ejemplo pasa esta prueba, pero falla en tu formulario, revisa las reglas adicionales. Si el formulario lo acepta, compara el valor enviado con el que recibe el servidor. Después comprueba el analizador del servidor y su respuesta de error. El ejemplo de formulario con JavaScript muestra cómo dar indicaciones y mantener una validación independiente en el servidor.
Conserva la dirección al guardarla y volver a usarla
Una vez que el servidor acepte el formato, comprueba que guardar y leer el valor no altera la parte local. o'neil@example.com y oneil@example.com son direcciones introducidas distintas. La aplicación no tiene motivos para tratar la eliminación como una corrección.
Para guardar el valor mediante SQL, pasa la dirección como parámetro al controlador de la base de datos. No la concatenes en la cadena de la consulta. OWASP recomienda consultas parametrizadas para separar los datos de entrada del código SQL. Borrar apóstrofos no sustituye esa separación.
Prueba cada función que lea el dato de contacto guardado. El registro puede funcionar aunque el acceso, la edición del perfil, la exportación o el restablecimiento de contraseña apliquen otro validador. Para preparar un informe reproducible, anota la entrada ficticia, el paso que falla, el error y el valor recuperado tras guardar y volver a cargar. No incluyas direcciones reales de clientes en el informe.
Si un servicio conectado no admite la dirección, explica la limitación y deja que la persona facilite otra. No inventes una alternativa modificando el nombre de su buzón.
Verifica la dirección después de corregir el problema
Envía la dirección sin modificar desde tu servidor a la API de verificación de correo. Así podrás obtener evidencia sobre el dominio y, cuando esté disponible, sobre el destinatario. Mantén las credenciales de la API en el servidor. Emvero conserva la parte local en lugar de borrar sus signos de puntuación.
Un resultado unknown significa que la evidencia disponible no permite llegar a una conclusión; pending indica que la comprobación sigue en curso. Ninguno demuestra un motivo permanente para rechazar la dirección. Si el proceso necesita comprobar que la persona controla el buzón, pídele que lo confirme mediante un enlace o código. La comparación entre verificación y confirmación del correo explica por qué un carácter permitido y un destinatario aceptado todavía dejan esa cuestión abierta.