你需要知道的关于交易电子邮件但不知道要问的一切

没有电子邮件，任何具有用户身份验证的应用程序都无法存在，但是，电子邮件并不总是得到应有的关注。 借助现代电子邮件服务提供商，为您的用户创建一流的事务性电子邮件体验比以往任何时候都容易，但对于我们大多数人来说，挑战在于您不知道自己不知道的事实。 我们将深入分析您需要的所有内容的端到端分析，以使您的事务性电子邮件与您的 Web 应用程序的其余部分保持同步。

我们将解决事务性电子邮件和批量电子邮件之间的区别，以及如何以及为何使用电子邮件身份验证。 我们还将讨论如何优雅地处理交付边缘案例，制作出色的电子邮件内容，以及您需要用于发送电子邮件和监控交付的关键基础设施。 然后，您将很快成为交易电子邮件专家。

交易电子邮件的挑战

在某种程度上，电子邮件传统上一直是二等公民，因为它更难以监控和了解您的表现。 对于您的应用程序，有无数的性能监控工具可以提供对前端、后端、数据库、错误等的洞察。 对于电子邮件，这些工具不太为人所知，并且更难以有效使用。 因此，让我们探讨电子邮件监控和报告所面临的一些挑战，然后我们可以看看可以在挑战和限制条件下工作的可用工具和策略，以便让您更了解您的交易电子邮件。

监控电子邮件的最大潜在挑战是，实际上不可能登录到每个收件人的收件箱并检查他们是否收到了电子邮件。 因此，从一开始，我们所能期望的最好的见解就是简单的代理或性能估计。 第二大挑战是每个 ISP 都按照自己的规则行事。 可能被 Outlook 归类为垃圾邮件的邮件可能会直接进入 Gmail 的收件箱。 收件箱提供商不能分享他们的“秘密武器”，因为它会立即被垃圾邮件发送者利用。 那么开发人员该怎么做呢？

打开率可以给你一个粗略的近似值，但由于它们依赖于跟踪像素，这很容易被阻止，所以这是一张不完整的图片。 收件箱率和交付速度也不能直接衡量。 因此，您必须满足于向您有能力测试的种子帐户发送定期测试。 这些并不完美，但它是了解交付给各种收件箱提供商的最佳可用代理。 我们将在本指南的后面部分介绍有助于自动化此操作的工具。

以 DKIM、SPF 和 DMARC 的形式添加域身份验证可能会很困难且令人困惑，或者，根据您公司的规模，访问或批准 DNS 更改可能很麻烦或不可能。 即便如此，让 DNS 条目不正确也非常容易。 如果您不熟悉域身份验证，请不要担心，我们稍后会深入解决。

当然，即使您通常能够实现出色的交付，退回处理也会给交付带来更多可变性。 收件人的收件箱可能已满。 人们换工作，电子邮件地址变得不活跃。 人们用电子邮件地址打错字。 人们可能会使用群组别名进行注册，然后该群组中的一个地址会被退回。 临时服务器或 DNS 中断可能会影响给定域中每个人的交付。 然后是垃圾邮件投诉。

所以一出大门，甲板就堆在你身上。 有大量的边缘情况，并且很难获得准确的交付情况。 持续监控很复杂，而且有很大的出错空间。 我知道，它描绘了一幅阴暗的画面。 幸运的是，电子邮件已经走过了漫长的道路，虽然它不是微不足道的，但所有这些问题都有很好的解决方案。

交易与批量促销

在我们进一步讨论之前，我们需要解决批量促销电子邮件和您的应用程序的交易电子邮件之间的显着差异。 对于前者，如果电子邮件丢失或延迟，没有人会错过它。 但是，对于后者，密码重置丢失或显着延迟可能会导致额外的支持请求。 您的交易电子邮件与应用程序中的页面一样重要。 您可以将丢失或延迟的电子邮件视为大致相当于您的 Web 应用程序中的损坏页面。 电子邮件是一种不同的媒介，但它仍然是使用您的应用程序体验的核心部分。

