Una respuesta 200 no es una entrega
La aceptación del proveedor, la entrega en la bandeja, los rebotes duros y temporales y las quejas son estados diferentes.
Activación por email para desarrolladores
Workspace disponible · envío a clientes no activoLa solicitud de envío es solo el comienzo.
TrackMailer está diseñado para conectar el email transaccional con la entrega, los rebotes, los clics y lo que ocurre después. Hoy puedes configurar audiencias y remitentes y validar contratos de solicitud en Sandbox; el envío a clientes en producción sigue desactivado.
01Solicitud→
02Identidad del remitente→
03Señales de entrega→
04Clic→
05Resultado
Por qué importa la infraestructura de email
«Aceptado» no significa entregado, y entregado no es el resultado.
El email transaccional se convierte en infraestructura operativa cuando restablecimientos de contraseña, recibos y mensajes de ciclo de vida afectan la confianza, la carga de soporte y los ingresos.
La tasa de apertura es una señal imperfecta
Los proxies de privacidad, el bloqueo de imágenes, las cachés y los escáneres impiden usar las aperturas como única fuente de verdad.
El contexto del email termina demasiado pronto
Un clic aporta más información cuando el contexto de campaña y sesión puede conectarlo después con un registro o una compra.
Ciclo objetivo de entrega
Pasa de la intención a la evidencia, un estado explícito a la vez.
TrackMailer separa configuración, validación, aceptación del proveedor, eventos de entrega y atribución posterior. Así evita contar un borrador, una respuesta de Sandbox o una solicitud al proveedor como mensaje entregado.
- Disponible
Preparar
Modela contactos, campos obligatorios, grupos sujetos al consentimiento, filtros guardados y un dominio remitente exacto dentro de un proyecto.
- Sandbox
Validar
Comprueba una solicitud tipada en el Sandbox autenticado. Un resultado válido indica sent=false y persisted=false.
- Previsto
Entregar
Un futuro worker verificado separará la aceptación del proveedor de la entrega, el rebote y la queja.
- Previsto
Atribuir
Una futura conexión con TrackAny.Click llevará los clics del email al contexto de sesión, conversión e ingresos.
{
"operation": "transactional.send",
"sender": {
"senderDomainId": "<your project domain id>",
"fromLocalPart": "service"
},
"to": "recipient@example.com",
"subject": "Your receipt",
"text": "Thanks for your order.",
"idempotencyKey": "receipt_2026_001",
"purpose": "receipt"
}Usa este contrato en el Sandbox autenticado de TrackMailer. Solo valida; en esta versión no existe una URL pública para enviar emails a clientes.
Flujos concretos
Diseña el mensaje en torno al trabajo que debe cumplir.
El workspace puede modelar y validar estos flujos hoy. El envío real a clientes sigue siendo una futura etapa de activación.
Mensajes de seguridad y cuenta
Prepara contratos de contraseña, verificación y alertas de cuenta con un propósito y una identidad de remitente explícitos.
Leer la guía técnicaRecibos y notificaciones de ciclo de vida
Valida payloads transaccionales idempotentes en tu servidor antes de activar una canalización de entrega.
Leer la guía técnicaAudiencias sujetas al consentimiento
Crea campos de contacto tipados, grupos manuales y filtros guardados sin tratar una vista previa como lista final de envío.
Leer la guía técnicaCreado para desarrolladores que lanzan productos con IA
Dale a tu agente un contrato, no permiso para adivinar.
La tarea de email asistida por IA más segura empieza con un límite de servidor exacto, un estado explícito y una solicitud que no pueda ocultar un secreto en el navegador ni fingir que Sandbox entregó un mensaje.
Valida este payload transaccional en el Sandbox de TrackMailer.El agente puede usar la operación documentada e interpretar correctamente sent=false.
Explica DKIM, SPF, DMARC y MAIL FROM para este subdominio remitente.El agente debe usar los registros exactos devueltos por el dashboard y nunca inventar valores DKIM.
Modela un grupo de destinatarios sujeto al consentimiento para esta app de Firebase.El agente puede mapear campos personalizados estables y reglas de supresión sin poner la clave API en React.
Capacidad, problema, resultado
Construye sobre lo que existe. Identifica lo que aún bloquea la entrega.
Cada capacidad muestra su estado actual para que desarrolladores, crawlers y agentes no confundan el producto objetivo con la versión disponible hoy.
Controles de audiencia
Los campos tipados, grupos y filtros guardados reducen la lógica frágil creada para un solo uso y conservan los límites de consentimiento y supresión.
Claves API y validación de solicitudes
Las claves con alcance y el Sandbox autenticado muestran errores de esquema sin enviar, guardar contactos ni generar eventos de tracking.
Configuración de la identidad del remitente
La prueba exacta del dominio y la guía de DKIM y MAIL FROM hacen visible el límite del remitente; el recorrido completo del dominio aún necesita validación en producción.
Evidencia de entrega y resultados
Los eventos del proveedor, el mapeo verificado de destinatarios y la atribución mediante TrackAny.Click siguen siendo requisitos para reportes confiables de entrega e ingresos.
TrackMailer + TrackAny.Click
Un punto de contacto por email aporta valor cuando el siguiente paso sigue siendo medible.
La integración prevista conserva el contexto de email, clic, sesión, conversión e ingresos sin copiar datos de contacto sin procesar en cada evento. Es arquitectura, no una canalización activa para clientes.
01Intención del email→
02Evento de entrega verificado→
03Clic atribuido→
04Sesión→
05Conversión o ingresos
Límites concretos de entrega
La confianza en el email es una cadena de comprobaciones, no una insignia.
TrackMailer mantiene explícitos los límites de remitente, destinatario, organización y evento antes de activar el envío a clientes.
Secretos y permisos en el servidor
Las claves API pertenecen al servidor, se muestran una sola vez y están limitadas por modo, alcance, proyecto y dominios remitentes permitidos.
Guía relacionadaPropiedad exacta del dominio
Un dominio padre no autoriza subdominios arbitrarios; cada identidad de remitente requiere su propia prueba de proyecto y comprobaciones del proveedor.
Guía relacionadaComprobaciones de organización y permisos
Organización, proyecto, habilitación del producto y rol actual se resuelven en el servidor en vez de confiar en campos de la solicitud.
Guía relacionadaEl consentimiento y la supresión son autoritativos
Una nueva importación no reactiva silenciosamente a un contacto que canceló su suscripción, rebotó o presentó una queja.
Guía relacionadaAntes de integrar
Las respuestas honestas más breves.
¿TrackMailer puede enviar emails de clientes en producción hoy?
No. El envío a clientes, las colas, los eventos del proveedor y la atribución de conversiones no están activos. El workspace y Sandbox pueden preparar y validar el contrato sin enviar.
¿Qué demuestra una respuesta exitosa de Sandbox?
Demuestra que una solicitud autenticada cumple el esquema y las reglas de proyecto actuales. Devuelve explícitamente sent=false y persisted=false; no es un comprobante de entrega.
¿Una apertura demuestra que una persona leyó el email?
No. Los proxies de privacidad, el bloqueo de imágenes, las cachés y los escáneres automatizados afectan la medición de aperturas. Entrega, clics, rebotes y quejas deben interpretarse por separado.
Prepara el contrato ahora. Activa la entrega solo cuando la cadena de evidencia esté lista.
Usa el workspace para audiencias, remitentes y validación en Sandbox; después consulta la guía de estado antes de tratar TrackMailer como servicio de entrega a clientes.