Una prueba de Inbox Placement con Postmark debe utilizar el mismo Message Stream y camino de presentación que el mensaje previsto. Envía un original por esa ruta a las direcciones de LDM y examina las carpetas. Un recibo que aparece en Inbox mediante un flujo Transactional no valida un boletín que utilizará otro flujo Broadcast.
Dos correos pueden mostrar el mismo From y, sin embargo, proceder de código, plantillas o flujos diferentes. Registra esas decisiones: la dirección visible no describe por completo el experimento. Este procedimiento utiliza destinatarios de prueba; no presupone que LDM se conecte a tu cuenta ni seleccione un stream por ti.
Una comparación controlada ayuda a evaluar una hipótesis; un resultado no demuestra una solución universal.
Qué representa el flujo
Postmark distingue flujos Transactional para mensajes como recibos derivados de acciones del usuario, y Broadcast para comunicaciones de uno a muchos, como boletines. La guía Message Streams explica que el flujo Transactional original del servidor sigue siendo el predeterminado. Crear otro no cambia ese valor.
Elige la clase según la finalidad y el proceso real. Que un envío sea automático no lo convierte en transaccional: un boletín programado sigue sin ser un recibo. Consulta las características adicionales de Transactional vs. Broadcast para los casos dudosos.
Mantén el mensaje de prueba en la clase apropiada para la comunicación prevista. Una observación solo resulta útil si corresponde a una ruta que puedes utilizar legítimamente para ese tipo de correo.
La selección cambia entre API y SMTP
Para la API, Postmark documenta MessageStream con el Stream ID. Si se omite, utiliza el flujo Transactional predeterminado. Cuando pruebes otro, incluye explícitamente su ID y verifica la solicitud efectiva; el nombre descriptivo de una variable no basta.
En SMTP debes revisar tanto el servidor como la autenticación. Los hosts documentados son smtp.postmarkapp.com para Transactional y smtp-broadcasts.postmarkapp.com para Broadcast. La referencia de SMTP y tokens describe dos opciones: Server Token junto a una cabecera de selección o un SMTP Token específico del flujo. La guía identifica la cabecera como X-PM-Message-Stream.
Si tu biblioteca elimina cabeceras personalizadas, comprueba lo que presenta realmente. Cuando resulte adecuado, utiliza la autenticación SMTP documentada por flujo, sin suponer que la cabecera sobrevivió al procesamiento del framework.
La interfaz de LDM también está disponible en español. Los enlaces abren la interfaz en español.
Ejecuta una prueba representativa
1. Define la comunicación
Selecciona un restablecimiento de contraseña, un recibo, una actualización o un boletín. Identifica el stream apropiado y el camino de la aplicación responsable del envío.
Utiliza datos seguros que produzcan el mensaje final. Conserva asunto, identidad, versiones del cuerpo, enlaces y adjuntos. Mantén las bajas y cabeceras necesarias. Eliminarlas para simplificar el resultado haría que el espécimen dejara de representar la comunicación real.
2. Guarda la configuración de ruta
Anota servidor de Postmark, Stream ID, API o SMTP, revisión de aplicación y plantilla. Para SMTP, registra host y método de autenticación sin guardar el token. Para API, conserva el valor efectivo de MessageStream.
Incluye las cabeceras y el seguimiento relevantes. Este registro permite explicar por qué una prueba manual y un trabajo programado no son necesariamente equivalentes. Documenta las diferencias que introduzcas deliberadamente.
3. Prepara un conjunto finito de destinatarios
Crea una prueba en Inbox Placement by LDM con el remitente real y obtén sus direcciones actuales. Confirma que tu cuenta y flujo permiten ese envío.
Mantén los destinatarios fuera de audiencias permanentes, calentamiento y automatizaciones recurrentes. Si necesitas registros temporales en la aplicación, aíslalos de la selección normal de clientes para evitar mensajes posteriores. No anules supresiones para forzar la entrega.
4. Genera un original por el flujo seleccionado
Usa el renderizado y la presentación habituales, con el conjunto limitado de destinatarios. No reenvíes una copia desde el buzón de un empleado: eso añade otra ruta y otro contexto.
Comprueba de nuevo la configuración inmediatamente antes del envío. En API, verifica el valor del stream. En SMTP, verifica host y mecanismo efectivo de selección. Conserva cada modificación intencional en el registro del experimento.
5. Confirma el flujo que procesó el mensaje
Revisa la actividad disponible del mensaje concreto. Relaciona destinatario, hora y referencia con el registro de la aplicación, y confirma el stream asociado. Un nombre de plantilla o etiqueta de trabajo no demuestra el camino utilizado.
Separa errores de presentación, resultados del transporte y carpetas. Si el mensaje nunca quedó habilitado para entrega, investiga esa etapa antes de atribuir el resultado al filtro del destinatario.
6. Interpreta las copias con sus límites
Aplica la metodología de LDM. 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, sin reenviarla en cada punto. Guarda las horas de medición. Una consulta posterior fallida no establece otra ubicación ni invalida una observación anterior confirmada.
Ejemplo hipotético: falta MessageStream
Un ingeniero reutiliza una herramienta de prueba de recibos para evaluar un anuncio de producto. La herramienta omite MessageStream y utiliza el flujo predeterminado. La copia aparece en Inbox y el equipo considera inicialmente verificado el anuncio.
Es un error hipotético de configuración, no una recomendación para enviar anuncios mediante Transactional. La observación corresponde al camino utilizado; no valida la configuración Broadcast prevista.
El equipo identifica la diferencia, selecciona el flujo apropiado y realiza otra prueba limitada con el anuncio final. Cualquier diferencia debe describirse junto al cambio de ruta. Una carpeta distinta no demuestra, por sí sola, que la selección del stream haya causado el cambio.
Conserva un registro que pueda revisarse
Guarda cuatro elementos relacionados: mensaje final, ruta efectiva, resultado del remitente y observaciones de buzón con sus horas. Incluye identificadores para conectarlos, sin credenciales ni datos personales innecesarios.
Al repetir la prueba tras modificar plantilla o ruta, explica exactamente qué cambió. Una comprobación de migración completa puede evaluar la nueva configuración, pero no aislar un elemento si se modificaron varios.
El resultado sigue limitado a los destinatarios observados. No predice las reglas, interacciones previas o decisiones futuras de cada suscriptor. La autenticación correcta tampoco garantiza Inbox.
Preguntas frecuentes
¿Un nuevo stream pasa a ser el predeterminado?
No. Postmark conserva el Transactional original del servidor. Selecciona explícitamente cualquier otro flujo y confirma el envío real, sin basarte en el orden de creación.
¿Una prueba correcta de recibo valida mi boletín?
No. El boletín tiene contenido, contexto y ruta apropiada propios. Prueba ese flujo específico con el mensaje final y sus bajas necesarias.
¿Qué hago si el cliente SMTP no admite la cabecera?
Revisa la opción documentada de SMTP Token por flujo y utiliza el host correcto. Confirma que el cliente admite la configuración antes de considerar reproducida la ruta.
¿Una copia ausente significa que elegí mal el stream?
No. Determina el flujo mediante configuración y registros. La ausencia o indisponibilidad de una observación no identifica la causa ni equivale a Spam.
¿Debo comparar flujos enviando continuamente a los mismos seeds?
No conviertas la prueba en envío recurrente. Usa experimentos limitados, una pregunta legítima, la clase adecuada y las direcciones actuales; evita incorporarlas a calentamiento o campañas permanentes.
Comprueba el flujo junto al mensaje
Inicia una prueba de LDM para el proceso específico de Postmark. Conserva original y ruta para que el resultado tenga un significado claro y comprobable.