航空公司行程變更和機場服務諮詢在乘客收件匣中可能看起來相似，但它們具有不同的權限、截止日期和系統。不要將機場網域視為航空公司的可互換別名，或假設旅遊通知提供者可以代表這兩者。第一個任務是確定訊息是誰的以及誰操作該路由。
將權威性和緊迫性結合起來
這張虛構地圖將行程變更分配給乘客訊息傳遞，將機場諮詢分配給機場營運訊息傳遞，將一般旅行通知分配給單獨的服務所有者。對於每個路由，記錄建立訊息的事件、預期收件者、作者網域和最近的有用接收時間。營運所有者（而不是通用電子郵件儀表板）必須定義該截止日期。
使用發明的飛行參考和明確標記的測試建議。請勿向乘客、操作人員或公共分發清單發送測試中斷訊息。僅在授權帳戶和環境中進行端到端測試，並採用可防止合成警報被誤認為真實操作指令的程序。
驗證身分而無需領取送貨
有效的對齊簽章支援所聲明的網域身分。它沒有顯示該訊息已從隊列中逃脫、在出發前到達乘客手中或包含正確的登機口。在範例中，旅行通知供應商使用 notification-vendor.test 進行簽名，而 From 使用travel.fly.test。即使假設簽名有效，這些假設的域也無法嚴格通過 DKIM 結盟。這不是執行的身份測試或完整的 DMARC 判決。
在變更記錄之前，請檢查提供者記錄的身分選項和服務的帳戶所有權。將航空公司和機場域權限分開。機場營運團隊的批准並未授予從航空公司域發送的權限，即使這些組織在旅程中進行合作也是如此。
將及時性作為其本身的結果來衡量
SMTP允許在臨時失敗後重試。 RFC 5321，第 4.5.4 節，描述重試行為；這並不是一個電子郵件將在航空期限內完成的承諾。分別記錄事件建立、應用程式佇列退出、提供者接受和受控接收。即使身份驗證通過，在 10:00 創建的虛構事件，有用收據截止日期為 10:10，並且在 10:13 收到收據也會遲到。
計算結果是 10:13 減 10:00 = 十三分鐘，10:13 減 10:10 = 遲到三分鐘。這些是發明的時間戳，而不是執行的時鐘模型。它不會重現網路隊列或對任何航空公司進行基準測試。在實際測試中，記錄時鐘來源並考慮時間戳不確定性，而不是假裝所有系統共享準確的時間。
保留經批准的營運管道
當電子郵件延遲或不可用時，請使用組織既定的安全性和乘客通知程序。本指南不批准電子郵件作為安全關鍵控制措施，也不建議更換操作警報系統。在部署之前定義恢復擁有者，隔離失敗的通知路由並根據需要保留先前批准的配置。航空監管、無障礙環境、乘客權利和保留義務需要進行合格審查。身分驗證通行證既不是操作授權，也不是合規性證明。
虛構的路線圖
以下顯式身分是說明性輸入，而不是真實的客戶配置。這些網域和負責的角色是假設的，而不是客戶批准或提供的簽署訊息。未執行任何加密測試或交付。
- 行程變更：旅客留言引導；來自行程.飛行.測試；信封和DKIM簽署者 itinerary.fly.test。
- 機場營運警報：機場營運訊息傳遞；來自 ops.airport.test；信封和DKIM簽署者 ops.airport.test。
- 出行通知：出行通知引導；來自旅行.飛行.測試；信封和DKIM簽署者通知-供應商.測試。
保持遲發事件和補救措施可追溯
記錄通知的有用截止日期以及每個時間戳記的實際證據來源。如果時鐘或收貨觀察的不確定性足以影響決策，請保持這種不確定性可見，而不是斷言確切的交付效能。授權營運所有者必須選擇既定的回應；本文不創建安全程序或批准乘客外展。
RFC 9989第 4.4、5.3.5 和 5.4 節 不要將身份驗證變成時間或內容保證。評估所有相關的對齊路徑以獲得完整的訊息判決。為了 p=reject 部署，第 7.4 節和第 8 節需要有效的DKIM ，而不是 SPF 獨自的。這個十三分鐘的例子只是證明了算術，而不是航空公司的準備。