范围和特定于提供商的配置
Stripe 自定义电子邮件域涵盖客户电子邮件，例如发票、收据和付款失败通知。默认发件人域是stripe.com 。这不是更换邮箱托管或将整个公司的外发电子邮件移至 Stripe 的指南。
在仪表板客户电子邮件设置中，添加您希望 Stripe 使用的域。检索生成的DNS记录。 Stripe 区分所有权 TXT记录, 来自域的邮件 CNAME 对于包络源和 SPF 政策，以及 DKIM CNAME记录。每个都有不同的目的；单独的所有权TXT并不能证明消息经过身份验证。在适用的情况下使用仅限 DNS 的记录：Stripe 明确表示不要通过Cloudflare代理提供的记录。
在权威DNS服务上发布每个确切的所有者、类型和目标。检查编辑器是否未两次附加域。分配CNAME所有者不得保留冲突的记录类型。使用验证客户电子邮件中的域来缩小验证问题的范围。 Stripe 最多允许 72 小时进行确认，但建议在验证失败时检查拼写错误、冲突和实际DNS发布。
条纹需要一个 DMARC 自定义电子邮件域的策略并明确规定严格的SPF 结盟 不受支持：其文档针对aspf=s.不要默默地放松组织既定的政策。如果域已经需要严格对齐，请从其邮件/安全所有者那里获取设计决策，可能使用适当管理的单独发送域。仍必须对收到的邮件进行DKIM对齐检查；产品限制并不是假设任何签名都会对齐的理由。
验证域后，使用溢出菜单发送测试电子邮件并确认活动的发送域。回复将发送至公共业务信息中的支持地址，因此请与身份验证分开测试该目的地。保留所有生成的记录：Stripe 反复检查它们，并表示未解决的无效或丢失记录会导致在 48 小时纠正窗口后回退到stripe.com 。要停用某个域，请先切换发送，在客户电子邮件设置中将其删除，然后仅删除其未使用的DNS记录。
重要的决定
Stripe 的严格 SPF 对齐限制和回退行为必须是明确的接受标准。
验证发布记录和真实发送路径
在编辑之前记录变更所有者、发送产品、域、批准的维护时段和先前的DNS答案。从指定帐户或记录的提供商工作流程获取当前记录值。将提供商提供的值与您的组织控制的选择（例如DMARC策略和报告收件人）分开。现有邮箱MX 、不相关的验证TXT记录和活动DKIM选择器不会仅仅因为添加新服务而成为清理候选者。
发布后查询每个确切所有者和记录类型的权威名称服务器。记录查询时间、响应服务器和完整答案。将TXT字符串作为一个逻辑值进行比较，其中DNS响应将它们拆分为字符串。检查CNAME目标以及起始别名。然后比较递归解析器答案以识别缓存差异。成功的提供者验证是配置的有用证据，但它并不能确定实际接收者收到的内容。
使用预期产品路线仅将授权测试发送给受控收件人。保留原始消息和可信接收系统的 Authentication-Results。记录可见的发件人域、 SMTP 邮件来自 或观察到 Return-Path 域、每个DKIM d= 和 s= 值、 SPF和DKIM结果以及接收者的DMARC结果。仅当其经过身份验证的域与适用策略下的可见发件人域一致时，通过SPF或DKIM检查才支持DMARC 。回复和品牌显示名称不是联盟身份。 RFC 7208 、 RFC 6376和 RFC 9989 为这些区别提供协议基础。
验收工作表、恢复和证据限制
这是原始验收工作表，而不是现场测试报告。将每个门标记为待处理，直到证据存在：账户范围已确认；先前捕获的DNS ；发布确切的新所有者/类型/值；提供商验证完成；预定的行使路线；收到记录的身份信息；已确认一致的身份验证；其他发件人不受影响。为每个门分配一个人和证据文件。即使提供商仪表板为绿色，红色门也会阻止推出。
如果测试失败，首先区分丢失的发布、过时的缓存数据、不活动的提供程序配置、错误的出站路由和未对齐的身份验证。纠正所显示的最小缺陷并再次测试。不要仅仅为了通过一项测试而削弱DMARC或删除其他发件人的记录。如果更改损害了现有邮件，请使用批准的恢复计划和捕获的更改前配置，协调任何提供商端发件人更改以及DNS 。当排队的消息或批准的重叠仍然需要旧密钥时，请保留旧密钥。
此稿件没有可用的客户租户、更改前后的权威信息或真实收到的消息。保留的资源支持文件工作流程；他们不满足委托的现场证据门。独立检查员审查和人类中小企业批准仍有待确定。请勿将本指南描述为经过现场验证或将其发布为已通过这些门槛。
将协议结果与支持的设置分开
书面案例 ST-01 假设receipts@example.com ，MAIL bounce@bounce.example.com具有受信任的SPF通行证，并且通过 DKIM签名 d=example.com, s=demo1. Under aspf=s the SPF identity is not an exact match, while that DKIM signature still supplies an aligned DMARC path. This protocol example does not make aspf=s a supported Stripe configuration: its current documentation expressly says otherwise. If the owner must retain strict SPF alignment on the shared domain, stop the rollout and obtain a separately governed design decision rather than silently changing policy. Also verify the approved reply destination independently. No Stripe configuration, invoice, receipt or payment action was performed.
保留执行边界
RFC 9989第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。