航空公司行程变更和机场服务咨询在乘客收件箱中可能看起来相似，但它们具有不同的权限、截止日期和系统。不要将机场域名视为航空公司的可互换别名，或者假设旅行通知提供商可以代表这两者。第一个任务是确定消息是谁的以及谁操作该路由。
将权威性和紧迫性结合起来
该虚构地图将行程变更分配给乘客消息传递，将机场咨询分配给机场运营消息传递，将一般旅行通知分配给单独的服务所有者。对于每个路由，记录创建消息的事件、预期收件人、作者域和最近的有用接收时间。运营所有者（而不是通用电子邮件仪表板）必须定义该截止日期。
使用发明的飞行参考和明确标记的测试建议。请勿向乘客、操作人员或公共分发列表发送测试中断消息。仅在授权帐户和环境中进行端到端测试，并采用可防止合成警报被误认为真实操作指令的程序。
验证身份而无需领取送货
有效的对齐签名支持所声明的域身份。它没有显示该消息已从队列中逃脱、在出发前到达乘客手中或包含正确的登机口。在示例中，旅行通知供应商使用 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 独自的。这个十三分钟的例子只是证明了算术，而不是航空公司的准备情况。