USAePay 定制品牌收据需要您控制的域。网关的“电子邮件发件人”选择会更改收件人所看到的内容，以便单独库存商家收据、发票和任何合作伙伴邮件流。请勿使用客户的真实交易作为身份验证测试或将付款详细信息放入诊断服务中。
配置自定义域身份验证
提供商文档include:spf.usaepay.com SPF。将其添加到现有适用的SPF策略中，在终端所有机制之前，而不是发布另一个 SPF记录。官方指南不鼓励维护 IP 列表副本，因为提供商地址可能会发生变化。
为了 DKIM，创建三个 CNAME 您的发送域下的记录：gps1。 _domainkey指向gps1._default.dkim.safewebservices.com ； gps2 和 gps3 遵循相同的编号模式。仅替换您自己的发送域部分，而不替换提供程序目标。该指南称 gps2 和 gps3 公钥是故意空出的储备以供轮换。即使密钥验证器标记为空目标，也要发布其委托；是否接受今天的信息取决于 选择器 实际使用过。 USAePay配置参考
该门户提供SPF和DKIM验证。将其用作配置检查，然后检查交付的测试收据。该文档称，未经身份验证的自定义品牌可以回退到safewebservices.com 。记录观察到的发件人地址，而不是假设交付的收据仍然带有您的品牌。如果您无法控制所需的域，请同意已批准的发件人身份，而不是伪造公共网络邮件地址。
提供商现在需要所有自定义发送域的这些身份验证记录，而不仅仅是批量活动。将旧验证示例中使用的公共示例 IP 视为诊断说明，而不是当前出口 IP 或实际发出的信封身份的证据。
验证DNS和真实的接收结果
在更改商家收据和发票发件人设置之前，导出现有DNS值、记录批准的差异并指定回滚所有者。确认DNS编辑器需要相对标签还是完全限定名称；加倍域名后缀会创建 一个记录 没有预期的验证者会发现。保存后查询实际所有者名称，包括任何CNAME目标，而不是依赖编辑器的成功横幅。
SPF必须在相关域中保留一项策略，并保持在 DNS 查询术语限制内 RFC 7208。添加包含本身并不建立 结盟。在下面 RFC 9989, DMARC 当至少一个成功的SPF或DKIM结果与适用模式下的可见发件人域一致时，通过。不需要将两种机制对齐作为标准强加的条件，并且不要将提供商域通行证误认为是对齐的客户域通行证。
将实际商家工作流程生成的无害测试收据发送到您控制的邮箱。保存接收系统的可信身份验证结果、可见发件人、信封身份、 DKIM d= 和 s= 值、时间戳和提供商状态。 DNS查找仅显示可用的密钥； RFC 6376 验证还评估接收到的消息的签名。使用非敏感内容并避免将完整的客户消息暴露给公共检查人员。
使用有界接受和回滚决策
仅虚构的书面诊断案例：UP-01 假设无害的收据旨在使用receipts@shop.example ，但其可见的发件人是noreply@safewebservices.com 。 SPF和所有DKIM身份/结果未知。交货不符合定制品牌要求。商家所有者必须检查网关身份和验证状态， DNS所有者必须在新的批准测试之前比较所有三个记录的委托。空的备用键本身并不能确定活动选择器的故障。此示例没有测试任何帐户、 DNS 、中继或消息。
如果测试失败，请在进行另一次更改之前将丢失的DNS 、错误的选择器、不活动的提供商配置、意外的路由和消息修改分开。每次批准的更正后重新测试相同的工作流程。不要削弱整个域的DMARC策略来隐藏单个发件人问题。在需要回滚的情况下，恢复批准的先前路由或发件人配置并保留关键记录，而排队的签名消息仍然需要它们。将测试证据和未解决的异常与域清单一起保存。在准备本指南时未执行租户访问、 DNS更改或实际发送。
保留可靠的验收记录
每个帐户、域和实质上不同的路由创建一行。记录企业所有者、 DNS所有者、更改参考、预期发件人、观察发件人、信封域和SPF结果、每个DKIM d= 和 s= 及其结果、适用的对齐模式、可信接收者和时间戳、提供商激活状态、放置观察、未解决的问题和下一步操作。将缺失值标记为未知，而不是将其视为通过或失败。车主仅接受有记录证据支持的预期路线和身份；否则保留该路线并遵循批准的恢复计划。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。