Cuentas de prueba ilimitadas en un dominio catch-all

Por qué un proveedor de correo tiene la forma equivocada para QA

Se ha probado cada forma de darle direcciones de correo a una batería de pruebas, y cada una tiene una fuga en un sitio distinto:

La cuarta fila es esta guía. Es el mismo mecanismo sobre el que funcionan los dominios públicos desechables — un servidor que acepta cualquier dirección de un dominio en lugar de una lista de buzones — aplicado a un nombre que nadie más que tú está usando.

El único registro DNS

En tu proveedor de DNS, añade un único registro MX en la raíz de un dominio que poseas. Ningún otro registro aquí, ningún TXT que demuestre nada, ninguna cuenta en este sitio:

Registro MX para el dominio10 smtp.grabmail.ioCopiar

1. Publica el MX. Prioridad 10, apuntando a smtp.grabmail.io. Elimina cualquier otro MX del dominio — el correo solo se puede entregar en un sitio, y un registro que se quede por ahí envía parte de él a otro lugar.
2. Espera al DNS. Normalmente minutos; en ocasiones el TTL de lo que hubiera antes. dig MX qa-example.com muestra cuándo ha hecho efecto.
3. Envía un mensaje a cualquier dirección de ese dominio. La primera entrega es lo que conecta el dominio: el servidor consulta el MX en ese momento, se ve a sí mismo, y acepta. A partir de ahí, cada dirección del dominio es un buzón.

Un esquema de nombres que dice quién creó el buzón

Con toda dirección siendo válida, la parte local queda libre para llevar información — y a las dos de la madrugada, con una ejecución fallida y un buzón abierto, vas a querer que la lleve. Tres partes, unidas por guiones, en este orden:

// one helper, every runner: who made it, which run, and eight random characters
export const testAddress = (who: string, run = process.env.GITHUB_RUN_ID ?? 'local') =>
  `${who}-${run}-${crypto.randomUUID().slice(0, 8)}@qa-example.com`;

testAddress('signup');        // signup-1234567890-3f9a1c2e@qa-example.com

Leer cualquier dirección, las mismas tres llamadas

Nada de la API cambia para tu propio dominio. La misma llamada de listado, la misma llamada de mensaje, el mismo borrado — sin clave en el nivel público, y el dominio de la dirección es lo único que cambia:

$ curl -sG https://grabmail.io/api/v1/mailbox --data-urlencode "address=signup-1234567890-3f9a1c2e@qa-example.com"

Lo que significa que todo ayudante de este sitio funciona sin cambios tras editar una constante: el fixture de Playwright, la tarea de Cypress, los módulos de Python y Node. Vale la pena saber tres cosas en las que los dominios públicos no te hacen pensar:

Un 404 significa que el MX todavía no está ahí

El listado responde 404 para un dominio que no está alojado aquí. En tu propio dominio eso es un problema de DNS — el registro no se ha propagado, o apunta a otro sitio — no un problema de la API. dig MX primero.

El alias también funciona en tu dominio

Todo buzón, en cualquier dominio, tiene una segunda dirección en un dominio distinto que entrega en él y que no puede leerlo. Dásela a un sitio cuando prefieras que no pueda abrir el buzón; consulta tú tu propia dirección.

Una dirección con mucho tráfico se pagina

Una dirección catch-all que recoge rebotes o un día de notificaciones puede contener más de una página de 200. Pasa next de vuelta como before hasta que sea null.

Mantener un dominio de pruebas utilizable

Un dominio propio no está en ninguna lista de bloqueo de correo desechable, que suele ser la razón misma para usar uno: la aplicación bajo prueba rechaza grabmail.io y cualquier otro dominio público, exactamente como debería. Cuatro hábitos mantienen esa situación:

• Usa un dominio dedicado — qa-example.com, no un subdominio de producción ni el dominio al que escriben los clientes. El servicio solo acepta dominios registrables (example.com, nunca mail.example.com), y un dominio de pruebas no debería tener ningún otro trabajo.
• No lo publiques. Las listas se construyen a partir de lo que aparece en sitios públicos de correo temporal y en volcados de direcciones compartidos. Un dominio que solo aparece en tu propia batería de pruebas no tiene forma de llegar a ellas.
• Ciérralo con SPF y DMARC. Un dominio de solo recepción sin SPF es un dominio desde el que cualquiera puede suplantar correo; dos registros cierran eso, y no cuestan nada.
• No apuntes correo real hacia él. En el momento en que un sistema de staging envía notificaciones de clientes a una dirección catch-all, un buzón público pasa a contener datos de clientes. Los dominios de pruebas llevan correo de pruebas.

Si la aplicación rechaza todos los dominios catch-all — algunas comprobaciones antifraude lo hacen, sondeando si se acepta una dirección aleatoria del dominio — hay un fondo de pago de dominios .com de aspecto normal que se mantienen fuera de las listas, descrito en la página de precios. Por qué los formularios de registro bloquean el correo desechable explica qué ve cada tipo de comprobación.

Para un equipo: un dominio, muchos testers, muchos pipelines

Un solo dominio catch-all sirve a todo el mundo, porque la parte local es lo único que tiene que ser distinto y es gratis. Lo que necesita un equipo es acordar el esquema de nombres de arriba y tres pequeñas convenciones:

Un prefijo por pipeline y por persona

e2e-, nightly-, alice-. Buscar el prefijo en un log de job encuentra todos los buzones que creó; buscar el de un compañero encuentra el bug que está mirando.

Nada compartido, nunca

No hay ningún «buzón de equipo» en el dominio ni ningún fixture que reparta una dirección fija. Si dos personas necesitan el mismo buzón, una de ellas le manda la dirección a la otra.

Los límites de solicitudes son por cliente

Una lectura por segundo por dirección, 1200 solicitudes por minuto por cliente — un ejecutor de CI es un cliente, un portátil es otro. Un equipo de diez ejecutando baterías de pruebas a la vez son diez clientes, no uno.

Los límites que se aplican

Tu propio dominio recibe el mismo servicio que los públicos, con los mismos límites. Ninguno de ellos es ajustable, y ninguno es un problema para una batería de pruebas:

Antes de darlo por terminado

• Un dominio registrable dedicado, con un registro MX: 10 smtp.grabmail.io, y ningún otro MX.
• Un mensaje enviado a cualquier dirección de ese dominio, y leído de vuelta a través de la API.
• SPF y DMARC publicados, para que nadie pueda enviar en nombre de el dominio.
• Un ayudante de nombres — quién, qué ejecución, ocho caracteres aleatorios — usado por todas las baterías de pruebas.
• El dominio guardado en la configuración del entorno, nunca en el código, en capturas de pantalla o en tickets.
• Nada que envíe correo real de clientes apuntado hacia él.

A partir de aquí, las baterías de pruebas son las que ya están escritas: Playwright con el dominio en su fixture, la disciplina independiente del ejecutor, y el workflow de GitHub Actions con el dominio en una variable.

Preguntas