MailerLite 域名认证：升级前修好 SPF、DKIM 与 DMARC

先分清三个不同问题

“域名未认证”可能同时涉及三个独立判断：

1. **MailerLite 能否确认你控制该域名？** 这依赖账户显示的验证值。 2. **收件服务器能否确认 MailerLite 是获授权的发件方？** DKIM 对邮件签名，SPF 声明允许的发送基础设施。 3. **对齐失败时收件服务器应怎么处理？** DMARC 发布策略与报告规则。

这三个问题都不等于“应该购买哪一个 MailerLite 方案”。MailerLite 的试用说明称，试用结束后若继续使用自定义域名发件，就必须完成认证；同一说明又称账户会回到 Free 方案。这支持“认证可能不要求 Comfort”的推断，但并未在明确套餐行中证明。

除非当前官方套餐表或真实账户测试给出证据，否则不能写“Comfort 解锁 SPF／DKIM”。

修改 SPF 前列出所有发件系统

最危险的捷径，是看到某个服务商指南要求替换 SPF，就直接删除原记录。域名可能同时授权 Google Workspace、Microsoft 365、客服系统、交易邮件平台或另一个营销平台。

修改 DNS 前应：

- 导出或复制当前区域记录； - 列出所有使用该域名发件的系统； - 保存现有 SPF TXT 值； - 确认注册商或 DNS 服务商账户负责人； - 设定回退点与维护时段。

一个域名通常应只有一条 SPF 策略记录。如果多个合法服务都要发件，应把获授权机制合并到一条有效策略中，而不是发布相互竞争的多条 SPF。MailerLite 排错指南明确提醒多条 SPF 会造成问题，并要求考虑 DNS 传播时间。

这也不是“无条件保留所有旧值”。只有在对应负责人确认旧发件系统已经停用后，才删除其机制。

严格使用账户显示的 MailerLite 记录

应使用 MailerLite 账户针对该发件域名显示的准确值，不能从文章、其他域名或别人的账户复制 selector、host 或验证 token。

受控配置流程如下：

1. 打开 MailerLite 域名认证页面，记录所需 DKIM CNAME、SPF TXT 与验证 TXT。 2. 在 DNS 服务商界面确认系统是否会自动补上主域名，避免把完整主机名输入两次。 3. 构造单一 SPF 策略时保留仍在使用的合法发件方。 4. 按账户给出的值添加 DKIM selector 与目标。 5. 单独添加验证记录；它不能替代 SPF 或 DKIM。 6. 保存修改前后快照、时间与操作人。 7. 等待传播后，再回 MailerLite 重新验证。

不要把验证 token 放进公开截图。若 DNS 由代理商或 IT 团队管理，应通过获批准的私密渠道传递记录值。

DKIM、SPF、DMARC 是三类证据

其中一项显示绿色，并不能证明整个链路都正确。

- **DKIM**：确认 selector 解析到 MailerLite 为当前账户签发的目标；别的域名或账户的 selector 不构成证据。 - **SPF**：确认只有一条连贯策略，且所有当前合法发件方仍被授权。 - **DMARC**：确认策略域名、报告地址与实际 From 域名一致，并且相关地址确由组织控制。 - **邮件证据**：DNS 验证后，发送一封获授权的测试活动，再检查邮件头里的 SPF、DKIM、DMARC 结果。

MailerLite 把 DMARC 说明为独立的策略与报告层，并没有承诺进箱。 发件信誉、内容、互动、投诉历史与名单质量仍会影响结果。

只有完成全量发件系统盘点后，才逐步提高 DMARC 强制策略。直接使用严格 reject 可能误拦仍未对齐的合法系统。

排错时先不要购买

如果 MailerLite 仍显示失败，应先检查最小可观察原因：

- **找不到记录**：查询准确 host 与记录类型的公开 DNS 结果。 - **DKIM 目标错误**：逐字比较在线 CNAME 目标与账户值。 - **多条 SPF**：合并合法机制，只删除已经确认的重复记录。 - **传播延迟**：记录 TTL 并等待缓存刷新；MailerLite 称传播可能最长需要 72 小时。 - **代理或扁平化**：确认 DNS 服务商没有改写必须保持为 CNAME 的记录。 - **域名不匹配**：确认认证域名与活动可见 From 域名一致。

升级套餐不会修复主机名拼错、区域后缀重复或无效 SPF。若公开 DNS 已正确但 MailerLite 仍失败，联系支持前先保存截图和查询证据。

从竞品资料提炼正确原则

Mailchimp、Kit 与 Brevo 也把域名验证和认证写成 DNS 信任配置，而不是简单的付费修复。 它们的记录值与套餐规则不能直接套用到 MailerLite，但共同说明三点：

- 验证与认证不是同一个步骤； - DNS 值必须来自当前有效账户； - 认证改善信任信号，但不能保证投递。

不能把竞品的 DKIM selector、SPF include 或 DMARC 策略加入 MailerLite 配置。

Twilio SendGrid 同样把域名认证视为服务商专属 DNS 配置；其记录值不能复制到 MailerLite。

判断 Comfort 是否解决了其他瓶颈

认证通过后，再把剩余限制对应到当前 MailerLite 价格表。 只有当方案明确改变了已测量的需求，例如订阅人数、发送量、席位或其他列明功能，才考虑 Comfort。

可以使用以下购买门槛：

- **DNS 仍失败** → 修 DNS，不为认证升级； - **DNS 已通过，但套餐限制阻塞工作** → 核对准确套餐行与所选结账页； - **DNS 已通过，也没有明确限制** → 保持当前方案并继续监控； - **希望保证进箱** → 任何方案都无法承诺，应另外测试投递与名单质量。

价格、税费、计费周期和功能名称可能变化。付款前必须核对所选市场与结账页。本文不引用价格，因为判断重点是“认证问题还是容量问题”，而不是某个日期的价格快照。

保存证据包

每个生产发件域名都应保留：

- 已批准的发件系统清单； - DNS 修改前后快照； - MailerLite 准确记录值与验证时间； - 显示 SPF、DKIM、DMARC 结果的测试邮件头； - 批准强制策略修改的负责人； - 回退方案。

更换 DNS 服务商、From 域名或邮件平台后，应重新核查。去年的通过记录不能证明今天的路由仍然对齐。

结论

不要仅因为域名认证未完成就购买 MailerLite Comfort。现有官方证据没有把认证写成付费专属开关；而“试用结束后 Free 方案仍可认证”也只能作为推断，除非后续由明确套餐行或真实 Free 账户验证。

应谨慎完成发件域名认证，保留其他合法发件方，检查邮件头；只有独立且有证据的容量或工作流限制出现时才升级。

*联盟披露：如果你之后通过获批准的链接选择 MailerLite，Toolnavia 可能获得佣金。本文不承诺专属折扣、DNS 修复、进箱结果或 Free 方案权益。*