浅谈 - 邮件服务最佳实践

发表于 | 分类于 | | 阅读次数:

前言

前前后后使用了 aws 的 ses 服务也用了好几年了，在很多使用上也踩了很多坑，打算从最佳实践角度去聊聊，怎么更好的使用邮件服务。

主要分为几大块

  1. 邮件质量相关
  2. 邮件安全相关
  3. 邮件统计相关
  4. 减少退信和投诉

以下很多内容虽然是从 aws 的 ses 服务来说明的，但是本质上邮件服务都是大同小异的，完全可以应用到其他的邮件服务上

邮件质量相关

1. 关注邮件质量

电子邮件接收方使用内容筛选器来检测邮件中的特定属性，以识别当前收到的邮件是否合法。这些内容筛选器会自动审核邮件的内容，以识别常见的不受欢迎的邮件特征乃至恶意邮件。

同时很多邮件服务厂商，比如 Amazon SES 也会使用内容筛选技术，协助在邮件发送之前检测和拦截包含恶意软件的邮件。

如果电子邮件接收方的内容筛选器认定我们的邮件包含垃圾邮件或恶意电子邮件的特性，邮件很可能被标记出来，并从收件人的收件箱中移出。

因此在设计电子邮件时请记住以下几点：

  1. 现代内容筛选器非常智能，且不断调整和更改。它们不依赖于预定义的规则集。诸如 ReturnPath 或 Litmus 等第三方服务可帮助识别电子邮件中可能触发内容筛选器的内容。
  2. 如果电子邮件中包含链接，请检查这些链接的 URL 是否在基于域名系统的黑名单（DNSBL）中，这些黑名单可在像 URIBL.com 和 SURBL.org 这样的网站中找到。
  3. 避免使用短地址。恶意发件人可能使用短地址来隐藏链接的实际目标。当 ISP 发现链接缩短服务（即使是信誉最好的服务）被用于不法目的时，他们会完全拒绝访问这些服务。如果我们的电子邮件中有包含被加入拒绝列表的链接缩短服务链接(哪怕我们用来干正事)，它也不会送达客户的收件箱，邮件的到达率也随之受到影响。
  4. 测试电子邮件中的每个链接，确保其指向预期的页面。
  5. 请确保我们的网站包括隐私策略和使用条款文档，并且这些文档是最新的。最好在发送的每封电子邮件中添加到这些文档的链接。提供指向这些文档的链接表明我们对客户无所隐瞒，有助于建立信任关系。(尤其是支付相关的邮件，比如支付成功等邮件)
  6. 如果计划发送高频率内容 (如“每日交易”邮件)，要确保电子邮件内容每次都有所不同。在发送高频邮件时，必须确保这些消息及时且有意义，而不是重复和令人厌烦。
  7. 邮件内容一定要被约束和规范后的，尽量减少带入一些用户自定义的信息，防止被黑客拿来做骚扰邮件或者钓鱼邮件。同时也要避免发送使用一些容易让ISP产生反感的名字，如恐怖 等等

说一下之前发生的几个案例:

1.1 使用短链被牵连

之前有出现过为了让邮件的链接看起来没有那么长，我们的市场人员用了第三方的短链服务，结果这个短链服务被封了，导致邮件中链接的打开率急速下降。

1.2 网易 163 邮箱被退回

之前有发生过我们的一封邮件被网易的 163 邮箱退回的情况，同一个 “From” 发送的其他封的邮件可以正常收到， 但是就是这一封邮件会收不到，后面经过多次确认，发现是因为这封邮件的内容触发了网易 163 邮箱的内容检测，认为潜在不规范，进一步排查发现是邮件中有一个链接中的一个参数有带 mail 参数，因此被 163 邮箱服务判为不规范内容，导致 bounce 退回。 最后是通过将这个 mail 参数的值做一层 base64 处理再 urlencode，这才通过检测，成功发送。

1.3 显示用户昵称被当作骚扰邮件滥用

针对一些用户的自定义的输入，如果要在邮件上有所体现，最经常出现的就是用户昵称，用户可以自己填自己的昵称

而我们很喜欢在给用户发送邮件的话，开头都是 hi,xxx 之类的，如果这时候用户是有邮箱验证过的，那就还好，如果是没有邮箱验证过的，比如这是一封注册邮件，这时候黑客就可以在注册的时候，在昵称一栏输入钓鱼网站或者广告信息，然后批量刷注册接口，让注册服务去帮他发送垃圾邮件，这时候你的邮件服务就很有可能会被大量投诉，乃至被禁用。

