即使三個不同的應用程式發送了相同的徽標，患者也可能會在預約提醒、註冊訊息和入口網站存取電子郵件上看到相同的徽標。識別每條訊息背後的服務。然後測試其電子郵件身份和使通知有用且安全的應用程式行為。
確定觸發點和目的地
對於約會，記錄哪個安排事件觸發訊息以及重新安排或取消如何影響排隊的提醒。對於註冊，記錄負責將訊息與預期人員配對的應用程式。對於入口網站訪問，請確定帳戶服務和核准的連結或程式碼生命週期。在每個應用程式旁邊保留實際的電子郵件提供者和租戶，而不僅僅是門戶網站地址。
記錄寄件者域、信封身分、 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完整性。這兩種機制都不能驗證臨床、教育或法律權威。收集實際部署的授權當前證據；這裡的操作清單是建議，而不是特定管轄區的合規評估。