用自有域名发邮件
机器人可以用 你自己域名 上的地址（如 noreply@example.com）给客户发邮件。但真正发信的是我们的服务器。因此在首次发送前，你需要在域名的 DNS 中一次性添加三条记录。下面说明：为什么需要、具体加什么、之后会发生什么。
没有 DNS 记录为什么邮件到不了
站在收信方——Gmail、Outlook，或你客户的邮件服务器——的角度看。他们收到一封 自称 来自你域名、却由不属于该域名的服务器投递过来的邮件。这与冒名伪造的样子一模一样：钓鱼邮件正是这样运作的。
收信方要分辨二者，只有一个办法：直接问域名本身——「这个发件方真的是代表你行事吗？」这个答案由你发布在自己域名的 DNS 里。DNS 是唯一只有你能支配的地方，因而也是收信方唯一愿意相信的地方。
在这个答案出现之前，一台尽责的邮件服务器只能把邮件当作可疑处理。最好的结果是进垃圾箱，最坏的结果是被拒收，收件人永远不会知道有过这封信。
所以下面三条记录不是形式，也不是界面上的一个勾。它们就是 你的授权。
三条记录，各自负责什么
DKIM —— 证明邮件为真的签名
DKIM 是给每封外发邮件加上的加密签名。平台为你的域名生成一对密钥：私钥留在我们这里用于签名，公钥由你发布到 DNS。收信方从你的 DNS 取出公钥来校验签名。校验通过，说明邮件确由持有私钥的一方发出，且内容在途中未被篡改。
没有 DKIM： 没有任何东西可以校验签名。邮件看起来未经签名、不可信，其他设置都无法弥补。三条记录中 DKIM 最为关键。
SPF —— 哪些服务器可以代表你发信
SPF 回答的是另一个问题：这个域名的邮件到底允许从哪些服务器发出。它是一份来源清单——你主机商的邮件服务器、你已经在用的发信服务，以及为了让机器人能发信而加入的我们的发信服务器。
没有 SPF： 邮件来自一台你的域名「不认识」的服务器。对过滤器来说这是典型的伪造迹象，并与其他疑点叠加。
DMARC —— 校验不通过时收信方该怎么做
DKIM 和 SPF 回答「邮件是不是真的」。DMARC 回答下一个问题：如果不是，该怎么办。这是你给收信方的指令——什么都别做只发报告、丢进垃圾箱，或者直接拒收。同时，DMARC 也是收信方汇总报告的接收地址，其中包括他人冒用你域名的尝试。
建议从最宽松的「仅报告」开始。等确认你所有合法发信方（财务、CRM、邮件订阅、这个机器人）都能通过校验后，再逐步收紧。过早启用严格策略，最先被砍掉的往往是你自己的邮件。
没有 DMARC： 每个收信方各行其是，而你永远不知道以你名义发出的邮件到底遭遇了什么。
需要添加哪些记录
先在后台把域名加进来：Email 板块 → 「Sending domains」 → 「Add domain」 按钮。对话框有三个字段：域名本身（例如 shop.example.com）、地址的 本地部分（@ 之前的部分，通常是 noreply），以及收件人看到的、用来代替地址的 发件人名称。保存之后，你的 DNS 记录就会显示在屏幕上。
三条都是域名 DNS 中的 TXT 记录。在你管理域名的地方添加：注册商的控制台或 DNS 服务商处。
下面的值以 example.com 为例，请换成你自己的域名。你域名的准确取值显示在后台的域名卡片上，请从那里复制，尤其是 DKIM：它的值包含你自己的公钥，每个域名各不相同，无法从文档中照抄。
屏幕上每条记录被拆成两个独立字段——「Host」 和 「Value」，各自带一个 「Copy」 按钮。请逐个复制到 DNS 服务商对应的输入框里：这两部分不能当成一整块粘贴。
| 类型 | 记录名（host） | 值 |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= 后接后台给出的长密钥 |
| TXT | example.com（域名根） | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
最容易出错的两点：
- 很多控制台会自动把域名接到记录名后面。如果名称栏里已经显示「.example.com」，就只填
mybot._domainkey，不要填全名，否则会变成mybot._domainkey.example.com.example.com。 - DKIM 的值很长，密钥内部不能有换行和空格。请用复制按钮，不要用鼠标拖选。
如果域名已经有 SPF 记录
一个域名只能有 一条 SPF 记录。如果你已经通过主机、CRM 或其他邮件服务发信，那条记录就已存在。不要再加第二条——在现有记录里、结尾的 ~all 之前补上一个 include：
v=spf1 include:spf.yourprovider.cn include:esp.getmybot.dev ~all
一个域名上有两条 SPF 记录，与一条都没有是同样的错误：校验无法通过，因为收信方不知道该信哪一条。
请注意：通过别人的记录「被覆盖」并不算数。即使你现在的服务商在自家 SPF 里包含了我们，我们的 include 也必须直接出现在你的记录中——原因见下文的域名验证一节。
SPF 为什么用 include 而不是 IP 地址
最常见的错误，是把在邮件头或论坛帖子里看到的 IP 地址粘进去。请不要这样做。
include:esp.getmybot.dev 指向我们自己维护的发信服务器清单。今天这个名字后面只有一台中继服务器。明天它们可能变多、可能迁移、可能被替换。到那时我们会在自己这边更新清单，而 你的记录继续有效，什么都不用动。这正是它的意义所在：地址只在一个地方变，而不是在每位客户的 DNS 里变。
手写的 IP 地址会在那一刻直接失真。邮件开始在 SPF 上失败，且毫无预警——后台不会报错，也不会有通知。你只会从「什么都没收到」的客户那里得知。
请原样写 include:esp.getmybot.dev，不要再添加任何东西。
域名验证
域名验证 就是平台自己去查你域名的 DNS，确认三条记录都没问题。三条全部通过，域名即变为 已验证，发信随之放行。只要有一条没通过，域名就一直处于等待状态。
检查的不只是「记录存在」：
| 记录 | 实际检查什么 |
|---|---|
| DKIM | 记录已发布，且包含 你自己的 公钥。别人的 DKIM，或换密钥后残留的旧值，都不算通过。 |
| SPF | 记录存在，并且直接包含 include:esp.getmybot.dev。形似的值，例如 include:esp.getmybot.dev.other-domain.example，不算数。 |
| DMARC | 已发布一条记录且以 v=DMARC1 开头。策略本身（p=、rua=）不检查——那是你的决定，不是给我们的授权。 |
DMARC 检查为何更宽松：它告诉收信方 如何处理 DKIM 与 SPF 的结果，却不赋予我们以你的名义发信的权利。那份权利只来自前两条记录，而这两条都做了完整的内容校验。
别人的 include 不算数
include:esp.getmybot.dev 必须写在 你自己的 SPF 记录里。如果你的 SPF 包含了某个第三方服务商，而那家的记录又包含了我们，验证不会认可：平台不会展开别人的 include 链条。原因很简单——这样「究竟是不是这个域名授权了我们」这个问题才有明确答案。
实际操作上：哪怕你确信自己「通过服务商已被覆盖」，也请把我们的 include 直接加到你自己的记录里。屏幕上的 SPF 说明写的也是同一件事：如果该域名已有 SPF 记录，请把 include:... 这个值加进去，而不要整条替换，因为这个域名可能还通过别的渠道发信。这条提示一直挂在那里，并不是校验失败后才出现。
DNS 不会即刻生效。 在注册商处保存记录后，它们需要扩散到各级名称服务器：通常是几分钟，有时几小时，偶尔长达一天。这取决于你的服务商和记录的 TTL。这是正常现象，不由我们决定。
不过你不必被动等待。平台会 每小时 自动复查一次待验证的域名，而域名卡片上还有 「Verify now」 按钮——同一套检查，立刻执行，结果马上显示。保存记录后请立即点它：若有拼写错误，你一秒钟就知道，而不是一小时后。想点多少次都可以。
域名状态显示在卡片上：「Pending verification」、「Verified」 或 「Not verified」。在通过验证之前，卡片上还会挂着提示「Sending from this domain is disabled until it is verified.」
结果不是一句「未通过」。 三条记录在屏幕上各有自己的状态——「Passing」、「Not passing」 或 「Not checked yet」——以及各自说明哪里不对的一行文字。
对于 SPF，屏幕会区分两种情况，这也是整个流程中最关键的区分：
- 域名根本没有 SPF 记录。 用上面表格里的值发布一条。
- 有 SPF 记录，但里面没有我们的 include。 请把 include 加到 已有的 那条记录里：不要再建第二条，也不要整条替换。同一条提示还明确覆盖了链式情况：如果 include 只是通过别家服务商的 SPF 记录才到达我们，那不算数，因为链条不会被展开。
第二种情况是整个流程中最令人困惑的时刻：记录明明已经在那儿，你刚刚还亲自读过一遍，验证却依然拒绝。现在错误提示说的，和记录旁边那条常驻提示完全一致——把我们的 include 加到你已有的东西里。
如果验证不通过：
- 先看三条记录中哪一条标着「Not passing」、它的说明写了什么，再按它去处理。
- 确认记录确实已发布——许多控制台需要另外点一下「应用更改」。
- 检查记录名是否出现域名重复（见上文）。
- 检查域名上只有一条 SPF 记录，并且我们的 include 就在那条记录里面。
- 稍等片刻再检查一次：改动可能还没扩散开。
验证通过之前不能发信——这是有意为之
只要域名未通过验证，邮件 就不会发送。不是「发出去了但进垃圾箱」，而是根本不出门：发送尝试会以「域名未验证」的错误结束，并记录在日志里。
这是有意设计，不是故障。来自未曾为自己背书的域名的邮件，最终会变成垃圾邮件投诉，而投诉会损害平台所有客户共用的发信基础设施的信誉。不发出一封邮件，远比发出去之后花半年从黑名单里爬出来划算。因此这里是禁止，而不是提醒。
看到这个错误时，先检查 DNS 记录并点一次检查，再联系客服。绝大多数情况下只是记录名里的一个笔误。
退订、投诉与投递失败
三条事先不知道就会感到意外的规则。
每封营销邮件都带有一键退订。 平台会自动在邮件页脚加入退订链接，并加上相应的技术邮件头，邮件客户端据此在发件人地址旁边画出「退订」按钮。这一点无法去掉——设置里不行，改版式也不行。退订立即生效，无需打开邮件，也没有确认步骤。Gmail 等主流服务对批量发信方就是这样要求的：缺少它的邮件必然进垃圾箱。
退订是终局，界面上无法撤销。 已退订的地址不会再收到这个机器人的邮件。既没有「恢复」按钮，也不能靠重新导入名单绕过：退订绝不会越过本人意愿被取消。只有本人才能回来——在你的订阅表单里重新留下地址。
还有更严格的一种情况：如果有人在邮件客户端点了 「这是垃圾邮件」，该地址将被永久关闭。即便通过你的表单重新订阅也打不开——因为我们已经知道上一次的结果，而继续向这类地址发信，是摧毁域名信誉最快的方式。因法律要求被人工关闭的地址同理。
硬退信会永久屏蔽该地址。 如果收件方服务器回复「不存在该信箱」，该地址会被标记为不可投递并从后续发送中剔除。这不是临时状态：继续敲一个不存在的信箱，是连同其余所有地址一起掉进垃圾邮件过滤器的最快路径。
软退信（信箱满、服务器暂时不可用）不会 关闭地址——发送继续。
为什么「打开数」偏低
邮件统计里有打开数，而它永远低于真实值。这不是统计出错，而是打开这件事本身的测量方式所致。
打开是这样记录的：邮件客户端在显示邮件时，从服务器加载一张极小的跟踪图片。现代客户端默认不加载远程图片；而那些会加载的（Apple Mail 及类似隐私机制）则会提前替所有人加载，包括从未打开过邮件的人。前一种情况打开被漏掉，后一种情况被记到了根本不在场的人头上。要更精确地统计邮件打开，没有任何办法——我们没有，别人也没有。
因此界面在这个数字旁边给出了说明：它是 下限，而不是精确值。可以用它来横向比较不同邮件（同样的偏差对所有邮件一视同仁），但不要把它当作「有多少人读了这封信」的答案。
如果需要可靠的互动指标，请看 「Link clicks」。点击链接是真人真实的动作，没有谁会替他提前点。「Delivered」、「Unsubscribes」、「Complaints」 和 「Bounces」 同样是精确的：它们由邮件服务器上报，而不是由邮件里的一张图片决定。这些都在同一个 Email 页面的 「Sending stats」 区块里。