由于人们期望并希望收到交易电子邮件，因此他们在打开率和点击率方面的参与度高于您的批量促销电子邮件。 同样，交易电子邮件被报告为垃圾邮件的频率远低于批量电子邮件。 与批量促销电子邮件相比，所有这些都会为您的交易电子邮件带来更好的声誉。 在某些情况下，这可能是收件箱和垃圾邮件文件夹之间的区别。 或者，这可能只是 Gmail 将电子邮件放入哪个标签的问题。无论如何，事务性和批量之间的差异非常明显，甚至 Gmail 官方也建议将流分开。 这样，您的大宗声誉就不会拖累您的交易声誉。

这给我们带来了第一个提示：

1. 使用不同的域或子域分隔您的事务和批量发送流

在一个完美的世界中，您将通过您的主域发送事务，并将批量降级到诸如[email protected]之类的子域，并且每个类别也将具有自己的 IP 地址。

分离流是第一步，也是为收件人提供最佳电子邮件体验奠定基础的关键。 虽然您不能保证将邮件送达收件箱，但您可以做一些事情来将卡片堆放在对您有利的位置上。 身份验证是做到这一点的下一步。 就像您不会在没有安全证书的情况下启动现代 Web 应用程序一样，您也不想在没有完全验证的情况下发送电子邮件。

电子邮件认证

您可能听说过诸如 DKIM、SPF 或 DMARC 之类的首字母缩略词，您甚至可能复制并粘贴了一些 DNS 条目来设置它们。 或者你可能跳过了它，因为它感觉有点太复杂了。 无论哪种方式，这些都是值得实施的标准，它们相互补充，共同建立和保护您的声誉。 解决这些问题的确切方法因提供商而异，但始终值得实施。

让我们从 DKIM 开始。 DKIM 无需过多了解技术细节，而是做了两件事。 首先，它在您的电子邮件上充当一种虚拟蜡封，以表明它们在传输过程中没有被修改。 其次，它使您能够建立域声誉。 DKIM 专注于域，而 SPF 专注于提供已批准的 IP 地址列表以供发送，以便接收邮件服务器更好地了解电子邮件是否来自合法来源。

DKIM 的一个显着优势是它是避免 Gmail 中的“通过”标签或 Outlook 中的“代表”标签的关键。 这些元素使您的电子邮件看起来更有可能是垃圾邮件，并可能破坏收件人的信任。 因此，DKIM 不仅仅是一个幕后标准。 这会直接影响收件人的体验。

这一切都将我们带到了下一个基本技巧：

2. 使用 DKIM 和 SPF 验证电子邮件

虽然身份验证不能保证交付，但它是建立声誉并尽一切可能确保交付的关键方面。

DMARC 旨在帮助防止网络钓鱼攻击。 它结合了 DKIM 和 SPF，以帮助您监控域的发送并通过使您能够发布 DMARC 策略来保护您的域声誉。 该策略告诉收件箱提供商在电子邮件未通过 DMARC 对齐时该怎么做。

在 DMARC 之前，收件箱提供商完全可以选择如何处理未通过 DKIM 和/或 SPF 进行身份验证的电子邮件，但是使用 DMARC，您可以创建一个公共策略来告诉提供商隔离（发送到垃圾邮件文件夹）或拒绝（彻底丢弃）未通过 DMARC 对齐的电子邮件。

DMARC 的另一个好处是，它使 ISP 能够向您提供有关使用您的域发送的电子邮件的来源以及通过 DKIM 或返回路径对齐失败的数量的报告。 这可以让您追踪未能对齐的合法来源，并采取措施确保这些来源经过身份验证。 它还可以帮助您量化尝试使用您的域发送的非法电子邮件的数量。

