SES Sandbox Mode: Por qué solo puedes enviarte emails a ti mismo y cómo salir de él

Acabas de integrar Amazon SES en tu aplicación, las pruebas internas funcionan perfectamente, pero en el momento en que intentas enviar un email de bienvenida a un cliente real, el mensaje rebota o simplemente no llega. El diagnóstico es casi siempre el mismo: tu cuenta SES está en Sandbox mode y nadie te avisó de que necesitas solicitar acceso a producción antes de poder enviar emails a direcciones no verificadas.

TL;DR — Resumen rápido del Sandbox de SES

AspectoSandbox (por defecto)Producción (tras aprobación)
Destinatarios permitidosSolo direcciones o dominios verificados en SESCualquier dirección de email válida
Límite de envío diario200 emails/díaSegún el límite aprobado en tu solicitud
Tasa de envío máxima1 email/segundoSegún el límite aprobado
Remitentes permitidosSolo identidades verificadas (email o dominio)Solo identidades verificadas (igual)
Cómo salirSolicitud de acceso a producción en la consola—

Los límites exactos de cuotas pueden cambiar — consulta siempre la documentación oficial de AWS.

Cómo funciona el Sandbox de Amazon SES

Cuando AWS activa SES en una cuenta nueva, la coloca automáticamente en modo Sandbox. No es un error de configuración ni una penalización — es una medida de protección de la infraestructura de email de AWS para evitar que cuentas nuevas, potencialmente comprometidas o mal configuradas, generen spam masivo desde el primer día.

La restricción central es esta: en Sandbox, SES solo acepta envíos hacia direcciones o dominios que hayas verificado explícitamente en tu cuenta. Puedes enviarte emails a ti mismo porque tu propia dirección está verificada. Tus clientes no están verificados, por eso sus mensajes fallan.

El remitente también debe ser una identidad verificada, pero eso aplica igual en producción. La diferencia real está en el destinatario.

