Un restablecimiento de contraseña que llega después de que expire su enlace le ha fallado al cliente incluso si su autenticación es correcta. Un recibo que nunca llega al buzón previsto puede generar trabajo de soporte a pesar de una respuesta API exitosa de la plataforma de envío.
DMARC es una parte para hacer que el correo transaccional sea confiable. Cree la configuración de autenticación en torno al flujo de trabajo de cada cliente y luego mida las etapas que deciden si el mensaje sigue siendo útil.
Defina el servicio, no solo el dominio
Enumere los mensajes que envía el dominio: códigos de inicio de sesión, restablecimiento de contraseña, facturas, avisos de pago, recibos y cambios de cuenta. Registre el propietario de la aplicación, la cuenta de envío, la identidad de origen, la ruta de regreso, la identidad de firma y la ruta alternativa relevante.
Dé a cada flujo un resultado empresarial. Es posible que sea necesario que llegue un código de inicio de sesión antes de que caduque. Un recibo puede tolerar más demoras, pero aún requiere una referencia de transacción que se pueda buscar. Estos son sus objetivos de servicio, no promesas de entrega creadas por DMARC .
Usar el inventario del remitente para conectar esas expectativas con la configuración de envío real. Incluya regiones y cuentas de respaldo en lugar de asumir que la configuración del proveedor principal las cubre.
Verificar la identidad utilizada por cada ruta de aplicación.
Para obtener un mensaje representativo controlado, inspeccione el dominio De origen real, la identidad evaluada por SPF y cada DKIM dominio de firma. Verifique tanto la autenticación sin formato como la alineación relevante para DMARC .
Bajo RFC 9989 §5.3.5, uno pasando alineado SPF o la ruta DKIM puede satisfacer la condición DMARC a nivel de mensaje cuando existe una política aplicable. Participación total bajo RFC 9989 §8 Además, requiere SPF y DKIM alineados, informes y publicación de políticas. Bajo RFC 9989 §7.4, un dominio con política de rechazo no debe depender únicamente de SPF y debe aplicar firmas DKIM válidas.
Esa distinción es importante cuando una plataforma en la nube devuelve un estado amplio de "autenticado". Una página de configuración de dominio no establece que la cuenta de la aplicación, la región de producción y el tipo de mensaje utilizaron la identidad esperada en el mensaje probado.
Siga una transacción a través de sus hitos
Mantenga separados el evento de solicitud, el envío y la evidencia del receptor. Un proveedor que acepta una solicitud API no es el mismo evento que un receptor SMTP que acepta el mensaje después de la transmisión. Finalización positiva después del final de la responsabilidad de entrega de las transferencias de datos según RFC 5321 §4.2.5; La aceptación del receptor no prueba la ubicación, visualización o lectura de la bandeja de entrada.
Esta prueba ficticia utiliza una vida útil del enlace de reinicio de cinco minutos elegida por la aplicación de ejemplo:
- Hora UTC: 12:00:00 ; Hito: solicitud de reinicio creada; Significado: la aplicación inicia la transacción
- Hora UTC: 12:00:02 ; Hito: la plataforma de envío acepta el envío; Significado: el envío se realizó correctamente en el límite de esa plataforma.
- Hora UTC: 12:00:20 ; Hito: el servidor destinatario acepta el mensaje después de DATOS; Significado: la transferencia SMTP a ese receptor se realizó correctamente
- Hora UTC: 12:00:27 ; Hito: el buzón de prueba controlado expone el mensaje; Significado: disponibilidad observada para este destinatario de prueba
- Hora UTC: 12:05:00 ; Hito: el enlace de reinicio caduca; Significado: fecha límite de utilidad de la solicitud.
El mensaje de prueba estuvo disponible cuando faltaban cuatro minutos y treinta y tres segundos. Esta es una observación en la prueba ficticia, no un punto de referencia ni una garantía para cada cliente.
Si un receptor pospone temporalmente el mensaje hasta las 12:06, una entrega exitosa posterior aún no cumpliría con la fecha límite de este flujo de trabajo. El incidente debe registrarse como un fallo de caducidad incluso si el mensaje final pasa DMARC .
Conservar pruebas suficientes para localizar el retraso.
Utilice un identificador de transacción que pueda coincidir con los registros de la aplicación y el servicio de envío. Registre el texto SMTP devuelto, los eventos de la cola y los encabezados de mensajes recibidos disponibles. Mantenga los tiempos en una zona horaria consistente.
No infiera un rechazo DMARC a partir de una queja de un cliente retrasada. Los fallos de autenticación, los aplazamientos temporales, el filtrado local, los problemas de dirección y los errores de aplicación necesitan diferentes soluciones. Para un rechazo, la respuesta completa devuelta y el evento de la plataforma de envío pueden ser la evidencia disponible porque no existe ningún mensaje entregado.
Para una prueba realizada, los resultados del receptor confiable dentro del límite descrito por RFC 8601 §7.1 puede mostrar autenticación y alineación. Limitar las muestras y registros retenidos a lo que necesita la investigación; un token de reinicio o el contenido completo del mensaje no se deben copiar casualmente en un ticket compartido.
Pruebe la ruta que el cliente realmente podría usar
Un buzón de prueba directo es útil, pero no representa todas las rutas de los destinatarios. Los clientes pueden proporcionar direcciones de reenvío o alias basados en roles. La manipulación indirecta puede alterar la fuente de conexión vista por SPF o cambiar el material relevante para DKIM .
Utilice pruebas representativas para rutas importantes para su población de clientes e investigue fallas reales. Un dominio exclusivamente transaccional puede estar más controlado que un dominio de correspondencia del personal, pero los destinatarios aún pueden introducir la entrega indirecta.
Los requisitos actuales de la política de rechazo hacen que la firma DKIM válida sea esencial; no garantizan que todos los mensajes reenviados se verifiquen o lleguen. La guía de selección de políticas explica cómo evaluar la compensación resultante.
Definir una recuperación que no multiplique la confusión
Diseñe el reintento de la aplicación y la recuperación de cara al usuario en torno a su propio modelo de caducidad. Para un enlace de reinicio, decida cómo un token recién emitido afecta al token anterior y qué ve el usuario si los mensajes retrasados llegan fuera de orden. Esas opciones pertenecen al equipo de aplicación.
Mantenga una ruta de conmutación por error del proveedor sujeta a la misma verificación de identidad que la ruta principal. Una copia de seguridad que comienza a enviarse con una identidad no relacionada puede crear un incidente de autenticación durante un incidente de disponibilidad.
No mueva silenciosamente el dominio afectado a una política más débil como sustituto de investigar la ruta. Si es necesaria una restauración de política, autorice su alcance exacto, conserve el historial de configuración y vuelva a probar el flujo crítico.
Supervisar los resultados por tipo de mensaje
Separe los resultados de reinicio, facturación y recibo en lugar de informar un único número de éxito para todo el dominio. Revise los retrasos, los aplazamientos, los rebotes y las pruebas de autenticación disponibles con respecto al resultado definido del servicio.
Informes DMARC agregados bajo RFC 9990 §3.1 ayudar a identificar patrones de autenticación observados. No proporcionan un recibo de entrega en tiempo real para cada transacción. Combínelos con la evidencia de la aplicación y del servicio de envío sin afirmar que una fila del informe demuestre que un usuario en particular recibió un correo electrónico en particular.
El registro operativo terminado debe mostrar quién es el propietario del flujo, qué identidades utilizó, dónde fue aceptado o retrasado y si cumplió con el plazo del cliente. DMARC aporta evidencia de dominio verificada a ese registro; el servicio tiene éxito cuando la tarea real del cliente tiene éxito.
Mantenga la siguiente acción específica
En el dispositivo de reinicio, 12:05:00 menos 12:00:27 deja 273 segundos, o 4 minutos 33 segundos, de utilidad. La disponibilidad a 12:06:00 sería 60 segundos después del vencimiento, incluso si se supera la autenticación. Registre la etapa de retraso y el fallo de caducidad de la aplicación por separado. Estos cálculos describen las entradas ficticias, no el rendimiento de entrega medido ni la vida útil recomendada del token.