PayPal 是良好 DMARC 政策重要性的典型例子。 多年来，无数诈骗者试图欺骗 PayPal 电子邮件，但现在，有了 DMARC，PayPal 发布了一项 DMARC 政策，告诉 ISP 拒绝未通过 DMARC 的电子邮件。 因此，如果任何诈骗者试图欺骗 PayPal 电子邮件，他们将无法与 DMARC 对齐，并且 ISP 可以有信心完全拒绝这些电子邮件，因为 PayPal 有一项公共政策，即如果电子邮件未能对齐，则应该被拒绝。

这是对 DMARC 的一个非常简短的概述，但希望它有助于为我们的第三个技巧提供上下文：

3. 制定并发布 DMARC 政策

此外，如果可能，设置自定义返回路径以最大限度地提高对齐机会。 然后，监控您的 DMARC 报告并进行调整，以确保与任何合法的电子邮件来源保持一致。 最后，如果您的产品或品牌是大量网络钓鱼攻击的目标，请开始逐步实施更积极的隔离或随着时间的推移拒绝政策。

Postmark 的 DMARC 工具是建立 DMARC 政策并开始接收有关您的域的每周报告的一种免费且简单的方法。 将您的批量和事务性电子邮件流分开，并设置所有上述身份验证，您已经处理了交付的所有基本方面。 从现在开始，我们将专注于您的应用程序中的电子邮件处理和处理。

了解电子邮件生命周期

从表面上看，电子邮件听起来很简单，但是当你分解电子邮件的生命周期时，表面之下有很多微妙之处和机会。 您越了解这一点，您就越能够为收件人提供更细致和丰富的体验。 您改善电子邮件体验的大部分机会取决于对电子邮件传递的细微差别的理解以及自动化应用程序相应处理和处理它们的能力。 因此，让我们看看任何电子邮件的生命周期中的关键事件。

排队

一旦您的应用程序从各种内容中组装了一封电子邮件，您就可以将其排队等待发送。 在您的应用程序中，您需要确保通过后台处理发送电子邮件。 稍后我们将深入讨论这一点，但简单的版本是，每当您的应用程序与 3rd 方服务通信时，您都希望在后台处理该通信。 假设您使用的是电子邮件服务提供商，一旦您向他们的 API 发出请求，它也会排队等待发送。

发送

与任何服务一样，您的电子邮件服务提供商将有自己的队列来处理和发送您的电子邮件。 在大多数情况下，这些队列非常快。 向成千上万的收件人发送批量电子邮件可能需要几秒钟或几分钟的时间，但大多数交易电子邮件的发送速度会快得多。

公认

电子邮件由您的电子邮件提供商发送后，理想情况下，收件箱提供商会接受该电子邮件。 但是，“接受”并不意味着“已交付”。 把它想象成邮政服务。 仅仅因为它有你的信，它仍然需要在它被认为已送达之前对其进行处理。 此外，一些收件箱提供商会接受电子邮件，但由于各种原因最终不会送达。 因此，即使电子邮件已被接受，也无法保证最终会送达。

被拒绝

虽然一些收件箱提供商会悄悄地拒绝电子邮件，但在大多数情况下，当电子邮件被拒绝时，它会明确地完成，并且您会收到电子邮件问题的解释。 在某些情况下，它可能是 IP 或域声誉，也可能是电子邮件的内容。 不幸的是，您并不总是能清楚地解释拒绝的原因。

弹跳

退回是一种更具体的拒绝类型。 如果电子邮件地址不存在、收件箱已满或其他原因，邮件服务将报告发送失败并退回电子邮件。 在这些情况下，您可以使用 ESP 的退回处理通知来主动采取措施纠正问题。 稍后我们将更详细地讨论这一点。

发表

Delivered 是消息已发送给收件人的状态。 它可能已发送到收件箱、垃圾邮件文件夹或 Gmail 的某个选项卡，但在某种程度上已被发送。 您永远不会收到电子邮件已送达的明确通知，但它是生命周期中的关键状态。

打开/点击

打开跟踪并不完全可靠，因为用于确定电子邮件何时打开的方法可能会被电子邮件客户端阻止。 由于打开跟踪依赖于电子邮件客户端来加载不可见的图像，因此阻止图像加载的客户端意味着这些打开不会被报告。 开放率可以作为交付的良好代理。 例如，如果您切换电子邮件服务提供商而不更改您的电子邮件的任何内容，并且您的打开率显着提高，则可以安全地假设您的第一个电子邮件服务提供商未能传递部分邮件。

