市场可以在没有被授权验证商家域名的情况下传递商家的话语。区分业务内容的编写者、发件人中显示的域以及邮件流由哪个服务运行。这些角色可能属于三个不同的团体。熟悉的商家显示名称并不能解决域名身份问题。
选择预期的作者身份
对于平台发起的订单通知，应使用平台认可的身份，并在内容中明确商家关系。对于商家品牌路由，请在启用之前验证商家域的控制权以及身份验证所需的特定委托。请勿接受商家输入的域名作为控制权证明，或将其他卖家的配置复制到新租户中。
工作地图将平台订单通知、商家响应和支持更新分开。将每个项目分配给指定的集成或服务所有者。记录发件人是平台所有还是商户所有，哪个租户可以触发邮件以及谁可以轮换或撤销签名配置。回复地址可以直接与商家进行对话，而无需将该地址设为 DMARC 作者身份。
测试允许的和未对齐的情况
虚构的商人案例在 From 中显示了 seller.test，同时签名为 market.test。即使假设签名已验证，它也无法严格通过 DKIM 结盟 与卖家.测试。路线图中的平台顺序和支持标识与其各自的From域相匹配；这些是假设的配置，而不是观察到的测试。这说明了为什么平台成功签名本身并不授权使用卖家的身份。
选择诚实支持的设计：具有明确商家属性的平台拥有的发件人，或经过正确验证的商家域配置。后者需要记录的权限和范围内的访问权限。记录批准的租户、域名、 选择器、 DNS证明和撤销所有者。这些是评估系统的建议，而不是声称特定市场或EmailAuth实现了它们。
在验收测试中保持租户的权威
加密通行证无法揭示是否允许错误的卖家帐户选择域名。添加负面应用测试：第二个商家不得作为第一个商家发送，过期的委托不得保持可用，删除商家必须关闭相关发送路径。仅在授权的测试环境中运行此类测试，并将实际系统结果与这些假设身份分开保存。
将共享 IP 盘点为基础设施证据，而不是商家身份。一个平台系列可以承载许多租户，包括受损的租户。不要仅仅因为一个订单通知是合法的就将该范围内的所有消息列入白名单。
规划关系的结束
定义当商家离开时如何处理排队消息、回复和公开支持对话。撤销确切的授权而不干扰无关商户。仅保留平台有权保留的报告和审计证据。消费者信息披露、商家合同、数据共享条款和支付责任需要经过合格审查； DKIM和此路线图都不会裁定它们。
虚构的路线图
以下显式身份是说明性输入，而不是真实的客户配置。这些域和负责的角色是假设的，而不是客户批准或提供的签名消息。未执行任何加密测试或交付。
- 平台订单通知：平台消息引导；来自订单.市场.测试；信封和DKIM签名者 order.market.test。
- 商户留言：商户整合引领；来自卖家.测试；信封和DKIM签名者 market.test。
- 平台支持：客户支持主导；来自支持.市场.测试；信封和DKIM签名者 support.market.test。
签署结果前检查补助金
假设商家 A 已批准范围域配置，但商家 B 可以通过平台的发件人选择器选择它。生成的邮件上正确对齐的签名不会修复该应用程序授权失败。保持路线，保留允许的诊断证据，并使用授权的测试帐户测试实际的租户/对象边界。不要仅仅为了演示问题而发送实时冒充消息。
OWASP 的多租户指南，第 1、3 和 5 节，支持受信任的租户上下文和资源授权，包括延迟工作。 RFC 9989第 4.4 节和 5.3.5 节 将DKIM对齐与完整消息判决区分开来：必须评估其他对齐的身份验证路径。第 7.4 节和第 8 节要求有效的DKIM p=reject 部署而不是依赖 SPF 独自的。未执行商户授予、选拔测试或签约操作。