graph TD A["Aplicación llama
a SES API"] --> B{"¿Remitente
verificado?"} B -- No --> C["Rechazo inmediato
de la API"] B -- Sí --> D{"¿Cuenta en
Sandbox?"} D -- No --> G["Email enviado
a cualquier destinatario"] D -- Sí --> E{"¿Destinatario
verificado?"} E -- No --> F["Mensaje descartado
sin error HTTP"] E -- Sí --> G
  1. Sandbox activo: SES evalúa cada envío. Si el destinatario no está en la lista de identidades verificadas de tu cuenta, el mensaje es rechazado.
  2. Verificación de identidad: Puedes verificar direcciones individuales o dominios completos. Un dominio verificado cubre todas sus direcciones.
  3. Producción: Una vez aprobada la solicitud, SES elimina la restricción de destinatarios verificados y eleva tus cuotas de envío.

Por qué el Sandbox atrapa a tantos equipos en producción

El error más común no es técnico — es de proceso. El flujo habitual es: un desarrollador integra SES, verifica su propia dirección, prueba con éxito, hace el deploy, y nadie solicita el acceso a producción porque las pruebas funcionaban. El problema aparece cuando el primer usuario real intenta recibir un email de confirmación de cuenta.

Piénsalo como un número de teléfono nuevo en una lista blanca corporativa. Puedes llamar a los números que ya están en la lista, pero cualquier número externo queda bloqueado hasta que alguien actualice los permisos.

El síntoma observable suele ser silencioso: SES acepta el mensaje en la API (devuelve un MessageId), pero el email nunca llega al destinatario. No hay un error HTTP 4xx que alerte al desarrollador. Para confirmar el rechazo, necesitas revisar los eventos de entrega en CloudWatch o en el SNS topic configurado para notificaciones de SES.

Diagnóstico: confirmar que estás en Sandbox

Antes de abrir la solicitud de producción, confirma el estado actual de tu cuenta. Hay dos formas directas.

Opción 1 — Consola de AWS

En la consola de SES, navega a Account dashboard. El panel muestra explícitamente si tu cuenta está en Sandbox o en producción, junto con tus cuotas actuales de envío.

Opción 2 — AWS CLI

aws ses get-send-quota --region us-east-1

Este comando devuelve Max24HourSend, MaxSendRate y SentLast24Hours. Si Max24HourSend es 200, estás en Sandbox. Ese valor es el indicador más fiable del estado de la cuenta sin necesidad de navegar por la consola.

Para verificar qué identidades tienes actualmente verificadas:

aws ses list-identities --identity-type EmailAddress --region us-east-1
aws ses list-identities --identity-type Domain --region us-east-1

Cómo solicitar acceso a producción en SES

La solicitud se gestiona a través de un caso de soporte en AWS. No existe un botón de 'activar producción' — AWS revisa manualmente cada solicitud para evaluar el caso de uso.

graph LR A["Abrir solicitud
en consola SES"] --> B["AWS revisa
el caso de uso"] B --> C{"¿Información
suficiente?"} C -- No --> D["AWS pide
aclaraciones"] D --> B C -- Sí --> E{"¿Caso de uso
aprobado?"} E -- No --> F["Solicitud denegada
con motivo"] E -- Sí --> G["Cuenta movida
a producción"] G --> H["Cuotas elevadas
según solicitud"]

Paso 1 — Preparar la información antes de abrir el caso

AWS pedirá detalles específicos. Tenerlos preparados reduce el tiempo de resolución significativamente. Necesitas documentar:

  • Tipo de email: transaccional (confirmaciones, recuperación de contraseña, notificaciones de sistema) o marketing (newsletters, promociones).
  • Proceso de opt-in: cómo obtuviste el consentimiento de tus destinatarios. Para emails transaccionales, el registro en la plataforma suele ser suficiente. Para marketing, necesitas demostrar opt-in explícito.
  • Gestión de rebotes y quejas: cómo procesas las notificaciones de bounce y complaint. AWS espera que tengas configurado SNS para recibir estos eventos y que elimines automáticamente las direcciones que generan hard bounces.
  • Volumen estimado: emails por día en el corto plazo y proyección a 6 meses.
  • Límite solicitado: el número de emails por día que necesitas.

Paso 2 — Abrir el caso de soporte desde la consola SES

La ruta más directa es desde el propio dashboard de SES:

  1. En la consola de SES, ve a Account dashboard.
  2. Haz clic en Request production access.
  3. Completa el formulario con el tipo de email, descripción del caso de uso, volumen estimado y confirmación de que gestionas rebotes y quejas.
  4. Envía la solicitud.

Esto abre automáticamente un caso en AWS Support con la categoría correcta. No necesitas el plan de soporte Business o Enterprise — cualquier cuenta puede enviar esta solicitud.

Paso 3 — Responder con precisión si AWS pide aclaraciones

AWS puede responder pidiendo más detalles sobre el proceso de opt-in o sobre cómo manejas los rebotes. Una respuesta vaga como 'enviamos emails transaccionales' suele generar una segunda ronda de preguntas. Sé específico: describe el flujo exacto del usuario, el mecanismo de consentimiento y el sistema de supresión de rebotes.

El tiempo de respuesta de AWS varía — generalmente entre 24 y 48 horas para la primera respuesta, pero puede extenderse si el caso requiere revisión adicional.

Configurar la gestión de rebotes y quejas antes del acceso a producción

Este es el punto donde más solicitudes se complican o se rechazan. AWS no aprueba cuentas que no demuestren un mecanismo de gestión de rebotes. Y tiene sentido: una tasa de rebotes alta daña la reputación del pool de IPs compartido que usan otras cuentas de SES.

La configuración mínima requerida en la práctica implica:

1 — Crear un SNS topic para notificaciones de SES

aws sns create-topic --name ses-bounce-complaints --region us-east-1

2 — Configurar SES para enviar notificaciones de bounce y complaint al topic

aws ses set-identity-notification-topic \
  --identity tu-dominio.com \
  --notification-type Bounce \
  --sns-topic arn:aws:sns:us-east-1:123456789012:ses-bounce-complaints \
  --region us-east-1

aws ses set-identity-notification-topic \
  --identity tu-dominio.com \
  --notification-type Complaint \
  --sns-topic arn:aws:sns:us-east-1:123456789012:ses-bounce-complaints \
  --region us-east-1

3 — Verificar que las notificaciones están activas

aws ses get-identity-notification-attributes \
  --identities tu-dominio.com \
  --region us-east-1

La respuesta debe mostrar los ARNs de SNS configurados para BounceTopic y ComplaintTopic. Si aparecen vacíos, las notificaciones no están activas.

Con SNS configurado, puedes suscribir una función Lambda o un endpoint HTTP para procesar los eventos y actualizar tu lista de supresión interna. SES también ofrece una lista de supresión a nivel de cuenta que puedes gestionar directamente.

El error de diagnóstico que cuesta más tiempo

Hay un patrón que aparece repetidamente: el equipo configura SES, verifica el dominio, envía emails de prueba exitosamente, y asume que está en producción. Semanas después, un cliente reporta que nunca recibió el email de activación de su cuenta.

Al revisar los logs de la aplicación, todo parece correcto — la llamada a la API de SES devolvió un MessageId válido. El error no está en la aplicación. Está en que SES aceptó el mensaje en la API pero lo descartó silenciosamente porque el destinatario no era una identidad verificada en la cuenta Sandbox.

La corrección no es un cambio de código. Es abrir el caso de soporte y esperar la aprobación. Mientras tanto, la solución temporal para no bloquear el desarrollo es verificar manualmente las direcciones de los testers en SES.

Para verificar una dirección individual durante el período de espera:

aws ses verify-email-identity \
  --email-address tester@ejemplo.com \
  --region us-east-1

El destinatario recibirá un email de verificación de AWS. Una vez que haga clic en el enlace, esa dirección queda habilitada como destinatario en tu cuenta Sandbox.

IAM: permisos mínimos para operar con SES

Si tu aplicación llama a SES desde un rol de IAM (EC2, Lambda, ECS), necesitas al menos los siguientes permisos para enviar emails y gestionar identidades:

🔽 Ver política IAM mínima para SES 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SESEnvioEmails",
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "arn:aws:ses:us-east-1:123456789012:identity/tu-dominio.com"
    },
    {
      "Sid": "SESConsultaCuotas",
      "Effect": "Allow",
      "Action": [
        "ses:GetSendQuota",
        "ses:GetSendStatistics"
      ],
      "Resource": "*"
    }
  ]
}