点击跟踪比开放式跟踪更可靠，但它本身也会带来复杂性。 例如，使用 Bit.ly 或其他 URL 缩短服务是垃圾邮件发送者常用的策略，因此在大多数情况下，Bit.ly URL 的存在将使您的电子邮件快速进入垃圾邮件文件夹。 但是，如果通过您的电子邮件服务提供商的点击跟踪做得好，它可以为您的电子邮件提供有用的见解。 此外，即使打开跟踪被客户阻止，如果有人点击电子邮件，也可以安全地假设该电子邮件已打开。 因此，点击跟踪也可以帮助提供关于开放率的更准确的见解。

对于打开和点击跟踪，重要的是要考虑隐私。 虽然它们可以成为丰富收件人体验并为您提供可用于改进电子邮件的见解的强大工具，但它们也涉及隐私问题。 如果你不打算对他们提供的数据做任何事情，你最好不要使用它们。 或者，如果您所在的行业对隐私非常敏感，您可能需要在启用它们之前三思而后行。

退订

虽然退订与交易电子邮件的相关性较低，但它仍然是一个应该得到尊重的请求。 虽然您可能没有法律义务支持退订交易电子邮件，但这是您可能会遇到的一种状态，当您这样做时，您应该尊重它。

垃圾邮件投诉

与退订一样，垃圾邮件投诉在交易电子邮件中的频率较低，但它们仍然会发生。 如果您的垃圾邮件投诉率很高，则表明您需要调整发送的交易电子邮件的数量和/或质量。 与退回邮件处理一样，您也需要主动处理垃圾邮件投诉。 你会想要尊重他们，但重要的是要记住一些垃圾邮件投诉是偶然的。 如果有人将电子邮件报告为垃圾邮件，则可能会影响他们接收未来的账单或发票。

这给我们带来了第四个技巧：

4. 将消息事件紧密集成到您的应用程序中

大多数电子邮件服务提供商都提供了广泛的 Web 挂钩，以自动通知您的应用程序有关每条消息的关键事件。 虽然退回处理是跟踪和处理的最关键事件，但其他事件可以提供有用的信息来丰富您的应用程序并使交易电子邮件成为用户体验中更加无缝集成的元素。

小心电子邮件内容

您的电子邮件内容可以在交付和参与方面发挥作用。 虽然某些规则（例如避免使用“伟哥”一词）可能很明显，但其他规则则更为微妙。 精心制作好的内容可以大大提高打开率或参与度。

我们将几个考虑因素分组到我们的第五个关于出色交易电子邮件的提示中：

5. 花时间精心设计电子邮件的内容和结构

发件人姓名和电子邮件地址、主题、预标题和 mime 类型等内容可能会对参与度、交付和打开率产生有意义的影响。 不要让这些元素成为事后的想法。 花时间让它们正确并不断测试和改进它们，就像它们是您应用程序中的任何其他页面一样。

发件人、主题和预标题

虽然每个电子邮件客户端都不同，但它们都在通过某种预览打开电子邮件之前提供了有关电子邮件的某种程度的洞察力。 这可以像显示发件人和主题一样简单，但有时也包含内容的预览。 这个主题可以证明一篇文章本身的合理性，但只要说它值得花一些时间以收件人的方式查看您的电子邮件就足够了。 这包括清楚地命名发件人，编写有用且简洁的主题行，以及制作完美的预标题。 不要让这些元素成为事后的想法，因为它们会对您的打开率产生重大影响。

HTML 和纯文本

电子邮件的实际内容很重要，包括电子邮件的 HTML 和纯文本版本会对收件人产生巨大影响。 有些人喜欢纯文本。 无论是出于性能、隐私还是可访问性，提供格式良好且经过深思熟虑的纯文本选项对接收者来说都是一种胜利。 一些垃圾邮件过滤器更喜欢看到与 HTML 版本配对的纯文本版本。 Litmus 有一篇关于电子邮件中纯文本选项重要性的精彩文章，以获取更多详细信息。

