Saltar al contenido principal

Dominios y remitentes de sandbox

Para desarrolladores

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: [email protected]          → entrega + apertura + click (autotracker)
To: [email protected]      → rechazo 550 5.7.0 al cierre del DATA → bounced (securityerror)
To: [email protected]     → hard bounce inmediato (550 user unknown)
To: [email protected] → soft bounce (552 mailbox full, mensaje estilo-Hotmail)
To: [email protected]        → soft bounce por tamaño (552 5.3.4 → emailtoolarge)
To: [email protected]      → 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 su instancia y <dc> el código del centro de datos asignado a su cuenta. Para una instancia acme en cl2, el remitente es [email protected]. El valor exacto aparece en el listado de remitentes de su cuenta, ya verificado — no hay que darlo de alta.

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.

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

swaks --to [email protected] \
      --from [email protected] \
      --server cl2relay.fidelizador.com: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