分开三个决定
AWeber 设置有三个实际问题：您能否收到发件人地址验证消息、域是否经过身份验证以及预期列表是否使用该发件人？一步的成功并不能解决其他的问题。从您控制的域及其上受监控的邮箱开始。在更改记录之前记录列表、广播所有者和DNS管理员。
提供商的发送地址指南将指导您在“域和地址”中添加地址并按照其验证电子邮件进行操作。在“列表设置”、“基本设置”中，从“发件人地址”列表中选择已验证的地址并保存。 发送地址工作流程
有意配置域
AWeber 提供自动连接和手动路径。对于手动设置，请在“域和地址”中打开域的齿轮图标，获取其 DKIM CNAME 记录和 DMARC 指令，并通过权威DNS服务发布。返回同一域视图以检查已安装状态。其自动路径会配置DKIM和DMARC ，因此在授予连接权限之前请检查现有的域策略。 认证说明
不要仅仅为了清除入职屏幕而用通用监控示例替换已建立的隔离或拒绝策略。要求域所有者协调任何策略冲突和报告目标。新的营销整合不应默默地改变财务、支持或其他平台发送的邮件的处理方式。如果预期的DNS名称已存在，请在编辑之前比较它们的用途和值。
建立广播发布检查
AWeber 表示，它会在广播发送时重新检查身份验证，并向 Draft 返回未经身份验证的广播。这使得DNS保留成为活动操作的一部分，而不是一次性的启动任务。 发送时间检查
原始操作流程：在进行高价值广播之前，确认选定的列表发件人、域名状态和责任活动运营商。然后通过相同的预期工作流程发送受控消息。私下保存其原始标头并记录可见的From域， 信封发件人、 DKIM d= 和 s= 身份，以及接收服务的 SPF、 DKIM和DMARC结果。使用可信接收者插入的结果，而不是消息中携带的任意标头。
身份验证和收件箱放置是不同的结果。身份测试是指通过的SPF或DKIM结果是否与域的适用策略下的发件人一致。到达收件箱的测试本身并不能证明这种关系，有效的身份并不能保证每个收件人都会接受活动。
诊断正确的层
说明性场景： DNS对于营销域来说是正确的，但列表仍然选择旧的发件人。域管理员没有发现DNS缺陷，而活动所有者则看到了意外的地址。在重建密钥之前比较实际消息和列表配置。相反，地址验证电子邮件证明邮箱访问，而不是域的已发布记录保持不变。
保留一个简短的异常记录，其中包含失败的层、所有者和下一个观察结果。对于DNS问题，请将公共权威答案与帐户说明进行比较，并检查所有者名称重复。对于地址问题，请检查邮箱访问和所选列表地址。对于退回的草稿，在重新安排之前恢复身份验证；不要假设先前的调度仍然是已执行的发送。
关闭并维护
保留以前的回滚设置，并在调查时仅暂停受影响的活动。 DNS迁移、列表所有权更改或发件人域切换后重新检查。在未咨询活动所有者的情况下，请勿在例行网站清理期间删除身份验证记录。文件于 2026 年 11 月 8 日审核；本指南没有测试 AWeber 租户、广播或实时DNS记录。
明确地做出名单选择决定
书面案例 AW-01 假设预期列表是产品更新，其批准的发件人是news@example.com ，但其保存的发件人是news@oldbrand.example 。在这种情况下，只有example.com具有当前已安装状态； oldbrand.example身份验证未知。活动所有者必须更正或明确批准实际发件人，并在安排之前验证该域。不要从不同域的绿色状态推断DMARC结果。对于稍后假设的受控消息，假设来自news@example.com和受信任的DKIM传递d=example.com, s=aweber_key_a;尽管SPF仍然未知，但这是一条精确对齐的路径。它仍然没有提及DNS删除后的未来广播。此处未访问或执行任何列表、广播或消息。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。