接受回复并避免“无回复”地址

尽你所能避免使用“无回复”电子邮件地址。 他们以各种可能的方式发送错误的信号。 结果，您会收到更多垃圾邮件投诉，因为人们无法回复退订。 这是一种单向的沟通方式，减少了原本可以提高可交付性的参与度。

理想情况下，发件人地址或回复地址会将回复发送到受监控的支持收件箱。 这为收件人提供了最佳体验，并确保回复不会丢失。 但是，需要牢记一个主要考虑因素。 如果用户收到密码重置 URL 并回复，则有权访问回复的任何人也将有权访问该密码重置 URL。 对于任何特别敏感的信息也是如此，但是，考虑到所有因素，您无论如何都不想在电子邮件中发送高度敏感的信息。

另一种选择是使用入站接收电子邮件地址。 在诸如评论通知之类的情况下，收件人直接回复电子邮件可能很有用，设置入站电子邮件处理可以使您能够避免无回复电子邮件地址。

无论采用何种方法，您都应始终尽力避免无回复地址。 您的客户会欣赏它，如果您在所有渠道上收听，您将更有可能收到重要的反馈。

小心处理电子邮件

电子邮件的内容很重要，但您如何交付它并通过交付响应边缘案例也同样重要。 您发送的每封电子邮件都会发生（或可能发生）很多事情。 虽然大多数与电子邮件的对话都只关注发送它，但发送它的方式也同样重要。

我们将把这一批分组到第六个高级技巧中，以实现出色的事务性电子邮件传递：

6.投资基础设施以可靠地发送和传递电子邮件

发送电子邮件听起来很简单，但不仅仅是编写几行代码。 构建和维护适当的基础架构（如后台处理和退回处理）以确保电子邮件的最高可靠性非常重要。

后台处理

假设您使用的是电子邮件服务提供商，您需要确保所有电子邮件发送都是通过后台进程进行的。 与任何外部服务的任何通信都是这种情况，有几个原因。 首先，对于外部服务，它总是有可能出现故障。 因此，如果请求失败，重要的是能够在设定的时间段后自动重试请求。 或者，请求可能存在问题，或者外部服务可能发生了某些变化。 无论出于何种原因，在您的电子邮件发送中设计弹性将在某些时候为您节省一些悲伤。

同样，良好的后台处理设置可以在出现问题时更容易得到警报和解决问题。 如果您在队列过多时设置警报，您将在出现问题时更快地知道。 此外，假设您的后台处理正在捕获和记录错误，您将更容易确定问题的根源。

了解专用 IP

如果您在任何程度上研究过交易电子邮件，您可能已经遇到过使用专用 IP 地址的概念。 虽然使用专用 IP 地址有很多好处，但这并不是非黑即白的问题。 在某些情况下，专用 IP 地址的弊大于利。

对于几乎每个电子邮件服务提供商，您都有两种发送方式。 第一个选项是从共享 IP 池发送。 在这些情况下，您的投递可能会受到使用同一 IP 地址的其他发件人的行为的影响。 如果这些发件人是邪恶的，它可能会降低 IP 地址的声誉。 但是，如果这些发件人是好的，它可以提升 IP 地址的声誉。

第二个选项是专用 IP 地址。 使用专用 IP 地址，如果 IP 地址存在声誉问题，只能怪你自己。 问题是，为了让专用 IP 地址正常运行，您必须拥有稳定的每日流量，足以建立和维持声誉。 每天大约有 10,000-20,000 封电子邮件。 您还必须小心，通过在设定的时间段内持续发送更多邮件来慢慢预热 IP 地址。 而且，虽然没有坏的发件人会降低您的声誉，但它也不会从可以帮助提升您的 IP 声誉的好发件人那里获得任何好处。 对于大多数电子邮件服务提供商，专用 IP 地址的成本也更高。