GetSendQuota y GetSendStatistics requieren Resource: * — no admiten restricción a nivel de recurso específico según la Service Authorization Reference de AWS.

Próximos pasos y recursos

Una vez aprobado el acceso a producción, el trabajo no termina. La reputación del remitente en SES es acumulativa — una tasa de rebotes o quejas elevada puede llevar a AWS a pausar tu capacidad de envío. Monitoriza las métricas de reputación en el dashboard de SES regularmente.

  • Configura alarmas en CloudWatch para las métricas de reputación de SES (Reputation.BounceRate y Reputation.ComplaintRate).
  • Considera usar Configuration Sets para tener visibilidad granular por tipo de email.
  • Si envías alto volumen, evalúa solicitar IPs dedicadas para aislar tu reputación.
  • Documentación oficial: Solicitar acceso a producción en SES.

Glosario de términos clave del Sandbox de SES

TérminoDefinición
Sandbox modeEstado inicial de toda cuenta SES que restringe el envío a identidades verificadas únicamente.
Identidad verificadaDirección de email o dominio que ha completado el proceso de verificación en SES (DNS o email de confirmación).
Hard bounceFallo permanente de entrega — la dirección no existe o está bloqueada. Debe eliminarse de la lista de envío inmediatamente.
ComplaintEl destinatario marcó el email como spam. AWS recibe esta señal de los ISPs participantes y la reenvía vía SNS.
Sending quotaLímite de emails que puedes enviar en un período de 24 horas, definido por AWS según el estado de tu cuenta.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más