即使三个不同的应用程序发送了相同的徽标，患者也可能会在预约提醒、注册消息和门户访问电子邮件上看到相同的徽标。识别每条消息背后的服务。然后测试其电子邮件身份和使通知有用且安全的应用程序行为。
确定触发点和目的地
对于约会，记录哪个安排事件触发消息以及重新安排或取消如何影响排队的提醒。对于注册，记录负责将消息与预期人员匹配的应用程序。对于门户访问，请确定帐户服务和批准的链接或代码生命周期。在每个应用程序旁边保留实际的电子邮件提供商和租户，而不仅仅是门户网站地址。
记录发件人域、信封身份、 DKIM 域和 选择器 对于每条路线。将回复目标和批准的门户主机作为单独的字段进行检查。服务域下的有效签名并不能证明链接是安全的、当前的或供接收者使用的。相反，熟悉的门户 URL 并不能证明该电子邮件已获得授权。
使用虚构记录测试生命周期变化
创建批准的综合预约和登记案例。在测试环境允许的情况下执行新的预约、重新安排、取消、重复注册尝试和门户访问请求。确认实际显示哪些消息、应用程序是否抑制过时的提醒以及链接是否指向预期的测试门户。
对于帐户访问消息，请使用非功能性演示值或隔离的经批准的测试帐户。不要在一般身份验证证据中保留可用的患者访问链接或代码。延迟访问电子邮件可能会在其令牌过期时通过DKIM ；这是应用程序生命周期的结果，而不是身份验证缺陷的证据。
区分三种故障
如果DKIM失败或不存在对齐路径，邮件和服务团队应调查签名、身份和邮件更改。如果提醒的时间错误，调度所有者应调查事件版本和时区处理。如果邮件到达过时的地址，注册和身份识别团队应遵循批准的收件人更正流程。最后两个问题不要放松解决 DMARC 政策。
保留简短的测试记录，其中包含合成案例 ID、事件时间、发送者身份、观察到的身份验证、应用程序结果和所有者。使用最少的经过编辑的证据。 电子邮件标头 仍然可以包含个人地址和路由信息，因此请根据组织的访问和保留规则来处理它们，而不是假设标头是公开的。
定义接受决定
需要正确的发送身份以及每个消息系列的预期应用程序行为。仅凭签名通行证无法批准门户之旅。当提醒或访问通知失败时，与服务所有者确认批准的恢复路径，而无需创建未经批准的备用通信渠道。
下面的虚构地图故意为门户访问样本留下了不完全对齐的提供商域签名。其规定的加密有效性说明了为什么仅查找DKIM =pass 是不够的。生产准备需要实际的服务证据和适用的 SPF 或DKIM 结盟，不是书面前提。
在更换调度程序、注册更改、身份提供商迁移、新门户主机和发件人域更改后重新检查。包括小批量例外情况，例如取消的约会和恢复的帐户。这是一种操作验证方法，并不声称任何医疗保健平台或EmailAuth产品已经实施了这些控制。
检查书面路线账本
所有行都使用保留的虚构域、建议的所有者和规定的DKIM结果。选择器 demo1 是一个说明性标签，而不是已安装的密钥。 SPF结果、其他签名、 DNS策略发现、实际收到和应用成功未知。不提供密钥、签名消息、测试执行或交付证据。
- 约会：来自appointments.care.example ； 邮件来自 未知; DKIM d=appointments.care.example,选择器 demo1，假定通过；建议所有者 调度所有者。下一步操作：验证此租户支持的签名路径及其单独的应用程序接受标准。
- 注册：来自registration.care.example ；邮件来源不明； DKIM d=registration.care.example,选择器 demo1，假定通过；提议的所有者 注册所有者。下一步操作：验证此租户支持的签名路径及其单独的应用程序接受标准。
- 门户访问：来自access.care.example ；邮件来源不明； DKIM d=provider.example.net,选择器 demo1，假定通过；建议的所有者 身份服务所有者。下一步操作：验证此租户支持的签名路径及其单独的应用程序接受标准。
d= 与 From 完全匹配的假设传递签名为该假设消息提供了严格对齐的路径。不相关的 d= 不提供来自该签名的对齐路径。未知的SPF或其他签名会阻止后一种情况的总体失败判定。这些书面前提不建立实时配置或收件箱放置。
比较三个生命周期决策
在建议的测试租户中使用虚构的门户案例 P-02。格林威治标准时间 09:00 的约会版本 1 在发出排队提醒之前被取消：即使是规定的DKIM通行证也会留下调度缺陷。发送到错误合成帐户的注册消息是收件人映射缺陷。假定 GST 09:10 到期且在 09:12 GST 观察到的访问链接必须根据应用程序的到期规则进行评估；身份验证不会延长有效期。调度、注册和身份所有者各自记录他们的预期结果和单独的观察结果。这里没有提供这些观察结果，因此没有一个通过测试。请勿将实时令牌、患者链接或可用代码复制到证据包中。
保持证据边界明确
RFC 9989 第 4.4 节和第 5.3.5 节区分了认证和对齐；第 5.4 节将消息处理留给接收者策略。第 7.4 节要求有效的DKIM而不是单独的SPF来进行域发布 p=reject 并警告不要拒绝其用户向 Internet 邮件列表发帖的域。所涵盖的规范化字节决定了RFC 6376第 3.4–3.7 节和 6.1 节中的DKIM完整性。这两种机制都不能验证临床、教育或法律权威。收集实际部署的授权当前证据；这里的操作清单是建议，而不是特定管辖区的合规评估。