选择Postmark路线和身份
本指南涵盖实际提交到Postmark出站邮件，而不是仅使用Postmark进行入站处理的网站。记录应用程序、 Postmark服务器和邮件流、预期发件人域以及DNS管理员。由不同应用程序发送的收据必须单独进行测试，即使其品牌看起来相同。在更改DNS之前，请保存现有记录和来自确切工作流程的基线消息。
Postmark的域验证工作流程提供了 DKIM TXT记录 和定制 Return-Path CNAME。经过验证的域允许从整个域中的地址发送，因此域验证应由授权代表它的团队拥有。使用为您的域显示的值，而不是来自其他租户的值。 Postmark域验证.
在更改策略之前启用签名
打开发件人签名，选择域并输入DNS设置。将DKIM主机名和值复制到权威DNS提供商处的TXT记录。检查DNS编辑器是否附加了区域名称；重复的后缀会将密钥放在错误的位置。返回Postmark并验证记录。 Postmark文档在 48 小时内自动检查并进行手动验证控制。审核通过后开始签名。 DKIM设置.
不要将绿色状态视为最终验收测试。它确定提供者发现 一个记录，并不是说您的生产应用程序使用了预期的发件人地址，也不是后来的网关保留了签名。在验证后安排受控发送并保留接收者的原始消息，包括所有DKIM签名。
单独添加支持的Return-Path
使用同一域设置中显示的Return-Path主机名及其CNAME目标，记录为pm.mtasv.net 。为此目的保留未使用的主机名。请勿放置 SPF TXT记录与CNAME具有相同的所有者名称，并且不要将您的顶点记录替换为退回CNAME 。 Postmark文档显示不同的默认主机名拼写，因此真实帐户值优先于复制的示例。 域名验证.
Postmark不要求将其包含在客户的顶点中 SPF记录。 SPF检查遵循实际的信封域。添加顶点包含无法将提供商拥有的Return-Path转换为客户拥有的返回路径。记录的自定义Return-Path是一个子域； Postmark建议宽松的SPF 结盟 对于这条路线。严格的SPF要求并不能通过添加更多包含物来解决。保留域批准的策略并在适当的情况下使用经过验证的一致DKIM路径。 Postmark SPF指南.
证明申请结果
以下是综合验收设计，而不是捕获的交付。将每个示例替换为观察到的值，并保留测试的时间戳和消息 ID。
- 证据：可见；说明性价值： receipts@example.com ；受理问题：这是批准的申请身份吗？
- 证据：信封域；说明性价值： pm-bounces.example.com ；接受问题：此消息是否激活了自定义Return-Path ？
- 证据： DKIM签名域；说明价值： example.com ；接受问题：受信任的接收者是否验证了该签名？
- 证据： DMARC;说明值：通过；验收问题：哪种对齐传递方法产生了这个结果？
- ra 从example.com域及其下的跳出子域中，宽松的SPF对齐可以起作用，而严格的SPF对齐则不起作用。精确域传递 DKIM签名 还是可以满足DMARC 。评估观察到的签名，而不是承诺每条消息都已签名。 DMARC对齐.
通过各自的应用程序路径测试真实收据和密码重置事件。比较它们的流和发送器配置。如果一个通过而另一个失败，请在更改共享DNS之前调查不同的路由。请勿将真实的财务收据重新发送给客户作为测试。
诊断和恢复
如果DKIM不存在，请确认应用程序的发件人域与已验证的域匹配并且签名处于活动状态。如果签名存在但失败，保留接收者的原因并检查确切的签名 选择器 查找和任何内容修改中继。如果SPF通过但未对齐，请检查Return-Path激活而不是添加顶点权限。如果DNS验证失败，请将权威答案、完整主机名和记录类型与帐户的值进行比较。
如果接受失败，则仅暂停受影响的应用程序流。通过更改所有者恢复保存的记录或发件人设置，然后重新测试受控事件。当排队的邮件可能仍需要旧的选择器时，请勿删除它。仅在确认没有其他Postmark应用程序共享未使用的退回委托和签名记录后，才停用这些记录。本手稿基于文档；没有测试租户、 DNS更改或实时交付。
明确比较严格和宽松的结果
对于书面案例 PM-01，假设来自receipts@example.com ， 邮件来自 bounce@pm-bounces.example.com和pm-bounces.example.com的可信SPF通行证。在普通的同组织域宽松对齐下， SPF路径对齐；使用aspf=s它与example.com不完全匹配。单独假设传递签名d=example.com, s=demo1:该路径完全对齐，即使在严格 SPF 情况下也能满足DMARC 。如果DKIM变得未知而不是通过，则不要根据先前的前提保留通过。这些是规定的输入，而不是捕获的Postmark投递或削弱政策的建议。
保留执行边界
对于发布p=reject, RFC 9989第 7.4 节要求有效的DKIM而不仅仅是SPF ，并就间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。