决定客户应该看到哪些身份
WeFact 记录了两种发件人方法：默认的 mijnweFact 身份和从企业自己的电子邮件地址发送。默认方法带有公司名称，而回复则发送至其自己的地址。自定义地址发送需要域认证。不要将工作回复目标与自定义的经过身份验证的发件人域混淆。 WeFact 发送者方法.
在编辑DNS之前，请询问发票流程所有者确认预期的方法和地址。记录涉及哪个管理和域、谁可以编辑其设置以及谁控制权威DNS 。库存提醒、报价和其他出库工作流程分开。他们共享的品牌并不能证明相同的发件人设置。保留基线原始消息和以前的配置，以便可以在不中断应收账款的情况下撤消更改。
获取个性化设置文档
在管理中，打开 Instellingen，然后 SPF & DKIM。选择域名验证并下载个性化说明。让负责的DNS管理员发布指定的记录。公开文章不提供通用DKIM密钥或完整的通用DNS配方，因此本指南不会发明此类密钥。 WeFact 验证说明.
将下载的指令视为版本化更改输入。记录域、生成日期、确切的公共所有者名称、记录类型和值。如果文档指定的域与批准的发票地址不同，请在发布任何内容之前停止并更正配置。仅与管理员共享公共DNS设置信息，而不是邮箱密码或包含个人数据的不相关发票。
使DNS更改可审核
导出当前区域并识别现有的SPF策略。如果说明需要包含SPF ，请将适用的机制合并到评估的信封域的一个策略中，而不是创建另一条v=spf1记录。保留其他授权发件人。在批准之前验证语法和查找成本。 DKIM需要实际 选择器 以及为此域提供的公钥，而不是从其他管理部门复制的密钥。 SPF, DKIM.
检查DNS编辑器如何处理相对所有者名称和TXT引用。保存后查询权威服务，然后按照当前的WeFact验证流程进行。请勿在此更改中更改入站MX路由。保留现有的 DMARC 除非域中的所有发件人都需要单独审查策略更改，否则策略保持不变。
测试非客户发票工作流程
通过批准的测试流程创建无害的测试文档，并仅将其发送给受控收件人。避免仅仅为了检查邮件标题而创建真实的可收回发票或向客户发送付款提醒。捕获文档工作流程和收到的原件，因为预览使用的发送器可能与操作发送路径不同。
- 证据：管理；记录内容：批准的发件人方式和地址；验收问题：是否选择了预期的自定义身份？
- 证据：收到消息；记录内容：发件人、信封、所有DKIM d= 和 s= 值；验收问题：实际使用了哪个身份？
- 证据：接收器结果；记录内容： SPF 、 DKIM和DMARC结果；验收问题：传递方法是否一致？
- 证据：回复测试；记录内容：无害回复到达的目的地；验收问题：财务团队是否收到回复？
该矩阵是综合测试设计，而不是 一个记录 真实的 WeFact 消息。对于 From invoices@example.com ，经过验证的DKIM d=example.com是准确的 结盟 例子。发送给invoices@example.com的回复本身并不能证明这种一致性。 DMARC.
安全恢复业务流程
如果消息仍使用默认身份，请检查所选的发送方方法以及当前验证流程的完成情况。如果出现自定义发件人但不存在DKIM ，请在更改密钥之前将配置的域和选择器与消息进行比较。如果签名失败，请检查公钥位置和任何修改中继。保留经过编辑的示例以获取支持，而不是重复发送实时发票。
如果客户关键交付受到影响，请暂停相关发送工作流程或在财务所有者同意的情况下恢复之前批准的方法。重新检查回复以及身份验证。将个性化说明文档、 DNS快照、测试原件和验收签字保存在一起。当发件人地址、管理或DNS主机发生更改时查看它们。本指南是记录性的，并不要求进行实时 WeFact 验证或交付测试。
确认提供商边界
公共页面建立了两种发送方式和个性化文档工作流程，但没有通用选择器、当前帐户状态或自动切换规则。在管理员提供这些特定于帐户的事实之前，请明确保留这些事实未得到解决。下载域的验证是与批准发票发送不同的决定。
完成一个虚构的诊断案例
仅虚构的书面案例：WF-01 假设财务负责人选择了默认方法，并且收到了一张无害的测试发票，其中包含提供者域 From，而 Reply-To 为invoices@atelier.example 。 SPF和DKIM身份/结果未知。财务部门已成功回复，但未满足发件人要求的定制要求。财务所有者必须批准自定义方法，获取特定于域的设置文档并验证新的受控发票路径，而不会创建可收回债务。此案例没有测试任何帐户、 DNS 、CRM、发票、活动或交付。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。