Un restablecimiento de contraseña tiene que llegar mientras su enlace aún funciona. Un recibo tiene que describir el pedido correcto sin volver a aparecer tras un reintento.
Esos requisitos comienzan en tu aplicación y continúan después de que el servicio de correo acepta el mensaje.
¿Qué debe contener un mensaje transaccional?
Proporciona al destinatario la información o la acción necesaria para el evento que originó el correo. Un recibo confirma un pedido. Un mensaje de restablecimiento ofrece una forma de recuperar el acceso.
Usa un nombre de remitente reconocible. Escribe un asunto que identifique el evento. Dirige las respuestas a una dirección que tu equipo monitorice cuando el flujo necesite soporte.
Para un recibo ilustrativo, usa un asunto como Receipt for order 8472. Incluye la referencia del pedido, los artículos comprados y un contacto de soporte. Para un mensaje de restablecimiento, coloca la acción de restablecimiento primero e indica cuándo expira.
Prueba tanto el contenido HTML como el de texto plano. Comprueba que la acción principal sigue siendo comprensible en una pantalla estrecha y con las imágenes desactivadas.
Mantén las promociones separadas de los mensajes de cuenta necesarios. Correo transaccional frente a correo de marketing explica cómo el propósito del mensaje afecta los controles del destinatario y la política de envío.
¿Cómo debes autenticar y separar los remitentes?
Autentica el dominio de envío antes del tráfico de producción. Los requisitos de remitente de Gmail exigen SPF o DKIM para todos los remitentes hacia cuentas personales de Gmail. Los remitentes que superan los 5000 mensajes diarios necesitan SPF, DKIM y DMARC.
Usa identidades de envío separadas para correo operativo y de marketing. La guía de Yahoo recomienda separar el marketing masivo del tráfico transaccional por IP o dominio de firma DKIM. Ambos transportan señales de reputación, así que una dirección From diferente por sí sola no separa la infraestructura.
Incrementa el volumen de envío gradualmente. La guía de Google advierte contra picos repentinos. Revisa los aplazamientos y rebotes durante un aumento para poder reducir la tasa cuando los receptores tengan dificultades con el tráfico.
La lista de verificación de entregabilidad cubre el trabajo más amplio de autenticación y reputación de remitente.
¿Cómo debes gestionar las supresiones y preferencias?
Comprueba por qué un destinatario está bloqueado antes de decidir si otro envío es apropiado. Una baja de marketing y una dirección no entregable requieren acciones diferentes.
La política de categorías de Bird permite correo transaccional tras una baja exclusiva de marketing. Los rebotes permanentes, las supresiones manuales y una baja que cubra todos los mensajes bloquean ambas categorías.
Por lo tanto, una categoría transaccional no anula todas las restricciones del destinatario. Cuando Bird informa recipient_suppressed, inspecciona el registro de supresión y las preferencias del destinatario. Repetir el mismo envío no repara la dirección ni cambia esa política.
¿Cómo deben expirar los enlaces y códigos de restablecimiento?
Aplica la expiración en la aplicación que valida el enlace o código. El texto del correo no puede evitar que se acepte una credencial expirada.
OWASP, la comunidad de seguridad de aplicaciones, recomienda tokens o códigos de restablecimiento generados aleatoriamente con un período de expiración adecuado. También recomienda un solo uso. Invalida la credencial tras un uso exitoso para que el mismo mensaje no pueda autorizar otro restablecimiento.
Elige una duración para la acción de cuenta y muestra esa duración en el mensaje. Ten en cuenta el tiempo de espera en tu aplicación y en la entrega. Un correo recibido después de la expiración necesita una ruta para solicitar un nuevo restablecimiento.
Antes de reintentar un trabajo de restablecimiento no enviado, comprueba si su credencial sigue siendo válida. No extiendas la expiración de una credencial solo porque un intento de envío falló. De lo contrario, los reintentos pueden mantener la credencial utilizable más allá de la duración que elegiste.
Para las URL de restablecimiento, OWASP recomienda HTTPS y un dominio de destino de confianza. También recomienda limitar las solicitudes de restablecimiento por cuenta para evitar la inundación de la bandeja de entrada.
¿Cómo evitan los reintentos los envíos duplicados?
Mantén un registro duradero del evento de negocio y su operación de envío. Un evento de pedido repetido debe encontrar el trabajo de recibo existente en lugar de crear otro.
Usa la misma clave de idempotencia al reintentar la misma solicitud API tras una respuesta incierta. El contrato de idempotencia de Bird conserva una respuesta completada durante tres horas. Pasada esa ventana, otra solicitud con la misma clave puede crear otro mensaje.
Ese límite hace que tu propio registro de eventos sea necesario para reintentos más antiguos. Guarda el ID de mensaje devuelto junto al evento antes de dar el envío por completado.
Un aplazamiento de entrega es diferente de una respuesta incierta de API. Bird reintenta la entrega aplazada automáticamente. Crear otro envío por cada aplazamiento puede añadir mensajes duplicados mientras el original sigue en curso.
¿Qué debes monitorizar y alertar?
Rastrea cada mensaje esperado a lo largo del envío. Registra el resultado de cada destinatario. Mide si el usuario completa la acción prevista.
Los eventos de entrega de Bird distinguen aceptación, entrega, aplazamiento, rebote y rechazo. Entrega significa que el servidor receptor aceptó el mensaje. No confirma la ubicación en la bandeja de entrada ni la lectura.
Registra la hora del evento de negocio junto con la hora de envío y el resultado del destinatario. Para mensajes de restablecimiento, compara el tiempo transcurrido con la duración restante de la credencial. Mide los restablecimientos completados en tu aplicación. Un evento de seguimiento de apertura no demuestra que una persona leyó el mensaje.
Configura alertas en torno a los límites operativos del flujo:
- Los trabajos no enviados se acercan a su expiración.
- Los fallos superan tu rango habitual.
- El procesamiento de webhooks se retrasa.
Asigna un responsable que pueda actuar ante cada alerta.
| Fallo | Evidencia a inspeccionar | Responsable y siguiente acción |
|---|---|---|
| Sin envío tras un evento de pedido | Trabajo de aplicación y registro de evento | Equipo de aplicación: recuperar el trabajo faltante sin duplicar un envío existente |
| Destinatario suprimido | Motivo de rechazo, supresión y preferencias | Equipo de soporte o envío: investigar el bloqueo antes de otro intento |
| Aplazamientos de entrega en aumento | Eventos de destinatario y volumen de envío | Equipo de envío: inspeccionar las respuestas de los receptores y reducir un pico de tráfico |
| Restablecimiento expirado al llegar | Expiración de credencial y marcas de tiempo | Equipo de aplicación: investigar el retraso y ofrecer una ruta para solicitar uno nuevo |
| Entrega de webhook repetida | Identificador de webhook y registro de procesamiento | Equipo de aplicación: omitir el trabajo ya completado para ese evento |
Verifica las firmas de los webhooks antes de aceptar eventos. La guía de webhooks de Bird usa webhook-id para deduplicación, de modo que una notificación reintentada no repita el trabajo de tu aplicación.
¿Qué debes comprobar antes de enviar a través de Bird?
Prueba el flujo completo a través de envío, resultado del destinatario y recuperación de la aplicación antes de usarlo para mensajes de cuenta en producción.
- Verifica el dominio de envío. Comprueba que el tráfico operativo usa la identidad y el pool previstos.
- Publica la plantilla. Prueba los detalles del recibo o la acción de restablecimiento con parámetros representativos.
- Configura
category: "transactional"para contenido operativo. Aplica la política de supresión y preferencias documentada. - Conserva el registro del evento de negocio y la clave de idempotencia. Guarda el ID de mensaje devuelto por el endpoint de envío.
- Ejercita la gestión de fallos con el sandbox de correo. Sus resultados simulados pasan por las rutas normales de eventos y webhooks sin llegar a una bandeja de entrada real.
- Inspecciona la línea de tiempo por destinatario en el registro de correo. Confirma que tu aplicación gestiona los mismos resultados y dirige las alertas a sus responsables.