2. 域和“发件人”地址注意事项

  1. 仔细考虑用于发送电子邮件的地址。“From”地址是收件人看到的第一条信息，因此可能会留下持久的第一印象。此外，一些 ISP 会将我们的声誉与我们设置的“From”地址相联系。
  2. 为不同类型的业务使用不同的子域。假设我们从 example.com 域发送电子邮件，并且打算同时发送营销邮件和支付邮件。不要从 example.com 发送所有邮件，而是从像 marketing.example.com 这样的子域发送营销邮件，从像 orders.example.com 这样的子域发送支付邮件。独有的子域可建立它们自己的声誉。使用子域可降低声誉损坏的风险，例如，当我们的营销邮件落入垃圾邮件陷阱或触发内容筛选器时，这时候哪怕营销邮件被退回了，也不会影响我们发送支付邮件的业务。
  3. 针对不同的业务类型，最好用不同的账号发送，尤其是营销邮件和业务邮件，最好用不同的 ses 账号发送，因为之前有出现过营销邮件整个发送的账号都被封了，这时候就不是分子域可以解决的了，而是账号要分开，这样子哪怕营销邮件的账号废了，大不了后面再申请解封甚至重新注册一个，但是就不会影响到我们的业务邮件。
  4. 如果计划发送大量邮件，不要从 sender@hotmail.com 这样的基于 ISP 的地址发送这些邮件。如果 ISP 注意到有大量邮件来自 sender@hotmail.com ，该电子邮件的处理方式将与来自我们自己拥有的出站电子邮件发送域的邮件有所不同，所以最好都走自己的域，也有利于信用度的培养
  5. 与我们的域注册商沟通，确保我们的域的 WHOIS 信息准确无误。维护真实且及时的 WHOIS 记录表明我们重视透明度，并让用户能够快速识别我们的域是否合法。
  6. 避免使用 no-reply 地址，例如 no-reply@example.com ，作为我们的“From”地址或“Reply-to”地址。使用 no-reply@ 电子邮件地址会向我们的收件人明确传达一个信息：我们没有为他们提供联系我们的方式，并且对他们的反馈不感兴趣。

针对第三点，正常我们的业务会至少保持同时有 3 个 ses 账号在使用:

  1. 发送业务邮件用一个，比如支付，忘记密码，邮件验证等主要的，跟用户紧密相关的邮件
  2. 日常定时报告邮件用一个，我们产品有提供定期发送业务报告/汇总的功能，一般用于定期发送
  3. 发送营销邮件用一个，我们有各种营销活动，折扣价活动，都是走这个账号，也是批量发送最多的一个账号，当然被封的概率也最大

3. 构建和维护列表

  1. 实施双重确认策略。当用户注册接收您的电子邮件时，向其发送一封包含确认链接的邮件，直到他们单击该链接确认地址之前，不要开始发送其他电子邮件(除非这封邮件从业务上认为已经过期)。双重确认策略有助于降低因拼写错误而导致的硬退信数量。
  2. 在针对 web 表单进行提交的时候，如果内容完全是用户生成的，要做内容的安全性验证和所填邮箱的有效性验证(指向的域具有有效的 MX 记录),确保只发送高质量的电子邮件内容
  3. 增加无效域名过滤机制，针对 hardbounce 率大于一定百分比且邮件 Deliver/Open 为0的邮箱域名，进行前置过滤，降低实际发送任务中的 hardbounce 率
  4. 自建分析和过滤系统, 通过 sns 来获取各种 bounce 通知，从而自建过滤系统，具体可以看: AWS 的邮件发送服务 SES 订阅 SNS 来处理硬反弹邮件
  5. 标准的别名 (例如 postmaster@、abuse@ 或 noc@) 不太可能故意用于注册我们的电子邮件。确保我们仅将邮件发送给确实想要接收它们的真实用户。对于标准别名应特别注意这条规则，因为这些别名习惯上是为电子邮件监控程序保留的。这些别名可能是恶意添加到我们的列表中，以蓄意破坏的形式损害我们的声誉。 因此针对一些特殊的别名，我们也可以直接放到我们的过滤系统中

邮件安全相关

1. 身份认证

  1. 使用 SPF 和 SenderID 对我们的域进行身份验证。这些身份验证方法向我们的电子邮件收件人确认，发送的每封电子邮件都来自实际声明的发件域。
  2. 使用 DKIM 对我们的出站邮件签名。此步骤向收件人确认，在发件人与接收方之间沟通中，内容不曾被更改。

关于 SPF + DKIM 的配置和验证，可以看: 电子邮件欺诈防护之 SPF+DKIM+DMARC

同时使用 DKIM 对我们的出站邮件签名，要遵守 DMARC 最好使用 custom Domain 来做验证，这样大部分 ISP 不会显示发送的邮件是通过AWS SES 进行发送，之前就有发生类似的事情: AWS SES 发送邮件出现的代发字样问题

2. 合规性

请注意电子邮件收件方所在国家/地区的相关电子邮件营销和反垃圾邮件法律和法规

邮件统计相关