最后，虽然 IP 声誉仍然发挥作用，但收件箱提供商越来越多地将域声誉与 IP 声誉结合起来。 由于 IP 地址越来越可随意使用，因此在域上增加声誉有助于减少垃圾邮件发送者在域中循环使用，因为新域必须建立声誉。 这也意味着，如果您遇到广泛的交付问题，这些问题可能归因于 IP 地址或您的域。 因此，交换 IP 地址可能会有所帮助，但如果您的域名声誉受损，更改 IP 地址将无济于事。 相反，您必须专注于清理您的域声誉。

虽然在适当的情况下专用 IP 地址可能很棒，但它不是一个灌篮高手。 而且，如果您使用的是共享 IP 地址，则需要确保密切监视它，以确保其他发件人不会破坏其声誉或将其列入黑名单。

反弹处理

电子邮件反弹。 没有办法解决它。 反弹的原因各不相同，但优雅地处理反弹的需求是普遍的。 将退回处理视为电子邮件的异常处理。 当异常发生时，您不希望它被默默地丢弃。 您想知道它发生了以及是什么原因造成的，以便您可以修复它。 有一个警告的反弹处理也是如此。 通过退回处理，您可以授权您的用户自己解决大多数问题。 这同时提高了客户满意度并减少了支持请求。

当电子邮件被硬退回时，最重要的步骤是停止尝试将其发送到该地址。 虽然一些硬退回可能最终会自行重新开始工作，但重复退回到同一地址对收件箱提供商来说是一个非常负面的信号。 从他们的角度来看，这意味着您没有保持列表整洁，并且很有可能您是垃圾邮件发送者。

不幸的是，如果您停止尝试向某个地址投递，而该地址又开始工作，您的收件人将无法收到他们的电子邮件。 这就是退回处理的用武之地。使用 webhook，您的电子邮件服务提供商可以自动通知您新的退回。 然后，您可以使用该信息在应用程序中显示发送电子邮件时出现问题的警报。 这样，您的用户可以更正问题，然后重新激活交付。

Postmark 使用 Rebound 使这更加容易，这是一个简单的 JavaScript 片段，可以自定义并包含在您的应用程序中，以主动提醒用户注意交付问题，以便他们可以在问题导致更大的问题或支持请求之前纠正问题。

通知管理

对于事务性电子邮件，与批量促销电子邮件相比，退订问题更小，但为收件人提供一种方法来取消订阅或管理他们收到的事务性电子邮件的数量或类型仍然是一件好事。

如果收件人不想收到某些类型的通知的电子邮件，一键取消订阅您发送的每种类型的电子邮件可以使事情变得方便。 或者，为交易电子邮件提供偏好中心是让收件人掌握更多控制权的好方法。 但是，如果您选择偏好中心路线，请将选项保持在最低限度。 请记住，带有大量复选框的页面可能会让人不知所措或令人困惑。 因此，虽然精细控制很好，但太多的选择可能会适得其反。

减少频繁通知的最佳方法之一是提供即时、每日或每周摘要等选项。 这样，您就可以让收件人对通知进行重大控制，从而使他们能够大幅减少通知数量，而不会对数十种不同类型的通知进行细粒度控制而使他们不堪重负。

无论采用哪种方法，都要认识到控制通知的频率可以大大帮助您的客户，同时也有助于减少您的电子邮件总量。 这对您的客户和您的电子邮件成本来说是双赢的。

工具和监控

虽然应用程序开发的其他方面在工具、最佳实践和可靠性方面取得了令人瞩目的进步，但电子邮件仍然是一个黑盒子。 通过应用程序，您可以监控正常运行时间、页面加载时间、应用程序性能以及无数其他方面。 但是，由于电子邮件收件箱是私密的，因此无法准确衡量真实的投递信息。 打开率和点击率可以作为不错的代理，但它们仍然只是代理。 幸运的是，有一些很棒的工具可以相互补充，共同为您的电子邮件传递提供一个相对清晰的画面。

