Generador de emails falsos

Por qué existen los dominios .example

La IANA (Internet Assigned Numbers Authority) reserva los dominios example.com, example.net y example.org en la RFC 2606 específicamente para usar en documentación, ejemplos y casos donde no se quiere apuntar a un dominio real. Eso garantiza dos cosas: nadie puede registrarlos (no van a aparecer apuntando a otro sitio), y los servidores de email los rechazan automáticamente.

Lo mismo aplica a TLDs reservados como .test, .invalid, .localhost y .local: ninguno resuelve en internet pública, son seguros para datos sintéticos.

Diferencia con emails temporales reales

Un email temporal real (Mailinator, 10minutemail, Tempmail) es una bandeja de entrada pública: cualquiera puede ver los mensajes que llegan. Sirven para registrarse en servicios sin dar tu email real, pero no para testing automatizado: no controlás el timing de la entrega y no son privados.

Los emails generados acá son distintos: no reciben nada. Son cadenas con formato válido pero sin bandeja detrás. Si tu test envía correo a uno de estos, rebota. Eso es lo que querés en CI/CD: ningún sistema externo se ve afectado por tu suite de tests.

Cuándo usar cada estilo de email local

• Basado en nombre (juan.perez@example.com): cuando querés que el email "se vea" como real, asociado a un nombre. Útil para demos y screenshots.
• Aleatorio (kx7p2qm9@example.com): cuando solo necesitás unicidad y volumen. Útil para fixtures que prueban listas largas.
• user1, user2…: cuando importa el orden y la trazabilidad. Útil para tests donde tenés que referirte a "el cuarto usuario" sin ambigüedad.

Errores comunes con datos de email en testing

1. Usar tu email real. Si una corrida de tests salta un guard y manda correos, llenás tu inbox o, peor, le mandás spam a un compañero.
2. Usar dominios que parecen falsos pero son reales. fake.com, nope.com y muchos otros son dominios registrados. Quedate con example.com.
3. Hardcodear un solo email para todo. Si todos los usuarios de tests tienen el mismo email, no detectás bugs de unicidad en la base.
4. No marcar los emails como sintéticos. Un flag is_test_data en la base te permite limpiar después.

Buenas prácticas para envío en entornos no productivos

Aún con emails sintéticos, conviene blindarse contra envíos accidentales:

• En desarrollo y staging, configurá un mail catcher (MailHog, Mailtrap, mailpit). Captura todo lo que el sistema "envía" sin que llegue a nadie.
• Whiteliste solo emails internos al sistema de envío fuera de producción.
• Implementá un kill switch: una variable de entorno que apaga el envío real en cualquier ambiente que no sea producción.
• Logueá todo intento de envío para detectar fugas.

Validación de email a tener en cuenta

Tu generador da emails con formato válido (nombre@dominio.tld). Distintas librerías validan distinto:

• Regex simple (HTML5, frontend): los acepta sin problema.
• RFC 5321 estricto: los acepta.
• Validación con DNS/MX lookup: example.com tiene MX (apunta a sí mismo), pero la dirección concreta no existe. Algunas librerías van a rechazarlos.
• Validación SMTP: rebota.

Para tests donde necesites un email "que pase validación profunda", usá un email real descartable. Para todo lo demás, estos sintéticos alcanzan.