Saltar al contenido principal

Dominios y remitentes de sandbox

Diferencias con producción​

AspectoProducciónSandbox
DestinatarioMX reales en InternetServicios internos de simulación
ActivaciónCualquier dominio públicoDominio del rcpt es subdominio de sandbox
Reportes / dashboardsDatos del clienteMismos dashboards; se excluyen del conteo por defecto al activar "Solo envíos reales" (parámetro send_types)

Dominios y prefijos de prueba​

Catálogo canónico:.

Resumen rápido:

  • Outcomes a nivel MTA (no llegan al MX): error.sandbox (hard bounce 5.1.1), deferred.sandbox (deferred 25 min, sin reintentos, después rebota), mailcatcher.sandbox (entrega silenciosa, status=sent sin opens).
  • Forward al MX con prefijos genéricos: inbox.sandbox. Los rebotes blandos viven acá, donde hay una respuesta remota que clasificar: mailbox-full.* (mailboxfull), size.* (emailtoolarge), spam.* (spamdetected), rbl.* (blocked) y policy.* (securityerror).
  • Sink de descarte: blackhole.sandbox (el MX lo descarta in-process; termina en sent sin opens ni almacenamiento — el más barato para pruebas de volumen).
  • Forward al MX con DSN específicos por proveedor: hotmail.sandbox. (gmail.sandbox existe y resuelve como proveedor Google, pero hoy usa los DSN genéricos.)

Útiles para validar el mapeo a status codes (5=deferred, 6=bounced soft/hard) y el procesamiento de rebotes asincrónicos (DSN).

Ejemplos de uso en integración​

To: ok.user1@inbox.sandbox          → entrega + apertura + click (autotracker)
To: policy.user2@inbox.sandbox      → rechazo 550 5.7.0 al cierre del DATA → bounced (securityerror)
To: unknown.user3@inbox.sandbox     → hard bounce inmediato (550 user unknown)
To: mailbox-full.user4@hotmail.sandbox → soft bounce (552 mailbox full, mensaje estilo-Hotmail)
To: size.user5@inbox.sandbox        → soft bounce por tamaño (552 5.3.4 → emailtoolarge)
To: ok.user6@blackhole.sandbox      → aceptado y descartado en el MX (sent, sin opens)

Remitente sandbox​

Cada cuenta nueva recibe automáticamente un sender de pruebas pre-verificado:

noreply@<slug>.<dc>.sandbox.test

Donde <slug> es el slug de la instancia (ej. gaia) y <dc> el DC asignado (ej. cl1). Para la instancia dev gaia en cl1, el sender es noreply@gaia.cl1.sandbox.test.

El dominio se publica en una zona DNS interna dedicada con SPF/DMARC mínimos, y queda marcado internamente como sandbox para poder filtrar reportes y aplicar retention reducida (ver).

Ejemplo end-to-end (sandbox + sandbox)​

swaks --to alice@inbox.sandbox \
      --from noreply@gaia.cl1.sandbox.test \
      --server cl1relay.fdz.tk:587 \
      --tls --auth -au "<smtp-user>" -ap "<smtp-pass>" \
      --header "Subject: Hola desde sandbox"

Anti-leak: sender sandbox solo a destinatario sandbox​

Si el sender es sandbox (<...>.sandbox.test), el destinatario debe ser también sandbox (*.sandbox). Cualquier mezcla con un destinatario real se rechaza:

API (POST /v1/mails/send)SMTP relay
HTTP 409 Conflict con mensaje "Sandbox sender cannot relay to non-sandbox recipients"Rechazo en RCPT TO con 550 5.7.1 Sandbox sender cannot relay to non-sandbox recipients

Es defensa en profundidad: el chequeo en la API pública da error sincrónico al integrador; el chequeo en el relay SMTP cubre el path SMTP directo. La regla es one-way — un sender real sí puede enviar a *.sandbox y se simula igual que cualquier otro destino sandbox, pero esos envíos no quedan marcados como sandbox para reportes.

Filtrado en reportes​

Los envíos sandbox conviven con los reales en el registro interno de correos. Para excluirlos, use el parámetro send_types=real en la API de reportes (ver Diferencias con producción) en vez de intentar distinguirlos por su propia cuenta — el marcado de qué es sandbox es interno a la plataforma.

En esta página