Mailtrap Email Sandbox captura mensajes para inspeccionarlos durante el desarrollo; Email API/SMTP realiza envíos a destinatarios externos. Una dirección de prueba en el To de una captura no demuestra que ese buzón recibió el correo. Para observar placement con LDM, genera un original por tu ruta real y evalúa sus carpetas por separado de las vistas previas y el análisis de Sandbox.
Ambas etapas son útiles. Sandbox puede revelar una plantilla defectuosa antes de contactar con un destinatario externo. La prueba de placement examina una copia después de recorrer el sistema de envío. Sustituir una comprobación por la otra deja parte del proceso sin observar. Esta guía no afirma una integración nativa con LDM ni cambios automáticos en tu cuenta.
El transporte, la carpeta y la interacción son observaciones distintas.
Para qué sirve Email Sandbox
Mailtrap describe Sandbox como un entorno que captura mensajes para inspección. Ofrece vistas de HTML y texto, revisión de cabeceras y adjuntos, y análisis de spam score. Consulta el resumen oficial de Email Sandbox.
Úsalo para revisar lo construido por la aplicación. ¿Se sustituyeron las variables? ¿El asunto corresponde al evento? ¿La alternativa de texto conserva la información esencial? ¿Aparecen las cabeceras y los archivos previstos? Estas preguntas no requieren observar la carpeta de un destinatario externo.
Una captura acredita la recepción en Sandbox. La dirección mostrada forma parte del mensaje inspeccionado; no es un comprobante de entrega externa. Tampoco una valoración favorable del analizador establece la carpeta que elegirá un proveedor real.
El envío real necesita otra configuración
La guía Email API/SMTP documenta la entrega real y exige un dominio de envío verificado. Completa la configuración y los requisitos de aprobación aplicables a tu cuenta antes del experimento externo. Mientras tanto, continúa las comprobaciones admitidas por Sandbox.
Importa el destino de la presentación. El resumen de Sandbox identifica sandbox.smtp.mailtrap.io para SMTP de pruebas. En API distingue el endpoint de Sandbox del transactional, https://send.api.mailtrap.io/api/send, y del bulk, https://bulk.api.mailtrap.io/api/send.
Cambiar únicamente el destinatario no realiza esa transición. En SMTP, revisa host y credenciales efectivos. En un SDK, consulta la configuración sandbox de la biblioteca instalada. En API, comprueba el endpoint. La ruta real elegida debe corresponder al mensaje que quieres evaluar.
Esta guía está en español. La interfaz de LDM también está disponible en español.
Procedimiento paso a paso
1. Establece una referencia en Sandbox
Activa el evento correspondiente con datos realistas y no confidenciales. Inspecciona el original capturado y resuelve defectos evidentes de renderizado o personalización. Registra revisión de plantilla y versión de aplicación para conservar la misma generación del contenido.
Mantén asunto, HTML, alternativa de texto, adjuntos y enlaces habituales. Conserva las bajas y cabeceras obligatorias para la comunicación. Quitarlas haría el espécimen menos representativo de lo que recibirá el usuario.
2. Delimita el experimento real
Elige una pregunta concreta: «¿Dónde aparece este recibo final mediante nuestra ruta transactional?» Anota remitente, camino previsto y versión de plantilla.
Crea un trabajo finito que solo pueda enviar a los destinatarios de prueba. Mantén el tráfico normal de staging en Sandbox. Un experimento controlado no requiere trasladar todos los eventos de desarrollo a un sistema de entrega externa.
3. Confirma la disponibilidad de la ruta
Revisa la configuración de envío real y el estado del dominio previsto. Usa los ajustes de esa cuenta; no reutilices credenciales de Sandbox ni copies un ejemplo genérico sin comprobarlo.
Registra si la aplicación utiliza SMTP, API directa o SDK. Conserva renderizado y cabeceras relevantes. Excluye contraseñas y tokens de capturas, configuraciones guardadas e informes. Necesitas información reproducible, no secretos de acceso.
4. Obtén las direcciones actuales de LDM
Crea una prueba en Inbox Placement by LDM con el remitente real. Utiliza sus destinatarios para este experimento limitado, siguiendo el procedimiento permitido por la plataforma.
No añadas los seeds a calentamiento, audiencias permanentes o eventos recurrentes. Si creas registros temporales, evita que activen mensajes posteriores ajenos a la prueba. Mantén las restricciones existentes de destinatarios en vez de eludirlas para producir una medición.
5. Genera y presenta un original nuevo
Haz que la aplicación renderice y envíe directamente por la ruta real prevista. No reenvíes la captura de Sandbox ni una copia recibida por un empleado. El reenvío introduce otro contexto y puede utilizar otro camino; no reproduce la presentación original de la aplicación.
Guarda resultado, hora, referencia disponible del mensaje e identificador del trabajo. Revisa los eventos del envío real antes de concluir que una copia ausente llegó al sistema del destinatario.
6. Interpreta la observación
Sigue la metodología de LDM. Ausente o desconocido no significa Spam. Promotions y otras categorías describen ubicaciones recibidas y deben distinguirse de Inbox principal y Spam.
La observación de 24 horas sigue la misma copia; LDM no vuelve a enviarla en cada punto. Conserva carpeta y hora juntas. Una nueva versión enviada después constituye otro experimento, no una observación adicional del original.
Ejemplo hipotético: confundir captura con entrega
Un desarrollador añade destinatarios de LDM a los datos de prueba de un recibo. El mensaje aparece en Sandbox, se ve correctamente y supera las comprobaciones del equipo. Como LDM no confirma ninguna copia, alguien propone cambiar el dominio.
En este ejemplo hipotético, la aplicación todavía utiliza el host SMTP de Sandbox. La captura acredita una presentación de desarrollo, no entrega externa. Aún no hay evidencia de que el filtro del destinatario haya evaluado ese mensaje.
El desarrollador mantiene aislado staging y prepara un trabajo independiente con destinatarios limitados por la ruta real verificada. Supongamos que aparecen Inbox principal, una categoría secundaria y una observación desconocida. Conserva los tres resultados: desconocido no se convierte en Spam y una categoría secundaria no equivale a rechazo.
Qué comparar después
Relaciona la captura de Sandbox y el envío real con la misma revisión de plantilla. Si el mensaje difiere, identifica dónde cambió: datos, secciones condicionales, enlaces, cabeceras o ruta. Esa investigación aporta una pregunta más concreta que editar repetidamente el asunto sin una hipótesis.
Para el siguiente experimento, conserva la referencia y documenta una modificación. Cambia una variable relevante cuando sea posible. Si una actualización sustituye varios componentes, describe el resultado como prueba de la nueva configuración, no como evidencia aislada sobre uno de ellos.
Incluso un panel completamente observado no predice las reglas ni el comportamiento futuro de cada cliente. El informe describe copias concretas, cobertura y horas; no garantiza la próxima campaña.
Preguntas frecuentes
¿Basta con poner los seeds en un mensaje de Sandbox?
No. El campo de destinatario no demuestra recepción externa. Confirma que el trabajo aislado utiliza una ruta real admitida y después revisa las observaciones de los buzones.
¿Un spam score bajo garantiza Inbox?
No. Análisis de contenido y ubicación son medidas distintas. La puntuación puede orientar una revisión, pero no establece cómo clasificó un proveedor una copia real.
¿Puedo reenviar la captura en vez de generar otro mensaje?
Puedes reenviarla para enseñar el contenido, pero no reproduce la ruta original. Para esta prueba, genera un nuevo original mediante el camino que estás evaluando.
¿Debo sustituir toda la configuración de staging?
No. Mantén aislado el desarrollo habitual. Utiliza un trabajo real limitado, con destinatarios explícitos y ruta documentada, para que otras tareas no formen parte del experimento.
¿Qué hago si mi dominio todavía no puede enviar realmente?
Continúa las comprobaciones que admite Sandbox y completa los requisitos aplicables de Mailtrap. La espera o indisponibilidad de esa ruta no demuestra Spam.
Añade evidencia de los buzones
Inicia una prueba de LDM cuando mensaje final y ruta permitida estén preparados. Conecta inspección del contenido, eventos de envío y carpetas observadas sin confundir lo que demuestra cada etapa.