Correo fake para pruebas: direcciones seguras para formularios de registro
Si creas o pruebas una web, te pasas el día escribiendo direcciones de correo en formularios. Lo único que no puede pasar es que un mensaje de prueba acabe en la bandeja real de un desconocido. Esta página te muestra qué correo fake usar para cada tipo de prueba — y cuándo el mensaje tiene que llegar de verdad.
Primero decide si el correo tiene que llegar
Esta sola pregunta lo decide todo, y vale la pena hacérsela en voz alta, porque la respuesta es «no» más a menudo de lo que se cree.
| Qué estás probando | ¿Tiene que llegar el correo? | Usa |
|---|---|---|
| Validación, almacenamiento o visualización de una dirección | no | un dominio reservado — mira abajo |
| El flujo de confirmación, a mano | sí | un buzón de aquí |
| El flujo de confirmación, automatizado | sí, legible por código | un servicio con API |
| Pruebas de carga o de volumen | no — y no debe | un dominio reservado, siempre |
Cuando el correo no debe llegar: usa nombres reservados
Hay dominios que existen justo para esto y que tienen garantizado no ser nunca de nadie: example.com y sus hermanos example.net y example.org, reservados por el RFC 2606, más toda la terminación .test.
Las direcciones en ellos son la respuesta correcta para datos de ejemplo, semillas y pruebas de carga. Nada de lo que envíes puede llegar a una persona, porque ahí no hay nadie — por acuerdo internacional, no por suerte.
test@mycompanytest.com resulta ser el dominio real de alguien con la frecuencia suficiente como para que importe, y una prueba de carga contra él no se distingue de un ataque. Los nombres reservados no cuestan nada y eliminan toda esa categoría de accidentes.Cuando el correo tiene que llegar, a mano
Coge una dirección de aquí, ejecuta el flujo y lee lo que tu aplicación ha enviado de verdad: cabeceras, enlaces y cómo se ve el mensaje cuando no lo muestra tu propio cliente de correo. Dos cosas que esto detecta y un capturador de correo local no:
- La entrega real. El mensaje recorre un camino de correo real, así que un remitente mal configurado falla aquí y no en producción.
- Cómo lo ve un desconocido. Enlaces que solo funcionan en tu sesión, imágenes que nunca cargan, un enlace para darse de baja que apunta a localhost — todo se ve al momento.
Fíjate también en los avisos de adjuntos si tu aplicación envía archivos: son los mismos avisos que verán tus usuarios.
Cuando tiene que estar automatizado
Raspar la página en su lugar es un mal negocio incluso cuando funciona: es frágil, no está documentado y es justo el tipo de tráfico que acaba bloqueándose.
Probar los caminos de rechazo
Los fallos interesantes no son «una dirección válida funciona». Vale la pena cubrir:
- Una dirección en un dominio sin registro MX: la entrega falla sin que la dirección esté mal escrita. Tu código debería distinguir una cosa de la otra. Comprueba cuál es cuál.
- Un dominio internacional, tanto en Unicode como en la forma
xn--. La mayoría de los validadores rechazan una y aceptan la otra, y casi siempre al revés de lo debido — convertidor. - Las variantes de Gmail con puntos y con más. Si tu control de unicidad compara cadenas tal cual, una persona puede registrar cuentas sin límite. Normaliza primero — esa página hace exactamente lo que debería hacer tu control.
- Una parte local muy larga. El estándar permite 64 caracteres; muchos formularios cortan en silencio a los 20 y guardan algo que ya no lleva a ninguna parte.
Algo que construir, no que probar
Si tu producto no acepta direcciones de correo fake, recházalas con claridad. «Correo no válido» para una dirección perfectamente válida es el error más confuso del género: el usuario revisa la ortografía, la vuelve a escribir y recibe el mismo mensaje. «No aceptamos direcciones de correo fake» ocupa lo mismo y acaba con la confusión.