Recepción de correos

Cualquier dirección en un dominio verificado puede convertirse en una bandeja de entrada: Bitelio acepta el correo entrante, lo guarda en tu proyecto, y dispara un evento email.received al que los flujos de trabajo pueden reaccionar. Esa es la base para respuestas automáticas, sistemas de tickets, reenvío condicional — cualquier automatización de "cuando llega un correo, haz X".

Qué ocurre cuando llega un correo

Para cada mensaje enviado a una dirección en tu dominio verificado, Bitelio:

1. Lo analiza y lo guarda como un registro Email entrante, visible en el feed de Actividad del proyecto.
2. Da de alta (upsert) al remitente como contacto — creado (suscrito por defecto) si es nuevo, actualizado en caso contrario.
3. Registra un evento email.received en ese contacto, disponible como disparador para cualquier flujo de trabajo.

Antes de guardarse, el cuerpo HTML pasa por sanitización: se eliminan scripts, iframes, manejadores de eventos y URI javascript:. Si el mensaje no tiene parte HTML, el texto plano se conserva sin cambios.

Configuración

dig MX yourdomain.com

Qué se guarda

El correo entrante aceptado aterriza en el feed de Actividad del proyecto justo al lado de tus correos salientes, con las mismas herramientas de búsqueda, filtro e inspección.

Lo que Bitelio guarda: el cuerpo HTML analizado y sanitizado (recurriendo a texto plano cuando no hay HTML), los encabezados listados en el payload de evento de abajo, los veredictos de autenticación y spam, y el ID del mensaje.

Lo que no guarda: el mensaje original en bruto, los adjuntos, los encabezados de hilo (In-Reply-To, References), o cualquier encabezado más allá de los del evento. Cuando necesites eso, haz que el flujo de trabajo disparado reenvíe el correo a tu propio servicio mediante un paso WEBHOOK.

El evento email.received

El evento aterriza en el registro de contacto del remitente (creado sobre la marcha si es necesario), con el mensaje completamente analizado en su campo de datos:

La emisión es incondicional — los veredictos de spam, virus y autenticación nunca hacen que Bitelio retenga el evento. Cualquier filtrado corre por tu cuenta dentro del flujo de trabajo que dispara.

Dentro de plantillas y pasos de flujo de trabajo, estos campos viven bajo el espacio de nombres de variable de evento: {{event.subject}}, {{event.from}}, {{event.body}}, y así sucesivamente.

Construir flujos de trabajo sobre correo entrante

Respuesta automática

La respuesta automática más simple posible para support@yourdomain.com:

1. Disparador: email.received.
2. Condición: continuar solo si event.to es igual a support@yourdomain.com y event.spamVerdict == "PASS" y event.virusVerdict == "PASS".
3. Enviar correo:
   • Para: {{event.from}}
   • Asunto: Re: {{event.subject}}
   • Cuerpo: Thanks for your message. We've received your email and will respond within one business day.

Dale a la respuesta automática una plantilla TRANSACTIONAL para que no apliquen las comprobaciones de suscripción — los remitentes se suscriben automáticamente, pero si uno se da de baja después, tu respuesta debería seguir saliendo.

Enrutamiento por destinatario

Un flujo de trabajo puede repartir distintas direcciones hacia distintas acciones:

1. Disparador: email.received.
2. Condición: ramifica sobre event.to:
   • support@… → webhook de tickets → respuesta automática.
   • sales@… → webhook de CRM → notificar Slack.
   • billing@… → webhook del sistema de facturación.

Reenviar a tu API

Cuando el procesamiento necesita más de lo que Bitelio ofrece (clasificación NLP, creación de tickets, adjuntos que Bitelio no captura), entrega el correo a tu propio backend:

1. Disparador: email.received.
2. Webhook:
   • URL: https://api.example.com/inbound
   • Método: POST
   • Cuerpo:

     {
       "from": "{{event.from}}",
       "subject": "{{event.subject}}",
       "body": "{{event.body}}",
       "messageId": "{{event.messageId}}",
       "timestamp": "{{event.timestamp}}",
       "verdicts": {
         "spam": "{{event.spamVerdict}}",
         "virus": "{{event.virusVerdict}}",
         "spf": "{{event.spfVerdict}}",
         "dkim": "{{event.dkimVerdict}}",
         "dmarc": "{{event.dmarcVerdict}}"
       }
     }

Filtrar spam y virus antes de procesar

Adopta el hábito de colocar un paso CONDITION cerca del inicio de cada flujo de trabajo de correo entrante que descarte mensajes cuyo spamVerdict o virusVerdict sea FAIL — Bitelio no hace ningún prefiltrado en tu nombre.

Dominios en múltiples proyectos

Cuando varios proyectos han verificado el mismo dominio, cada correo entrante se reparte a todos ellos — cada proyecto obtiene su propio registro Email, upsert de contacto, y evento email.received. Eso es intencional: permite que staging y producción compartan una bandeja de entrada, o que varios equipos consuman el mismo flujo de entrada.

Para evitar el reparto, mantén el dominio verificado en un solo proyecto a la vez.

Facturación

Cada correo recibido consume 1 crédito del uso de correo de tu proyecto, exactamente igual que un envío saliente. Los niveles gratuito y de pago se nutren del mismo pool.

En Facturación → Límites puedes poner un tope por proyecto sobre el correo entrante. Cuando se alcanza el tope, el correo entrante de ese proyecto se descarta silenciosamente hasta que el tope se restablece — nada se pone en cola ni se reproduce después. Un tope en un proyecto no tiene efecto sobre otros proyectos verificados en el mismo dominio.

Consideraciones de seguridad

• Trata el cuerpo como entrada de usuario no confiable. La sanitización cierra las rutas obvias de inyección de scripts, pero los enlaces de phishing, el texto de ingeniería social y los caracteres unicode similares sobreviven a ella. Nunca renderices el cuerpo tal cual en tu propia interfaz sin escaparlo apropiadamente para ese contexto.
• Los veredictos de autenticación son informativos. Los resultados de SPF / DKIM / DMARC se registran en el evento, no se aplican. La política es tuya para definir — para bandejas sensibles (facturación, cambios de cuenta), rechazar correo no autenticado en el primer paso CONDITION del flujo de trabajo es una base razonable.
• Los remitentes se suscriben automáticamente. Todo remitente entrante se une a tu audiencia como contacto suscrito. Para excluirlos, termina el flujo de trabajo de entrada con un paso UPDATE_CONTACT que establezca subscribed: false.
• Riesgo de bucle de respuesta. Una respuesta automática dirigida a un dominio en el que también recibes (o a una dirección de lista) puede entrar en bucle indefinidamente. Prevénlo con una CONDITION que descarte mensajes cuyo event.from esté en tu propio dominio.

Limitaciones

• Solo catch-all: toda dirección en el dominio converge en el mismo manejador; distinguir destinatarios ocurre dentro del flujo de trabajo vía event.to.
• Sin adjuntos: el análisis los descarta. Reenvía a tu propio servicio si los necesitas.
• Sin MIME en bruto: el mensaje original no se conserva.
• Sin hilos: los mensajes entrantes no se agrupan en hilos ni se emparejan con respuestas salientes.
• Tope de 40 MB: cualquier cosa por encima de 40 MB se rechaza antes de que empiece el procesamiento.

Solución de problemas