#01 · AI Agent Developer · Email Outreach Engine
Outreach Engine Anti-Fingerprint — Pipeline de email que envía como una persona, no como un script
Cliente B2B de servicios locales (dominio dedicado de agencia) ·
Sistema propio de outreach por email para un cliente B2B de servicios locales — diseñado para enviar como una persona, no como un script, y para detenerse solo cuando algo sale mal. La mayoría de las herramientas de email marketing automatizado comparten un mismo defecto: dejan una firma mecánica que los filtros de spam de Google y Microsoft ya saben leer. Un correo exacto cada seis minutos, un dominio nuevo enviando volumen alto desde el día uno, un "unsubscribe" que tarda en aplicarse — cada uno de esos detalles es una señal de bot, aunque el remitente sea un negocio real. Este pipeline resuelve ese problema desde la raíz: no ocultando que es un sistema automatizado, sino haciendo que su comportamiento — horarios, volumen, calentamiento, manejo de errores — sea indistinguible del de una persona trabajando con disciplina. Cada regla que aparece aquí nació de un incidente real documentado en el código, no de una decisión teórica de diseño. Infraestructura: Node.js · SMTP/IMAP.
Leer análisis completo
01 · El correo y el dominio de envío
El remitente real es una cuenta dedicada del dominio de envío, enviada vía SMTP del proveedor de hosting (puerto 587, STARTTLS) a través de nodemailer. La resolución DNS se fuerza explícitamente a 1.1.1.1 / 8.8.8.8, resolviendo el host SMTP a IP antes de conectar — el resolver local del servidor fallaba de forma intermitente y eso bastaba para tumbar un envío a mitad de lote.
De cara al destinatario, el correo llega firmado con nombre y cargo reales de una persona del equipo comercial, con una firma en imagen incrustada como cid: en los correos e2/e3. El price sheet real del cliente va adjunto desde el primer contacto — un archivo real, no un link roto a un servidor que puede estar caído.
El dominio de envío es un dominio de agencia, deliberadamente separado del sitio público del cliente. Ninguna API ni credencial de este pipeline toca ese segundo dominio.
02 · Calentamiento del dominio
Un dominio nuevo necesita historial de entrega, apertura y respuesta genuino antes de que Gmail y Outlook confíen en él. En vez de contratar un servicio externo de warming — señal sintética, fácil de detectar — construí un sistema de conversaciones reales entre cuentas propias.
La cuenta de envío conversa con cuatro cuentas de Gmail propias, verificadas con SMTP e IMAP reales. Cada día se sortea un presupuesto de entre 3 y 8 mensajes — nunca un número fijo — repartidos en horarios aleatorios dentro de una ventana de 8am a 9pm. Un Task Scheduler dispara el script cada 20-30 minutos, pero es el script quien decide si realmente actúa: si no venció ningún turno, no hace nada; si venció uno, prioriza responder una conversación con mensaje sin leer antes de abrir una nueva.
Cada conversación se cierra sola a los cuatro intercambios — nunca queda un loop infinito — y lleva jitter humano de 5 a 20 segundos antes de cada envío, con contenido variado tomado de un pool de mensajes "starter".
03 · Horarios de envío humanizados
Esta es la pieza que evita que un lote de 12 a 33 correos diarios se vea como una ráfaga automatizada. La primera versión — jitter uniforme cada 3-8 minutos — se descartó por ser detectable. La versión actual genera un plan de horarios una sola vez al día:
El plan decide únicamente horarios, no destinatarios: quién ocupa cada slot se resuelve en el momento exacto del envío, para que un lead que dejó de ser elegible a media mañana no ocupe un espacio de la tarde con datos viejos. Si el proceso muere a mitad de una corrida, el siguiente run recupera hasta 3 slots vencidos de una sola vez — nunca más, para no disparar una ráfaga gigante de golpe. Todo el cálculo corre en America/Chicago, con conversión correcta a UTC incluyendo cambios de horario de verano.
- Reparto bimodal: ~60% de los envíos entre las 8:00 y las 11:30am (hora de Texas), un envío opcional al mediodía con 40% de probabilidad si el cupo del día es de 6 o más, y el resto por la tarde hasta las 4:00pm — nunca después.
- Clusters tipo Poisson: en vez de espaciar los correos de forma uniforme, se agrupan en ráfagas de 2 a 4, con 1 a 5 minutos entre sí, separadas por huecos de 30 a 90 minutos — el patrón de alguien que trabaja por bloques, no de un intervalo fijo.
- Autovalidación del plan: antes de usarse, se revisa que ningún cluster supere 4 correos, que ningún hueco entre clusters sea menor a 30 minutos y que nada caiga después de las 4pm.
04 · El cupo diario
El volumen no es fijo: sigue una escalera semanal en forma de campana, aprobada por el cliente, que se fue subiendo a medida que el dominio demostraba buena entrega. Cupo semanal actual: lunes 20 · martes 23 · miércoles 33 (pico) · jueves 29 · viernes 22 · sábado y domingo 0.
La forma de campana responde a comportamiento real de bandeja: el lunes llega con bandejas saturadas del fin de semana (más quejas), martes a jueves es donde mejor responde B2B, y el viernes la respuesta cae por la tarde. La tabla arrancó en un total semanal de 74 correos y escaló ~1.3x cada vez que dos semanas seguidas cerraban limpias — siempre con aprobación explícita del cliente antes de subir, nunca de forma automática.
- Regla inviolable: cada mañana se revisa cómo cerró el último día con envíos reales.
- Si cerró limpio (rebotes ≤3%), se usa el cupo normal del día.
- Si cerró sucio por primera vez, el cupo de hoy se congela en el valor del día sucio.
- Si cierra sucio dos días seguidos, el sistema se pausa por completo hasta que el cliente revise manualmente — nunca se reactiva solo.
05 · Las secuencias de email
Cadencia estándar por lead: día 1 email e1 (primer contacto) · día 3 email e2 (price sheet adjunto) · día 5 LinkedIn (li1) · día 8 email e3 (breakup) · día 10 cierre (pasa a NURTURE-90 sin respuesta).
Hay variantes de plantilla por canal: el canal retail estándar sigue e1 → e2 → e3; el canal puerta-a-puerta usa plantillas c1/c2/c3 (ángulo de ventas) o p1/p2/p3 (ángulo de producción) sin price sheet adjunto; el canal de referidos por seguros usa la familia r1/r2/r3; y un toque e-clic se dispara 24-48h después de que un lead hace clic en un link, fuera de la cadencia normal.
- Retroceso automático: si un lead nunca recibió e2, el sistema no manda un e3 que suene a "tercer contacto" sin segundo — retrocede al paso real que le falta.
- Catch-up tras el día 10: un lead atascado que pasó el día 10 sin calzar con la cadencia se retoma en el primer email real pendiente, en vez de quedar congelado para siempre.
- Anti-doble-contacto: en el canal puerta-a-puerta, si otro contacto de la misma empresa ya está en cadencia activa, no se pitchea a un segundo contacto hasta 7 días después del último toque.
- Reentrada contextual: un lead reactivado tras un "ya tenemos proveedor" recibe un mensaje diseñado para esa objeción específica, no el pitch de primer contacto.
- Kill switch: cualquier lead que responde sale inmediatamente de la cadencia automática, sin importar la fecha, y pasa a revisión humana.
- Anti-fingerprint: el texto de intro y CTA rota entre variantes por selección determinística según el email del lead — siempre la misma variante para el mismo lead, distinta entre leads — para que no todo el lote del día salga con el texto idéntico.
06 · Puntuación de leads
Cada lead recibe un score de 0 a 100 calculado por cuatro componentes con pesos configurables: ICP fit (25 — industria exacta, localidad en lista, tamaño en rango) · Intención (45 — suma de señales de intención detectadas; el componente más pesado) · Reachability (15 — email válido, teléfono verificado, LinkedIn del decisor) · Actividad (15 — verdict de validación de la empresa: activa / dudosa / muerta).
El umbral de calificación para entrar a cadencia automática es score ≥ 60. Un lead del canal de mayor valor por proyecto, con señal de lenguaje específico detectada, recibe un bonus de +30 puntos — decisión de negocio explícita del cliente según el valor relativo de cada segmento. Cualquier lead que responde se fuerza a score 100 de inmediato, sin importar el cálculo.
07 · Verificación de email en cascada
Ningún correo se envía a una dirección no verificada — es una regla física en el código. Antes de eso, cada email pasa por tres niveles:
Nació de un incidente real: 183 leads quedaron marcados como ALL_INVALID solo porque se agotó la cuota de un proveedor de verificación. Desde entonces, un error de API nunca colapsa a INVALID ni a VALID — se guarda como estado separado (UNKNOWN / VERIFICATION_ERROR) para no destruir leads válidos por un timeout ajeno.
- 1. Handshake SMTP propio (gratis, ilimitado): MX lookup + RCPT TO sin enviar el correo, desde el servidor. Devuelve VALID, INVALID, CATCH_ALL o UNKNOWN.
- 2. Snov Verifier (de pago, pool mensual): segunda opinión para lo que queda CATCH_ALL/UNKNOWN, priorizado para decisores.
- 3. MillionVerifier (pago por uso): respaldo final para lo que sigue sin resolver.
08 · Rebotes y auto-pausa
Dos mecanismos distintos trabajan en conjunto. El primero revisa la bandeja de la cuenta de envío cada 15-30 minutos vía IMAP, buscando mensajes de mailer-daemon o asuntos de entrega fallida, y distingue un rebote duro (código 550-554, buzón inexistente) de uno blando (buzón lleno, greylisting temporal). Un rebote duro confirmado pasa al lead a blacklist de inmediato, con registro exacto en bounce-log.json.
El segundo es un gate que se evalúa antes de cada lote: calcula el porcentaje de rebotes de las últimas 24 horas reales. Si supera el 3%, el envío del día se pausa y el cliente recibe una notificación — se requiere revisión manual antes de reanudar.
Hay un límite conocido y documentado a propósito: el sistema no mide quejas de spam (feedback loop de los ISPs), solo rebotes duros vía IMAP. "Cerrar limpio" hoy se evalúa únicamente con bounce rate.
09 · Unsubscribe
Tres canales de baja, todos confluyen al mismo resultado: un Google Form en el footer que un script revisa periódicamente, una respuesta por email con palabras como "unsubscribe" o "stop" detectada por el mismo proceso IMAP que vigila rebotes, y un botón one-click real (RFC 8058) en el header List-Unsubscribe, firmado con HMAC, que Gmail y Outlook muestran junto al remitente.
En los tres casos el lead pasa a blacklist permanente — guardada primero en un CSV local (se respeta incluso si el Sheet remoto falla) y sincronizada después — y queda excluido de cualquier campaña futura, con el canal exacto de baja auditado en unsubscribe.log.
10 · Tracking de clics
Todos los links reales pasan primero por un webhook propio (un Cloudflare Worker) que firma cada link con HMAC — lead, destino real, tipo de link y timestamp de envío — antes de redirigir al destino, sin pantalla intermedia visible. Un clic detectado en menos de 60 segundos desde el envío se descarta como escaneo de seguridad corporativo, no como interés humano.
Un clic real mueve al lead a la etapa COMPROMETIDO, dispara un toque contextual 24-48h después y encola una llamada con guión específico — es la señal de intención más fuerte de todo el sistema, por encima de cualquier regla de calendario. El tracking de apertura (píxel) está desactivado: se intentó servir desde Google Apps Script y falló porque esa plataforma no puede devolver contenido binario desde un Web App; el código ya está listo para cuando exista un endpoint capaz de servirlo.
11 · Respuestas reales
El mismo proceso IMAP que revisa rebotes y bajas también detecta respuestas humanas reales — por asunto "Re:", headers In-Reply-To/References, o remitente ya conocido en la base.
Nació de un incidente real: un autoresponder de "Out of Office" subió por error a un lead a score 100. Desde entonces, cualquier mensaje con lenguaje de autorespuesta se filtra explícitamente y no cuenta como respuesta real — la cadencia sigue normal. Una respuesta real confirmada fuerza el score a 100 y notifica al cliente de inmediato, sin esperar el reporte del día.
12 · Resistencia a fallos
El sistema guarda su estado inmediatamente después de cada envío real — no al final del script. Sin esto, un corte de red a mitad de corrida podía hacer que el mismo correo saliera dos veces. Un lock file evita que dos corridas procesen el mismo lote a la vez, y un heartbeat permite detectar si el proceso dejó de correr. El cupo de un día solo se recorta hacia abajo nunca hacia arriba: si el gate de rebotes lo reduce a mitad de jornada, los slots sobrantes simplemente no se usan.
El flujo completo
1. Sourcing → validación de empresa → verificación de email en cascada. Solo entran leads con email confirmado como enviable.
2. Scoring 0-100. Score ≥ 60 entra al drip automático de email.
3. Checkpoint de warming cada mañana. Decide el cupo del día: escalera semanal + gate de rebotes de las últimas 24h.
4. Plan de horarios humanizado. Clusters tipo Poisson, reparto bimodal mañana/tarde, validado antes de usarse.
5. Envío cada ~20 minutos. Manda lo que esté vencido según la cadencia (día 1 / 3 / 8), renderiza plantilla, adjunta PDF y firma, envía por SMTP.
6. Vigilancia IMAP cada 15-30 minutos. Rebotes, respuestas reales y bajas — las tres señales que pueden sacar a un lead de la cadencia o subirlo de prioridad.
7. Salida de la cadencia. Rebote duro o baja → blacklist inmediata. Respuesta real → aviso prioritario al cliente. Clic real → etapa COMPROMETIDO + llamada. Sin respuesta tras el día 10 → NURTURE-90.
Documento generado a partir del código real del sistema en producción (2026-09-30). Cada regla descrita aquí nació de un incidente real documentado en los comentarios del código.
- Cupo semanal
- 74 → 127
- Umbral de rebotes
- ≤3%
- Reactivación automática
- Nunca