我们肯定是希望我们邮件发送出去之后，邮件的到达率，打开率，邮件内链接的打开率等等都可以知道，邮件服务平台都会提供相关图表和接入的 API 设置，以 aws ses 来说，就可以使用 Amazon SES 事件发布监控电子邮件发送，具体实践可以看: AWS 的邮件发送服务 SES 设置邮件事件监控

其实就是 SES + SNS 通知的方式来记录电子邮件的事件类型, 这些是存在表里面的，如果要看更加具体的图表，可以再结合 Prometheus + grafana 的方式，让你的发邮件程序接入 Prometheus 统计，然后在 grafana 中输出图表，比如

1

然后就可以在 grafana 中去针对业务的发送情况去设置对应的预警，关于 Prometheus 的使用，可以看: 基于 prometheus 打造监控报警后台

减少退信和投诉

毫无疑问，退信和投诉一定是我们查看电子邮件发送情况结果最重要的两个指标，因为一不小心就有可能翻车导致账号被封了。比如之前发生过的几次:

就是因为处理机制的不完善，导致硬退信指标超标了，从而被封了，还是吃了没经验的亏。 还有出现过营销邮件的投诉率超标被封的情况，后者更严重，前者还可以申请解封，后者大概率这账号是废了。

1. 退信(Bounces)

当电子邮件无法传输给目标收件人时，会出现退信。有两种类型的退信：硬退信(hard bounces)和软退信(soft bounces)

也有叫反弹的，意思是同一个

  • 硬退信 -> 当电子邮件由于邮件地址不存在等持久性问题而无法送达时
  • 软退信 -> 当有临时问题阻止电子邮件送达时，会出现软退信。出现软退信的情况有，收件人的收件箱已满，或者收件服务器暂时不可用

正常我们可以通过接入 SES webhook 来得到每一封邮件的退信情况，并且会有退信监控，因为一旦退信率在短时间内很高的话，邮件服务商就有可能将你的邮件发送账号封禁掉。

除了上面提到的一些程序上的处理，还有一些原则上的操作可以避免退信和改善发件人的声誉:

  1. 尽量保持硬退信率低于 5%。电子邮件程序中的硬退信越少，ISP 将我们的邮件视为合法和有价值信息的可能性越高。这一比率应被视为合理且可达到的目标，但并不是所有 ISP 的通用规则。
  2. 请勿租用或购买电子邮件列表。这些列表可能包含大量无效的地址，这可能会导致硬退信率显著增加。此外，这些列表可能包含垃圾邮件陷阱 - 专门用于捕获非法发件人的电子邮件地址。如果我们的邮件落入垃圾邮件陷阱，送达率和发件人声誉会不可挽回地受损。
  3. 持续更新我们维护的邮件列表。如果很长一段时间未向我们的收件人发送电子邮件，请尽可能通过一些其他方式 (如网站登录活动或购买历史记录) 来验证客户的状态
  4. 如果没有办法验证客户的状态，请考虑发送赢回(win-back)电子邮件。典型的“赢回”电子邮件会提到很久没有收到客户的消息了，并鼓励客户确认他们仍希望接收我们的电子邮件。在发送“赢回”电子邮件后，从我们的维护列表中清除所有未响应的收件人。

当收到退信时，通过观察以下规则适当地进行回应至关重要：

  1. 如果某个电子邮件地址硬退信，立即从维护列表中删除该地址。并不再尝试重新发送。反复的硬退信会叠加，并最终损害我们对收件人 ISP 的声誉。
  2. 请确保我们用于接收退信通知的地址能够接收电子邮件，因为邮件服务商会转发退信资讯到我们的接收邮箱

2. 投诉(Complaints)

当电子邮件收件人在基于网页的电子邮件客户端中单击“标记为垃圾邮件”或等效的按钮时，就会出现投诉。

如果您累积了大量的此类投诉，ISP 会假定您发送垃圾邮件。这对您的送达率和发件人声誉有负面影响。甚至会出现针对该 From 域名的其他邮件也进行拒收

以下指导原则有助于避免投诉和改善发件人声誉：

  1. 尽量保持您的投诉率低于 0.1%。电子邮件程序中的投诉越少，ISP 将我们的邮件视为合法和有价值信息的可能性越高。这一比率应被视为合理且可达到的目标，但并不是所有 ISP 的通用规则。
  2. 如果客户投诉营销电子邮件，应立即停止向该客户发送营销电子邮件。但是，如果我们的电子邮件程序还包括其他类型的电子邮件 (如通知或事务性电子邮件)，继续向发出投诉的收件人发送这些类型的邮件也许是可以接受的。
  3. 与硬退信一样，如果很长时间未向某个列表发送电子邮件了，确保我们的收件人了解他们为什么收到您的邮件。通过发送“欢迎”邮件，提醒他们我们的身份以及我们为何联系他们

针对第二点，我们一般会在营销邮件的 footer 底部会有一个链接，点击表示后续不再接收此类的营销邮件，让用户可以自己选择。

参考资料: