非营利组织的筹款平台、捐款处理者和志愿者协调员都可以使用不同的电子邮件身份以同一品牌进行发送。在更改身份验证策略之前，请确定谁可以授权每个流以及哪些故障会中断。收据丢失与时事通讯延迟不是同一事件，经过验证的捐赠请求并不能证明其目的地已获得批准。
将域中的信任与上诉中的信任分开
RFC 9989 通过一致的身份验证验证域的使用。它不批准筹款活动、验证付款目的地或确定帐户未被盗用。将活动签署和付款目的地验证保留在身份验证结果之外。工作人员应使用组织既定的验证流程来应对捐赠指令的意外更改，即使消息已通过 DMARC.
建立志愿者可以维护的库存
为筹款活动、捐赠者收据和志愿者沟通创建不同的行。记录负责人员的角色、供应商帐户、来自域、 DKIM 域和 选择器、信封身份、发送目的和最后的受控测试。活动所有者批准上诉；财务或捐赠服务所有者确认接收工作流程；志愿者协调员拥有日程安排通知。指派代表，以便库存在志愿者离开后仍能保存下来。
在繁忙的捐赠期之前协调旧的活动。筹款活动后保留的供应商帐户可以在其所有者离开后很长时间内保持授权。通过正常的更改流程检查用途、密钥、凭据和DNS依赖性。不要仅因为DNS条目在较短的报告窗口中不存在而删除它：季节性活动可能会合法且安静地持续数月。
将志愿者身份与活动成功分开
假设筹款和收据通知使用匹配的 From 和DKIM d= 域，而志愿者提醒使用 From volunteers.charity.example和来自provider.example.net的签名。即使假设后一个签名已验证，它也无法通过严格的DKIM 结盟 与 From 域。不要因为筹款路线通过了自己的测试而关闭协调员的身份问题。
这是假设的域比较，而不是证据包、密码检查或捐赠者邮件观察。 RFC 9989第 4.4 节和 5.3.5 节 需要评估相关的身份验证和对齐路径以获得完整的消息判决。另一个对齐 DKIM签名 或通过对齐 SPF 可以影响该判决；为了 p=reject 部署时，第 7.4 节和第 8 节需要有效的DKIM ，而不仅仅是SPF 。在宣布志愿者路线准备就绪之前，请验证实际的供应商配置并控制收到的样本。
优先考虑收据而不隐藏活动失败
根据组织的服务期望定义接收截止日期，然后使用批准的沙箱或测试模式通过捐赠工作流程发送无害的测试。确认收据事件、受控收据、可信身份验证结果以及对测试交易的正确引用。切勿在未经授权的情况下创建真实的捐赠或联系真实的捐赠者只是为了获取样本。分别测试活动预览和志愿者轮班提醒。
RFC 5321 区分SMTP接受责任；接受并不能证明捐赠者打开收据或在收件箱中看到它。将提交、接受接受和用户可见的收据作为单独的观察。总通过率不能替代那些交易级别的检查。
在活动启动前缩小差距
对于未对齐的外包发件人，请寻求供应商支持的自定义域设置并重新测试。如果供应商无法支持预期的身份，请考虑与通信所有者明确标识受支持的发件人地址，而不是默默地削弱整个域。将筹款内容审批、选择退出处理和捐赠者数据访问置于自己的控制之下。仅在记录相关路径证据、所有者和后备时启动，并在供应商、域或营销活动工作流程更改后再次审核。