Los pacientes pueden ver el mismo logotipo en un recordatorio de cita, un mensaje de registro y un correo electrónico de acceso al portal incluso cuando los envían tres aplicaciones diferentes. Identifique el servicio detrás de cada mensaje. Luego pruebe tanto su identidad de correo electrónico como el comportamiento de la aplicación que hace que la notificación sea útil y segura.
Identificar el desencadenante y el destino.
Para las citas, registre qué evento de programación activa un mensaje y cómo una reprogramación o cancelación afecta los recordatorios en cola. Para el registro, registre la aplicación responsable de hacer coincidir el mensaje con la persona destinataria. Para acceder al portal, identifique el servicio de la cuenta y el enlace aprobado o el ciclo de vida del código. Mantenga el proveedor de correo electrónico y el inquilino junto con cada aplicación, no solo la dirección del sitio web del portal.
Registre el dominio De, la identidad del sobre, DKIM dominio y selector para cada ruta. Inspeccione el destino de la respuesta y el host del portal aprobado como campos separados. Una firma válida bajo el dominio de servicio no establece que un enlace sea seguro, actual o esté destinado al destinatario. Por el contrario, una URL de portal familiar no prueba que el correo electrónico haya sido autorizado.
Probar cambios en el ciclo de vida con registros ficticios
Crear casos sintéticos de nombramiento y registro aprobados. Ejercer una nueva cita, reprogramación, cancelación, duplicado de intento de registro y solicitud de acceso al portal cuando el entorno de prueba lo permita. Confirme qué mensajes aparecen realmente, si la aplicación suprime los recordatorios obsoletos y si los enlaces conducen al portal de prueba esperado.
Para mensajes de acceso a cuentas, utilice valores de demostración no funcionales o una cuenta de prueba aprobada y segregada. No conserve enlaces o códigos de acceso de pacientes utilizables en la evidencia de autenticación general. Un correo electrónico de acceso retrasado puede pasar DKIM mientras su token haya caducado; ese es un resultado del ciclo de vida de la aplicación, no una prueba de un defecto de autenticación.
Separar tres tipos de fracaso
Si DKIM falla o no existe una ruta alineada, los equipos de correo y servicio deben investigar los cambios de firma, identidad y mensaje. Si un recordatorio tiene una hora incorrecta, el propietario de la programación debe investigar las versiones del evento y el manejo de la zona horaria. Si el mensaje llega a una dirección desactualizada, los equipos de registro e identidad deben seguir el proceso aprobado de corrección del destinatario. No resuelvas los dos últimos problemas relajándote. DMARC política.
Conserve un breve registro de prueba que contenga el ID del caso sintético, la hora del evento, la identidad del remitente, la autenticación observada, el resultado de la aplicación y el propietario. Utilice evidencia redactada mínima. Encabezados de correo electrónico aún puede contener direcciones personales e información de enrutamiento, así que trátelas de acuerdo con las reglas de acceso y retención de la organización en lugar de asumir que los encabezados son públicos.
Definir la decisión de aceptación.
Requerir una identidad de envío correcta más el comportamiento esperado de la aplicación para cada familia de mensajes. Un pase de firma por sí solo no puede aprobar el recorrido por el portal. Confirme la ruta de recuperación aprobada con el propietario del servicio cuando fallen los recordatorios o las notificaciones de acceso, sin crear un canal de comunicación alternativo no aprobado.
El siguiente mapa ficticio deja intencionalmente la muestra de acceso al portal con una firma de dominio de proveedor que no se alinea exactamente. Su validez criptográfica estipulada ilustra por qué buscar solo DKIM =pass es insuficiente. La preparación para la producción necesita evidencia de servicio real y las normas aplicables. SPF o DKIM alineación, no la premisa escrita.
Vuelva a verificar después del reemplazo del programador, cambios de registro, migración del proveedor de identidad, nuevos hosts del portal y cambios en el dominio del remitente. Incluya excepciones de bajo volumen, como citas canceladas y cuentas recuperadas. Este es un método de verificación operativa, no una afirmación de que alguna plataforma de atención médica o producto EmailAuth ya implemente estos controles.
Inspeccionar el libro de ruta escrito.
Todas las filas utilizan dominios ficticios reservados, propietarios propuestos y resultados DKIM estipulados. El selector demo1 es una etiqueta ilustrativa, no una clave instalada. Se desconocen los resultados SPF , otras firmas, el descubrimiento de políticas DNS , la recepción real y el éxito de la aplicación. No se proporcionan claves, mensajes firmados, ejecución de pruebas ni pruebas de entrega.
- cita: De appointments.care.example ; CORREO DE desconocido; DKIM d=appointments.care.example, selector demo1, supuesto aprobado; propietario propuesto Propietario de programación. Siguiente acción: Verifique la ruta de firma admitida de este inquilino y sus criterios de aceptación de aplicaciones independientes.
- registro: Desde registration.care.example ; CORREO DE desconocido; DKIM d=registration.care.example, selector demo1, supuesto aprobado; propietario propuesto Registro de propietario. Siguiente acción: Verifique la ruta de firma admitida de este inquilino y sus criterios de aceptación de aplicaciones independientes.
- acceso al portal: Desde access.care.example ; CORREO DE desconocido; DKIM d=provider.example.net, selector demo1, supuesto aprobado; propietario propuesto Propietario del servicio de identidad. Siguiente acción: Verifique la ruta de firma admitida de este inquilino y sus criterios de aceptación de aplicaciones independientes.
Una firma de paso supuesta cuyo d= coincide exactamente con From proporciona una ruta estrictamente alineada para ese mensaje hipotético. Un d= no relacionado no proporciona una ruta alineada desde esa firma. SPF desconocido u otras firmas impiden un veredicto de fracaso general en este último caso. Estas premisas escritas no establecen ninguna configuración en vivo ni ubicación en la bandeja de entrada.
Compare tres decisiones sobre el ciclo de vida
Utilice el caso de portal ficticio P-02 en un inquilino de prueba propuesto. La versión 1 de la cita a las 09:00 GST se cancela antes de que se emita el recordatorio en cola: incluso un pase DKIM estipulado deja un defecto de programación. Un mensaje de registro dirigido a una cuenta sintética incorrecta es un defecto de asignación de destinatarios. Un enlace de acceso con un vencimiento supuesto a las 09:10 GST observado a las 09:12 GST debe evaluarse según las reglas de vencimiento de la aplicación; la autenticación no extiende la validez. Los propietarios de programación, registro e identidad registran cada uno su resultado esperado y una observación por separado. Aquí esas observaciones no se proporcionan, por lo que ninguna es una prueba aprobada. No copie tokens activos, enlaces de pacientes ni códigos utilizables en el paquete de pruebas.
Mantenga explícitos los límites de la evidencia
RFC 9989 Las secciones 4.4 y 5.3.5 distinguen autenticación y alineación; La sección 5.4 deja el manejo de mensajes a la política del receptor. La sección 7.4 requiere DKIM válido en lugar de SPF solo para la publicación de dominios p=reject y advierte contra el rechazo de dominios cuyos usuarios publican en listas de correo de Internet. Los bytes canonicalizados cubiertos determinan la integridad DKIM según RFC 6376 secciones 3.4–3.7 y 6.1. Ninguno de los mecanismos valida la autoridad clínica, educativa o legal. Recopilar evidencia actual autorizada para un despliegue real; Las listas de verificación operativas aquí son recomendaciones, no una evaluación de cumplimiento específica de la jurisdicción.