Recepción de correo electrónico

El correo recibido está disponible en Email > Emails > Receiving, a través de la API de inbound-messages y en webhooks email.received. Elige entre dos métodos de configuración según la dirección en la que quieras recibir correo.

• Una dirección de reenvío es un buzón que generamos para ti, como mfzxq2lom5uxi3lb@eu1.inbound.bird.com (@us1.inbound.bird.com en la región de EE. UU.). Sin dominio, sin DNS: configuras una regla de reenvío en tu bandeja de entrada existente apuntando a esa dirección, y recibimos cada mensaje que reenvía.
• Recepción en tu propio dominio publica registros MX para un subdominio que controlas (por ejemplo, inbound.acme.com), tras lo cual el correo enviado a cualquier dirección en ese subdominio llega como mensaje entrante.

Comienza con una dirección de reenvío si quieres probar la recepción o reenviar el correo de una bandeja de soporte existente. Configura la recepción por dominio cuando quieras que el correo llegue directamente a tu propio dominio.

Direcciones de reenvío

En Email > Domains > Forwarding, selecciona Add forwarding address e introduce un nombre como Support inbox. Generamos una dirección fija y aleatoria. Puedes renombrar su etiqueta más adelante. Eliminar una dirección de reenvío detiene el correo hacia esa dirección sin afectar a las demás.

De forma programática, POST /v1/email/inbound-addresses hace lo mismo (CLI: bird email inbound-addresses create). La respuesta contiene la address generada, su id y tu etiqueta.

Después, configura esa dirección como destino de reenvío donde resida el correo actualmente: una regla de reenvío de Gmail o Google Workspace, una regla de Outlook o la configuración de reenvío de tu helpdesk. Recibimos lo que se reenvíe, lo analizamos y lo almacenamos como mensaje entrante.

Recepción en tu propio dominio

La recepción por dominio es una función de un dominio de envío, así que el dominio debe estar registrado y verificado con DKIM primero. Usa un subdominio dedicado (inbound.acme.com), nunca tu apex: la recepción se habilita en el propio registro del dominio, y los registros MX en el apex capturarían tu correo corporativo.

Abre Email > Domains y selecciona tu dominio. En Receiving (Optional), activa la recepción y publica los registros MX indicados. No puedes habilitar la recepción hasta que DKIM esté verificado. Un dominio que ya recibe correo para otra organización tampoco está disponible.

Una vez habilitado, el estado de recepción sigue el mismo ciclo que los registros de envío: pending mientras comprobamos en DNS los registros MX, y luego verified cuando resuelven correctamente. A partir de ese momento, el correo enviado a cualquier parte local del dominio (support@, orders@, lo que sea) se entrega como mensaje entrante. Desactivar el interruptor detiene la entrega de correo entrante. Los registros MX permanecen listados en el dominio como referencia, con su estado de vuelta en pending.

Tamaño del mensaje entrante

Bird admite mensajes entrantes de hasta 20 MB, adjuntos incluidos, en cada dominio de recepción en cada región. Los mensajes más grandes quedan fuera del límite admitido, incluso si el servidor de envío recibe una respuesta de aceptación SMTP. No confíes en su entrega.

Un mensaje que exceda el tamaño puede ser rechazado durante la transacción SMTP con 552 5.3.4 message size limit exceeded. El servidor de envío recibe este rechazo y puede notificar a su remitente. Bird nunca trunca un mensaje para ajustarlo a un límite de tamaño.

Lectura de lo que recibes

La pestaña Receiving lista los mensajes recibidos del más reciente al más antiguo, con remitente, destinatario, asunto y hora de recepción. Busca por dirección exacta del remitente o filtra por fecha. Selecciona una fila para abrir las vistas Rendered, Text, Details y Raw. El encabezado muestra los resultados de SPF, DKIM y DMARC registrados cuando llegó el mensaje.

Los correos recibidos se conservan durante 30 días.

Los mismos datos están disponibles a través de la API (CLI: bird email inbound-messages):

• GET /v1/email/inbound-messages lista mensajes, filtrables por remitente, dirección de entrada y hora de recepción.
• GET /v1/email/inbound-messages/{id} devuelve los metadatos analizados de un mensaje: direccionamiento, asunto, referencias de hilo, resultados de autenticación y metadatos de adjuntos.
• GET /v1/email/inbound-messages/{id}/body devuelve los cuerpos HTML y de texto plano.
• GET /v1/email/inbound-messages/{id}/attachments lista los adjuntos; cada uno se puede descargar individualmente.
• GET /v1/email/inbound-messages/{id}/raw devuelve el mensaje original tal como se recibió, en formato RFC 5322 (MIME).

Reacción al correo recibido: el webhook email.received

Para procesar el correo a medida que llega (enrutar solicitudes de soporte, procesar respuestas, activar un agente), suscribe un endpoint de webhook al evento email.received. Lo disparamos después de recibir y analizar cada mensaje. El payload incluye el inbound_message_id, el remitente del encabezado From del mensaje, los destinatarios, el asunto y la referencia in_reply_to. También incluye un veredicto general authentication (pass, fail o unknown) y los resultados individuales de SPF, DKIM y DMARC; Uso de resultados de autenticación explica cuáles están disponibles hoy. Esta información permite enrutamiento y triaje sin una llamada adicional. Cuando necesites el cuerpo o los adjuntos, consúltalos con la API de inbound-messages usando el inbound_message_id del evento. El mensaje se almacena antes de enviar el evento, así que ese id se resuelve en cuanto el evento te llega: consulta /raw o /body directamente desde tu handler, sin espera ni polling.

Uso de los resultados de autenticación

SPF y DKIM se verifican cuando un mensaje llega a Bird. Los encabezados que añade el remitente, como su propio Authentication-Results, no alteran estos resultados.

Los campos spf_pass y dkim_pass son cada uno true, false o null. null significa que no se registró ningún resultado, incluso cuando una verificación no pudo completarse. Una firma DKIM válida hace que dkim_pass sea verdadero aunque otra firma en el mensaje falle. Los campos no exponen tokens de resultado detallados, dominios de firma ni selectores.

Los resultados de DMARC aún no están disponibles. Hasta que lo estén, dmarc_pass y spam_score son siempre null, y authentication, que sigue a dmarc_pass, es siempre unknown. No enrutes basándote en dmarc_pass === true ni authentication === "pass" hoy: ningún mensaje cumple ninguna de las dos condiciones.

Para controlar el enrutamiento automático ahora, exige dkim_pass === true o spf_pass === true, y trata false, null y los valores ausentes como no verificados. Los pases de SPF y DKIM no confirman que el dominio firmante o remitente coincida con el dominio en el encabezado visible From. Úsalos para filtrar correo no autenticado, no como prueba de quién lo envió.

DMARC comprueba la alineación con el dominio en el encabezado From del mensaje. El campo from en email.received contiene esa dirección del encabezado, con el remitente analizado del relay y luego el remitente del sobre como respaldos cuando el encabezado no se puede leer. En email_mailbox.message_received, from contiene el remitente del sobre, que puede ser una dirección de rebote diferente. Para enrutamiento de buzón que usa el remitente visible, consulta los metadatos del mensaje recibido usando el message_id del evento. Un pase de DMARC autentica un dominio; no establece que una persona concreta haya enviado el mensaje.

Siguientes pasos

• Dominios de envío: registra y verifica el dominio en el que quieres recibir correo.
• Webhooks: endpoints, firmas y reintentos para email.received.
• Superagent: puntúa el correo recibido antes de que un agente actúe sobre él.
• Registro de correo: el lado de envío de la página Emails.