Supresiones, rebotes y entregabilidad
Gestiona tu lista de supresión, entiende la gestión de rebotes y protege tu reputación como remitente.
Por qué es importante
Enviar emails a direcciones inválidas daña tu reputación como remitente. El daño reputacional hace que más de tus emails terminen en spam, no solo los de outreach sino todos los emails que envía tu dominio. La lista de supresión y la gestión de rebotes de Kit protegen tu reputación al impedir automáticamente que vuelvas a contactar direcciones que rebotaron, se dieron de baja u optaron por no recibir emails.
Lista de supresión
La lista de supresión es a nivel de cuenta: se aplica a todas las campañas. Ve a Outreach > Suppressions para verla y gestionarla.
Los emails se almacenan como hashes SHA-256 por privacidad. Una dirección se suprime automáticamente cuando:
- Se detecta un hard bounce (el servidor del destinatario rechaza de forma permanente la dirección en sí, o una notificación de rebote lo confirma)
- Un prospecto hace clic en el enlace de cancelar suscripción en un email de outreach
- Tu equipo marca a un prospecto como dado de baja
También puedes agregar manualmente direcciones de email a la lista de supresión para evitar contactarlas en el futuro, o eliminar una dirección si fue suprimida por error.
Al importar prospectos por CSV, Kit comprueba cada email contra la lista de supresión y omite las coincidencias automáticamente.
Gestión de rebotes
Kit clasifica los rebotes por severidad y origen:
| Tipo | Código SMTP | Acción |
|---|---|---|
| Hard bounce | 5xx en respuesta a RCPT TO con un código de estado de dirección de destinatario: 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.6, 5.1.10, 5.2.1 o 5.4.1
|
Supresión inmediata; la dirección es inválida, está desactivada o ya no existe |
| Rechazo por política | 5xx con un código de estado 5.7.x (filtro antispam, DMARC, lista de bloqueo) |
El mensaje falla; la dirección no se suprime, porque el rechazo tiene que ver con tu reputación como remitente, no con la dirección |
| Otro fallo permanente | Cualquier otro 5xx: antes de RCPT TO, sin código de estado ampliado, o con un código de remitente, de cuota o de protocolo |
El mensaje falla y queda para que lo revise una persona; la dirección no se suprime |
| Soft bounce | 4xx (fallo temporal) | Reintento con backoff; el buzón puede estar lleno o el servidor temporalmente no disponible |
Las confirmaciones de rebote llegan por SMTP o por notificaciones DSN:
| Fuente | Cómo funciona |
|---|---|
| SMTP | El servidor de envío rechaza el mensaje en el momento de la entrega con un código de error |
| DSN | Llega un email de Delivery Status Notification después del envío (rebote diferido) |
Una clasificación de rebote por IA no cambia por sí sola el estado de entrega ni suprime una dirección. Esas acciones requieren pruebas SMTP o DSN.
Los hard bounces suprimen la dirección de inmediato; los rechazos por política y los demás fallos permanentes no lo hacen, así que ningún prospecto válido se pierde por un problema de reputación. Los fallos temporales que pueden reintentarse con seguridad se vuelven a intentar; cuando se agotan todos los intentos, el mensaje pasa a Intentos agotados para que una persona decida.
Revisión de entrega
Abre Outreach > Entregabilidad para gestionar los mensajes que Kit ha detenido de forma intencionada:
- Entrega desconocida significa que la conexión SMTP terminó después de empezar el envío y Kit no puede confirmar si el proveedor aceptó el correo. Revisa las pruebas del intento y los registros del proveedor a partir del RFC Message-ID antes de decidir. Que el mensaje no esté en Enviados no demuestra por sí solo que no se envió.
- Intentos agotados significa que un fallo temporal conocido antes del envío consumió todos los reintentos seguros. Corrige el problema del remitente o del proveedor antes de autorizar otro intento.
- Fallido significa que Kit recibió un fallo conocido de autenticación, remitente, contenido o política. Corrige esa causa concreta antes de autorizar otro intento; de lo contrario, cierra la revisión sin enviar.
Un miembro con permiso para gestionar la campaña puede confirmar que una entrega desconocida se envió, confirmar que no se envió a partir de las pruebas del proveedor, autorizar un reintento después de corregir una entrega agotada o fallida, o cerrar cualquier revisión sin enviar. Kit registra la decisión, la atribución a quien la tomó mientras se conserve, su origen, la marca de tiempo y una nota opcional cifrada. Solo pone en cola otro intento cuando el resultado lo autoriza de forma explícita.
Inspecciona el último intento antes de decidir: la fase SMTP, los códigos de respuesta y estado ampliado, las marcas de tiempo, el diagnóstico y el RFC Message-ID forman las pruebas de la revisión. La vista previa de la resolución queda vinculada a ese intento y esas pruebas concretas. Cuando se permite otro intento, también se vincula al destinatario, la identidad del remitente, el asunto y el cuerpo revisados. Si el intento, las pruebas o el contenido del envío cambian antes de confirmar, Kit rechaza la confirmación obsoleta y exige otra vista previa.
Protección de la confirmación de aprobación
Si el destinatario, la identidad del remitente, el asunto o el cuerpo de un mensaje aprobado cambia antes de iniciar SMTP, Kit lo pasa a Revisión necesaria y no abre ningún intento de entrega. Revisa el mensaje actual y vuelve a aprobarlo. El webhook outreach.message.confirmation_expired permite que los sistemas conectados distingan esta detención segura antes del envío de un fallo SMTP.
Cumplimiento de la cancelación de suscripción
Por defecto, Kit agrega encabezados de cancelación de suscripción RFC 8058 a cada email de outreach:
- Encabezado List-Unsubscribe con una URL de cancelación en un clic
- Encabezado List-Unsubscribe-Post que admite el POST en un clic de RFC 8058
- Los tokens de cancelación expiran a los 6 meses por seguridad
Puedes desactivar estos encabezados en Outreach > Settings si envías cold email personalizado 1:1, donde los encabezados podrían parecer correo masivo a los ESP. La página de cancelación, la lista de supresión y los flujos de baja siguen funcionando independientemente de esta configuración.
Cuando un prospecto hace clic en cancelar suscripción, Kit suprime su email de inmediato y actualiza el estado del prospecto a Desuscrito. No se envían más emails.
Consejos de entregabilidad
| Práctica | Por qué ayuda |
|---|---|
| Usa un dominio de envío dedicado | Aísla la reputación de outreach de tu dominio principal |
| Calienta gradualmente | Comienza con 10–15 emails/día y aumenta a lo largo de 2–4 semanas |
| Respeta el límite diario | El valor predeterminado es 50 emails/día por cuenta, configurable hasta 500 en los ajustes de SMTP |
| Vigila la tasa de rebotes | Mantén los hard bounces por debajo del 2 %; limpia tus listas con regularidad |
| Escribe emails relevantes | Las quejas por spam bajan cuando los prospectos reconocen por qué los contactas |
| Incluye una firma clara | Los destinatarios que pueden identificar al remitente tienen menos probabilidad de marcar el mensaje como spam |
| Usa un dominio de seguimiento personalizado | Si activas el seguimiento de interacciones, configura un dominio de seguimiento personalizado para que las URLs de píxel/redirección coincidan con tu dominio de envío |
Eventos de webhook
Kit dispara eventos de webhook para actividades clave de outreach. Suscríbete en Integrations > Webhooks para sincronizar datos de outreach con sistemas externos.
| Evento | Se dispara cuando | Modelo del payload |
|---|---|---|
outreach.prospect.drafted |
La IA termina de redactar un email para un prospecto | Prospect (ID, campaign_id, company_name, display_name, status) |
outreach.message.approved |
Se aprueba un borrador para envío | Message (ID, campaign_id, prospect_id, step_number, subject, status, timestamps) |
outreach.message.sent |
Un email se envía correctamente por SMTP | Message |
outreach.message.bounced |
Se recibe un rebote permanente confirmado para un email | Message (incluye last_error_code) |
outreach.message.failed |
El envío falla por un error SMTP | Message (incluye last_error_code) |
outreach.message.deferred |
Un fallo temporal conocido antes del envío persiste tras agotar todos los intentos de entrega | Message (incluye last_error_code) |
outreach.message.delivery_unknown |
Kit no puede confirmar si SMTP aceptó el email y detiene el reenvío automático | Message (incluye last_error_code) |
outreach.message.confirmation_expired |
Los datos de envío revisados cambian antes de iniciar SMTP y Kit se detiene para pedir otra aprobación | Message |
outreach.message.delivery_resolved |
Un miembro con permiso para gestionar la campaña registra una decisión auditable para una entrega detenida | Delivery Resolution (mensaje, intento, resultado, origen, responsable y marcas de tiempo) |
Todos los payloads siguen el formato estándar de webhook. Consulta Webhook Events Reference para el formato del envelope y la verificación de firma.
Nota: Las direcciones de email de prospectos y mensajes se excluyen de los payloads de webhook porque están cifradas en reposo. El diagnóstico SMTP completo y la nota de resolución se excluyen por la misma razón: ambos pueden contener datos del destinatario copiados del buzón. Los webhooks de mensaje solo transportan el last_error_code ya procesado; para leer el diagnóstico o la nota completa, abre el mensaje en Kit.
Checklist rápido
- Revisa tu lista de supresión en Outreach > Suppressions
- Verifica que tu dominio de envío tenga registros SPF, DKIM y DMARC
- Vigila las tasas de rebote; investiga si los hard bounces superan el 2 %
- Considera un dominio de envío dedicado para outreach
- Suscríbete a los eventos de webhook de outreach si integras con herramientas externas
Siguientes pasos
- Configurar el envío de correos: configuración de SMTP e IMAP
- Webhook Events Reference: documentación completa de payloads para todos los tipos de eventos
- MCP Tools Reference: gestiona outreach programáticamente con asistentes de IA