No hay bandeja de entrada aparte para agentes: mismas reglas de CAN-SPAM, mismos umbrales de Gmail y misma separación técnica entre marketing y transaccional.
Un agente puede lanzar una campaña con la misma infraestructura de envío que una persona. Gmail sigue viendo el remitente, el dominio y el mensaje.
Los proveedores de correo puntúan dominios, IP y tasas de quejas. No puntúan si fue una persona quien hizo clic en Enviar. Si el agente envía contenido promocional por la IP transaccional, heredas el mismo problema que habrías creado a mano, solo que antes.
Este artículo complementa la guía de entregabilidad, no la sustituye. La guía trata la reputación, la autenticación y la higiene de la lista; este, los errores que aparecen cuando es el software quien pulsa Enviar.
La ley CAN-SPAM se aplica a los mensajes comerciales. El criterio de finalidad principal se fija en el asunto y en el cuerpo del mensaje, no en quién los escribió.
Si un mensaje mezcla una factura y una oferta, evalúa su finalidad principal. Cuentan el asunto, dónde aparece la información de la cuenta y cuánto destaca la promoción. Un breve pie de página promocional no convierte automáticamente un extracto de cuenta en un mensaje comercial. La guía de la FTC incluye ejemplos. Los mensajes comerciales necesitan encabezados y asuntos veraces, una dirección postal y una opción de baja que funcione.
También ocurre al revés. Un email para restablecer la contraseña que el agente activó a raíz de un evento de seguridad real sigue siendo transaccional, siempre que el cuerpo se ciña a ese evento.
Los requisitos para remitentes de Gmail incluyen normas para todos los remitentes y otras más estrictas para los remitentes masivos que envían unos 5000 mensajes al día a cuentas personales de Gmail. Entre esos requisitos más estrictos están:
p=none o más estricta.List-Unsubscribe y List-Unsubscribe-Post.El correo transaccional está exento de la regla de la baja con un clic. No está exento de la autenticación, ni de las quejas por spam si metes una oferta en la plantilla.
Yahoo pide a los remitentes de gran volumen que separen el marketing y el transaccional en IP distintas y, preferiblemente, en dominios distintos. Comprueba qué identidad de envío usará el agente en lugar de dejarlo en manos de un valor predeterminado poco claro.
Dale al agente una identidad de envío promocional para las campañas y las automatizaciones: el dominio que estás calentando, la IP en la que esperas las quejas y los encabezados de baja que ya has probado.
Mantén el correo transaccional en una identidad aparte. En Brew, esa identidad es un dominio con propósito de envío transaccional, y el correo en sí es una automatización publicada con un disparador. El agente puede redactar la plantilla. Aun así, cada evento debería enviarse con POST /v1/automations/triggers/{triggerEventId}/fire y un payload JSON, no con un “envía este borrador a la lista”.
No dejes que el agente elija la dirección From entre un montón de dominios verificados “para ver cuál llega”. Así acabas entrenando dos reputaciones a la vez sin entender ninguna.
El fallo típico no es una errata. Es un párrafo bien escrito que cita una cifra que nunca publicaste, o un asunto que parece un recibo.
Antes de dejar que un agente envíe sin pasar por una cola de aprobación:
Cory Nelson, de Harmonya, le contó a Noah Adelstein que hizo esa lectura de la primera campaña antes de confiar en el proceso automatizado. Ese es el orden correcto.
Autentica el dominio, elige la identidad de envío correcta y contrasta la primera campaña con el brief aprobado. Revisa también los permisos y los ajustes de confirmación del asistente. No todos los clientes MCP piden aprobación de la misma forma.
El brief que evita las cifras inventadas está en cómo preparar el brief para un agente de email. La lectura de la primera campaña de Harmonya está en cómo Harmonya convirtió una newsletter en un programa de ciclo de vida.