这是了解我们的第七个也是最后一个提示的关键：

7. 使用可用的工具来监控和改进您的交付

就像您要监控应用程序的正常运行时间或性能一样，监控电子邮件发送也同样重要。 虽然没有一个工具可以告诉您一切，但强大的工具的组合可以在确保您的电子邮件传递可靠并帮助解决那些不可靠的时候产生巨大的差异。

为了获得良好的覆盖率，您将需要使用以下工具并密切关注随时间变化的模式。

1. 监控电子邮件的打开率和点击率趋势。 它只是一个代理，但它对相对历史数字有好处。 例如，如果您注意到您的打开率或点击率随着时间的推移而急剧下降，这通常是您可能遇到交付问题的早期预警信号。 由于如果电子邮件未成功送达，则无法打开电子邮件，因此送达问题可能会导致打开率下降。
2. Gmail 提供 Postmaster 工具，可帮助您评估 IP 和域声誉，以了解哪些电子邮件来源可能存在递送问题。 当您怀疑自己可能遇到交付问题时，这是一个很好的取证工具。 它仅提供来自 Gmail 的洞察力，但这通常是了解您的声誉如何看待其他提供商的一个很好的代理。
3. 使用 MXToolBox 黑名单 检查您的域或 IP 地址是否已列入黑名单。 如果您使用的是共享 IP 地址，您可能希望为该共享 IP 地址设置一个永久的自动监控器，这样您就可以更快地知道自己是否最终被列入黑名单。
4. 使用 GlockApps 或 250ok 之类的工具来监控您的电子邮件的收件箱位置。 重要的是要记住，这些工具依赖于种子列表来测试交付。 也就是说，由于他们无法测试发送到真实收件人的收件箱，因此他们必须使用测试地址作为代理。 与大多数电子邮件传递工具一样，这不是一门完美的科学，但在实践中，它已经足够接近，在衡量传递质量方面仍然非常有用。

您拥有的监控和警报越多，您就会越早了解问题并能够纠正它们。 通常，糟糕的电子邮件传递可能是一个无形的问题，只有在支持请求开始出现时才会出现，但到那时，您可能已经有 100 或 1,000 封电子邮件最终进入垃圾邮件文件夹或根本没有到达。 就像您不希望您的客户成为提醒您应用程序停机的人一样，您也不希望他们首先提醒您注意潜在的交付问题。

把它放在一起

在发送电子邮件方面，您有很多选择。 如果您愿意，您甚至可以设置服务器和邮件传输代理 (MTA) 并自己发送，但您将承担很多责任和开销。 管理声誉是困难的。 与 ISP 建立关系更加困难。

除非发送电子邮件是您的核心服务，否则您通常最好求助于电子邮件服务提供商。 即便如此，重要的是要认识到出色的交付并非已成定局。 尽管所有 ESP 都声称它们提供了出色的交付，但情况并非总是如此。 在大多数情况下，当您评估 ESP 时，如果您使用上述工具为自己获取可量化的交付信息，而不是相信他们的话，您会做得更好。 This is true whether you use a shared IP address or a dedicated IP address. Great delivery isn't automatic, and you should always be gathering hard data on your delivery.

Regardless of how you handle email, make sure to treat it as an extension of your application's user experience rather than an afterthought. Take time to write concise and helpful emails, and do everything possible to seamlessly integrate it into the user experience. Be judicious about firing off too many emails, and give your users the ability to tune email notifications for their needs.

Finally, monitor your transactional email delivery like you would any other service in your stack. If your users aren't receiving critical emails like password resets and invoices, you'll be losing goodwill, and your support costs will increase. Don't let your email delivery fail quietly. Make sure that you're notified quickly and loudly of any potential delivery issues long before it gets bad enough for your customers to email you.

Your application can't work without email. While it's not as easy to measure or monitor as most aspects of your application, it's still a critical piece of functionality that deserves your full attention. Invest the time in making your email experience great, and you'll unquestionably reap the rewards.