El simulador de buzones de Amazon SES comprueba cómo procesa tu aplicación determinados eventos de envío. No muestra si Gmail, Outlook u otro proveedor colocará el correo en la bandeja de entrada. Para observarlo, envía un mensaje original por tu ruta real de SES a las direcciones de LDM. Mantén separadas la simulación y la prueba con buzones externos: responden a preguntas distintas.
Una aplicación puede superar la simulación mientras una copia real termina en Spam. También puede faltar un mensaje que nunca salió de la aplicación. Distingue el contenido generado, el intento de envío y la carpeta observada. Este procedimiento describe una prueba que tú controlas; no presenta resultados experimentales ni una integración nativa entre SES y LDM.
El transporte, la carpeta y la interacción son observaciones distintas.
Qué demuestra el simulador
AWS proporciona destinatarios para simular entrega correcta, rebote, queja y respuesta automática. Por ejemplo, success@simulator.amazonses.com reproduce el escenario de entrega correcta. Debes enviar a estas direcciones mediante SES, según la documentación del simulador.
Úsalo para revisar tu aplicación: ¿recibe el evento?, ¿lo relaciona con el trabajo adecuado?, ¿ejecuta la acción prevista ante un rebote? Son comprobaciones útiles, pero una respuesta predefinida no constituye una observación de carpeta en un buzón externo.
Registra «gestor de rebotes verificado» con su escenario. Registra «copia encontrada en Inbox» con el buzón y la hora correspondientes. Una etiqueta única de «entregado» ocultaría la diferencia entre ambos resultados.
Comprueba primero el sandbox de la cuenta
El sandbox de la cuenta y el simulador son conceptos diferentes. AWS establece que el estado de sandbox es específico de cada región. Dentro del sandbox, los destinatarios deben ser direcciones o dominios verificados, salvo los del simulador. El acceso a producción elimina esa restricción de destinatarios, pero conserva los requisitos de identidad del remitente. Consulta Request production access.
Una dirección de LDM es un destinatario externo, no una dirección del simulador. Añadirla al campo de destinatario no autoriza por sí solo el envío. Revisa la región y los permisos de la cuenta. Si la restricción impide la prueba legítima, sigue el procedimiento admitido por AWS para obtener acceso a producción; no intentes eludir la verificación.
Prepara una prueba representativa
Esta guía está en español. La interfaz de LDM también está disponible en español.
1. Define el mensaje y la pregunta
Elige un recibo, una notificación de cuenta o un boletín para suscriptores. «¿Dónde aparece este recibo enviado por nuestra ruta actual?» es una pregunta concreta. «¿Es bueno SES?» resulta demasiado amplia para un pequeño panel.
Prepara datos realistas sin información confidencial. Conserva asunto, HTML, alternativa de texto, enlaces y comportamiento de adjuntos. Mantén los mecanismos de baja obligatorios para ese tipo de comunicación.
2. Anota la ruta utilizada
Registra la región de AWS, identidad de envío, entorno y presentación mediante SMTP o API. Añade las opciones de configuración y enrutamiento que realmente utiliza la aplicación, junto con la versión de plantilla y el seguimiento.
Un mensaje manual desde la consola puede ser útil, pero no reproduce automáticamente el renderizado y la cola de tu aplicación. Indica qué parte del proceso intervino para no atribuir el resultado a una ruta que no probaste.
3. Separa las pruebas de eventos
Ejecuta los escenarios del simulador necesarios y examina el comportamiento de la aplicación. Identifica esos registros como simulaciones. No combines direcciones del simulador y de LDM en una misma valoración de placement.
Después prepara un trabajo real, independiente y limitado. Deja fuera las tareas habituales de desarrollo y las campañas programadas. Define cuándo termina el trabajo para evitar envíos posteriores involuntarios.
4. Obtén los destinatarios actuales de LDM
Inicia una prueba con el remitente real en Inbox Placement by LDM. Utiliza las direcciones proporcionadas para esa prueba e interpreta el informe mediante la metodología de LDM.
Trata el conjunto como temporal. No lo añadas a listas permanentes, actividades de calentamiento ni automatizaciones recurrentes. Confirma que tu cuenta y el flujo elegido permiten ese envío externo.
5. Envía un original nuevo
Haz que la aplicación genere el mensaje directamente para esos destinatarios. No reenvíes una copia desde tu buzón personal: añadirías otra ruta y otro contexto.
Usa la lógica normal de renderizado y presentación, sustituyendo deliberadamente los destinatarios por el conjunto de prueba. Conserva cabeceras y bajas necesarias. Guarda la referencia del trabajo, resultado de presentación, horas e identificadores disponibles. Detén el trabajo cuando haya realizado los envíos previstos.
6. Relaciona los registros con las carpetas
Antes de interpretar una copia ausente, revisa el registro del remitente. Un error de presentación, un problema posterior de entrega y un buzón que no pudo consultarse requieren investigaciones distintas.
En LDM, un resultado ausente o desconocido no significa Spam. Promotions y categorías similares son ubicaciones recibidas, diferentes de Inbox principal y Spam. La observación de 24 horas sigue la misma copia; no vuelve a enviar el mensaje en cada punto. Conserva carpeta y hora juntas.
Un ejemplo hipotético
Un equipo verifica un recibo. El simulador confirma que la aplicación procesa una notificación de entrega correcta. Una prueba real posterior utiliza seis buzones externos: tres copias aparecen en Inbox principal, una en Promotions, una en Spam y otra no se encuentra.
Son cifras hipotéticas, no un resultado de SES. Se recibieron cinco copias. La proporción de Inbox principal es tres entre cinco, un 60%; la cobertura es de cinco copias recibidas entre seis destinos. Informar únicamente «60% de entregabilidad» ocultaría el denominador y la observación ausente.
Investiga la copia no encontrada con los datos de envío. Examina por separado la copia en Spam y su autenticación disponible. Ninguna de las dos situaciones justifica reescribir inmediatamente todo el contenido.
Límites de la conclusión
Un panel pequeño no representa el historial, las reglas ni las futuras acciones de cada cliente. Tampoco demuestra que una palabra, un enlace o SES hayan causado la ubicación. Autenticación y carpeta son evidencias distintas.
Para repetir la prueba, guarda la referencia y cambia una variable relevante cuando sea posible. El resultado de un mensaje nuevo pertenece a otro envío; una observación posterior del original pertenece a su historial existente.
Preguntas frecuentes
¿Una simulación correcta demuestra que llegué a Inbox de Gmail?
No. Confirma el escenario simulado. Para describir una carpeta de Gmail necesitas un mensaje externo real y la observación correspondiente.
¿Puedo usar LDM con SES en sandbox?
Solo si los destinatarios cumplen las restricciones aplicables. Las direcciones normales de LDM no son del simulador. Revisa el estado de la cuenta en la región utilizada.
¿Debo enviar desde la consola o desde la aplicación?
Usa la ruta que responde a tu pregunta. Para un recibo generado por la aplicación, ejecuta su renderizado y envío reales. Identifica por separado cualquier prueba exclusiva de consola.
¿Conviene quitar seguimiento o enlaces de baja?
Conserva un primer mensaje representativo y las bajas obligatorias. Una modificación del seguimiento opcional puede probarse aparte; una mejora aislada no demuestra una causa universal.
¿Cómo describo un resultado que cambia después?
Informa de la secuencia confirmada y sus horas. No supongas una carpeta constante entre consultas ni interpretes un error posterior como prueba de la ubicación actual.
Observa la ruta real
Crea una prueba en LDM después de confirmar que SES permite el envío. Conserva juntos los resultados del simulador, registros del remitente y observaciones de buzones, sin confundir su significado.