🦋 🧚🏿 ⏸️ 如何制作电子邮件而不是一团糟：实用技巧 🤽🏼 ☢️ 🐐

最初遇到生成电子邮件的开发人员几乎没有机会编写可以正确执行的应用程序。公司应用程序生成的电子邮件中，大约40％违反某种形式的标准，因此，传递和显示存在问题。这是有原因的：电子邮件在技术上比网络更难，并且电子邮件的操作受数百种标准以及不计其数的普遍接受（而不是那么多）实践的规范，而电子邮件客户则多种多样并且比浏览器更难以预测。测试可能会大大改善这种情况，但是实际上不存在用于测试电子邮件系统的材料。

Mail.ru定期通过电子邮件与其用户互动。在我们的项目中，所有负责生成电子邮件甚至单个邮件的组件都必须经过强制测试。在本文中，我们将分享我们的经验（从错误中学习）。

有什么样的电子邮件？

该应用程序可以生成各种类型的电子邮件。它们可以分为几类。通过选择收件人的方法-个人/触发-选择性组。预约：交易-营销-服务。您可以为不同类型的电子邮件设置不同的要求，并应用各种测试方案。

触发个人电子邮件是响应任何事件（例如，用户操作或系统对象的状态更改）而生成的。它们是由应用程序生成的，因此在测试方面是最有趣的。触发的电子邮件可以是交易，市场营销和用于服务。选择性电子邮件将发送给满足某种形式的条件的动态用户选择。组电子邮件将发送给永久的收件人组，例如所有用户或合作伙伴。选择性电子邮件和组电子邮件通常供市场使用，并且手动或按计划开始发送此类电子邮件。

交易电子邮件是在用户完成某种形式的操作的过程中生成的。此类电子邮件包括（例如）发票，票证或交付状态通知。交易电子邮件始终被触发，并旨在携带重要信息。它们应该尽可能简单和兼容，并且应该在大量邮件客户端上进行测试。

营销电子邮件会鼓励用户采取行动，例如，这可以是基于先前购买的个人折扣优惠。可以在这些电子邮件中利用交易数据，并且可以触发电子邮件或批量，定期或一次性触发交易数据。对于这些电子邮件，效率更为重要，而拆分测试的结果通常决定了它。为了效率，可以牺牲兼容性的某些方面。

团体营销电子邮件（例如，有关季节性优惠，促销和销售的消息）通常是“手动”发送的，不属于您的应用程序，但您可以（也应该）对它们应用常规测试原则。

同样，可能会有服务电子邮件：为员工，自动CRM系统，日记，审计或DWH生成的通知。此类电子邮件通常是触发的电子邮件，这意味着它们也是应用程序的一部分，必须经过测试。

谁参与测试和控制过程？

质量检查工程师-参与过程的所有阶段。
网络工程师-负责配置网络基础结构和消息传递基础结构。网络工程师应参与计划和基础架构测试。
传递专家-监视电子邮件的可传递性的人员，还参与监视所有已发送电子邮件的技术和管理参数，并监视邮件处理的进度。他负责确保已发送的电子邮件达到了最高的用户百分比，并且不会最终成为垃圾邮件。为此，专家必须具有特定的知识和联系方式。如果电子邮件的发送有任何问题，他就是必须了解可能原因并消除它的人。消除技术障碍；或更改电子邮件内容中的某些内容；或尝试使用邮件提供商无法提供的支持服务来解决问题。此类专家（如果有）还应参与制定清单，并测试生成应用程序和电子邮件的基础结构。但是，测试过程本身应在质量检查服务的控制之下。
电子邮件营销人员-确定营销通讯的有效性。在他的控制下，进行了将营销分配给受众的拆分测试。电子邮件营销人员还控制用户群的细分，已发送电子邮件的组成和频率，电子邮件向用户的可视化“呈现”。

所有这些角色不一定都由专职员工来担任；营销人员的角色可以由产品经理之一执行，而交付专家的角色，例如，可以由支持员工或网络工程师执行。在初创公司中，很可能所有这些工作都必须由一个人来处理，而且他们最终可能成为质量专家。

邮寄和邮件运输

电子邮件结构就像一个巨大的冰山，其中有两个层次。电子邮件管理标准有一百多种，但几乎所有标准都属于以下两个级别之一：

冰山的水下部分 -网络服务，其基本协议是RFC 5321定义的SMTP应用程序协议。它负责电子邮件的传递。形成了用于发送电子邮件的所谓SMTP信封，其中包括SMTP级别的发送者和接收者的地址。其他网络服务（例如DNS）也负责传递电子邮件。网络基础结构的主要组件是邮件传输代理（MTA）。 MTA负责将邮件传递队列和传递过程本身传递给收件人服务器。 MTA示例包括Postfix，Sendmail，Exim，Microsoft SMTP服务。

冰山的水下部分包括MTA，DNS参数和其他网络参数，我们将其称为电子邮件基础结构或邮件传递基础结构。

冰山一角 -电子邮件本身。电子邮件的基本结构由标准RFC 5322定义。电子邮件由服务标头和一个或多个数据部分组成。数据可以是纯文本格式和/或HTML甚至是AMP，并带有内联图像或几乎任何类型的附件。

电子邮件基础结构的界面和已测试应用程序的边界

通常，电子邮件基础结构具有一个或多个接口，通过该接口发送电子邮件（当电子邮件进入MTA传递队列时）。例如，SMTP提交服务，PHP中的函数mail() ，向外部邮件或sendmail应用程序的数据传输，用于内部或外部服务的API（例如GetResponse，SendPulse或Amazon SES）。我们将这些接口视为基础架构的一部分。经常发生的情况是，应用程序A为电子邮件和收件人列表准备数据，然后通过其API将其发送到应用程序B（对于大批量邮件营销，可以通过用户界面UI手动完成），然后应用程序B生成RFC 5322中的邮件消息，并将其传递到MTA。对于应用程序A（以及在对其进行测试时），应用程序B将成为电子邮件基础结构的一部分。应用程序B的API或UI将用于邮件基础结构的应用程序A接口。尽管对于应用程序B，情况将有所不同，并且其邮件基础结构将是较低级的网络应用程序或协议。

测试参数的定义

在测试每个应用程序时，重要的是选择它使用的所有邮件基础结构（可能有多个），并为每个基础结构挑选出所使用的接口（每个基础结构也可能有多个）。对于每个接口，将尽可能准确地确定传输给它的数据的组成和格式，例如TEXT / HTML中的电子邮件文本，TEXT / PLAIN中的电子邮件文本，电子邮件主题，收件人名称，收件人地址，发件人姓名，发件人地址（RFC5321.From），SMTP对流发件人的地址（RFC5322.mailfrom）。接下来，为每个参数（表示，编码，边界值等）制定一组要求，确定用于监视每个参数的方法（如何将实际结果与预期结果进行比较）。

发电应用的典型结构

通常，我们正在测试的同一产品负责其中的电子邮件和数据的生成。这通常是服务器（但有时是客户端）应用程序。它定义了电子邮件的结构，部分服务标题，数据封装格式，字符串表示形式和文本编码。此类应用程序的一个简单示例是构成电子邮件并调用mail()函数的脚本。必须控制的应用程序的主要元素是：

如果电子邮件结构是动态生成的，则负责生成标头和/或电子邮件结构的代码，和/或描述其结构的静态电子邮件模板；
电子邮件的HTML布局（理想情况下，它是电子邮件模板/布局的单独实体或一部分，但可以嵌入应用程序代码中）；
将应用程序数据替换为电子邮件（或电子邮件模板）；
应用程序与电子邮件传递基础结构的集成，传递给基础结构接口的参数的正确性。

什么时候测试

无论我们是否喜欢，都应该对整个冰山进行测试。有几个主要组件需要测试：

交付基础设施

应着重测试：电子邮件的可传递性；正确的DNS记录，包括PTR / FCrDNS，MX和A记录； SMTP协议参数（HELO，使用TLS）；电子邮件授权（SPF / DKIM / DMARC）； SMTP信封地址（如果应用程序不对其进行管理）；处理基础结构接口的输入参数的正确性；跟踪，记录和处理未送达的电子邮件。

在初始实施期间以及每次更改基础结构本身（MTA的配置，DNS或网络更改）或发送电子邮件的接口时，都必须测试基础结构；使用新的域，网络或API；如果发送的电子邮件的特性（例如语言，大小或数字）发生了显着变化，则需要进行其他测试。根据经验，基础结构倾向于“自身”更改，因此即使没有任何更改信息，也应定期进行基本测试。

可能且有必要让网络工程师和可交付性专家参与制定计划和检查基础结构的清单。

生成应用

应当监视SMTP信封的地址（如果应用程序控制它们，即它们已传输到接口-信封从，信封到），电子邮件的服务标头值（日期，消息） -ID，列表取消订阅，自动提交等）。条款），电子邮件授权（DKIM / DMARC），MIME编码（base64，带引号的可打印内容），电子邮件格式的一般正确性，例如，标头中没有非ASCII字符，注入的数据组成，触发器的正确触发，退订机制，写入和收集统计信息的跟踪机制（邮局主管标头，例如Feedback-ID或X-Mailru-Msgtype，以及跟踪像素）。

有必要在应用程序开发过程中对其进行测试，包括负责生成和存储数据的所有相关组件发生变化，电子邮件模板发生重大变化，更改所使用的基础架构或接口以及在该应用程序框架内进行测试。一般回归。

结构和排版电子邮件模板（可以是生成应用程序的一部分，也可以单独开发）

检查电子邮件的结构（内容类型，内容处置，电子邮件多部分的嵌套，文本编码，字符串参数），目标值和显示的标头（从，到，回复到，主题）），电子邮件在电子邮件列表中的显示方式以及在各种界面，微格式（例如，将日历事件识别为日历事件或将机票识别为机票）阅读，品牌化时的方式。

每次进行至少最小的更改时，都应分别测试电子邮件模板，以及分别进行测试，例如，在服务器准备就绪之前电子邮件进入应用程序的情况下。

建议让电子邮件营销专家和可传递性专家参与，以编写清单来测试电子邮件模板。

检查基础结构的基本要求

为邮件服务器选择的IP地址应尽可能接近邮件服务器的IP地址。建议使用whois实用程序进行检查。尤其是，发件人的地址不应属于网络，可以视为动态网络。所选网络必须具有活跃的联系人，可以向其发送投诉；必须使用网络（RIPE中的状态为ASSIGNED）IP地址必须具有正确配置的PTR记录。可以通过托管控制面板或在服务提供商的帮助下对其进行独立配置。 PTR记录必须指向真实主机名，并且仍然有意义，必须解析回相同的IP地址（所谓的FCrDNS检查），不提醒动态主机名，并且不包含大量数字或字符。一个很好的例子是mailserver.example.com。

信封地址或电子邮件标题中使用的每个域都必须具有指向主机A记录的有效MX记录，该记录至少可以处理无法传递的邮件。不允许MX直接引用IP地址。

控制SPF，DKIM，DMARC的通过。 SPF允许域所有者在TXT记录中指定一列服务器的列表，这些服务器有权发送带有该域中返回地址的电子邮件。它配置为用于管理域的DNS区域的部分中的信封来源（SMTP-信封）中使用的地址。 DKIM使用数字签名技术提供对邮件或其发件人到特定域的作者身份的验证，该签名已添加到电子邮件本身（在其DKIM-Signature标头中）。通常，DKIM签名是在MTA（基础结构）级别配置的。 DMARC设置了检查特定域中的传入邮件的策略，并对未通过SPF或DKIM身份验证的电子邮件采取措施。尝试违反此策略时，将提供结构化报告以及有关此类尝试的信息。 DMARC和SPF在域区域中作为TXT记录发布。

检查电子邮件对主要邮政服务的可传递性-适用于俄罗斯Mail.Ru，Yandex，Gmail，Microsoft（Hotmail / Outlook.com / Office365），Rambler，nic.ru。在收到的电子邮件中，您需要检查HELO的正确性； PTR / FCrDNS，SPF，DKIM和DMARC检查的存在和通过；标头和其中的数据的有效性，尤其是时钟在日期中的同步性和时区的正确性。

（由于使用了免费邮件地址，注册邮件的验证失败）

某些参数的形成（例如，授权，可传递性和垃圾邮件）受所有组件的整体影响，但是对于它们的控制，通常有单独的操作工具-DMARC和FBL报告，邮政局长服务API，电子邮件跟踪工具，传递统计信息。测试应考虑公司运营监控工具的实施水平-例如，在没有DMARC报告的运营控制的情况下，应定期测试电子邮件的授权，而在没有交付能力的运营控制的情况下，以及电子邮件的运行方式，即使没有与发送电子邮件相关的进展。

要测试基础结构，可以使用专门的服务，例如mail-tester.com，mxtoolbox.com。详细的基础结构要求可以在本文中找到。

（SPF记录损坏的示例）

认证要求

通常可以使用收件人服务器上的Authentication-Results标头检查SPF，DKIM，DMARC的通过。

检查SPF记录的有效性，以了解语法和DNS查询的限制（例如，使用mxtoolbox.com）。形成SPF时，应考虑所有邮件来源（请不要忘记CRM系统，所有当前使用的传递基础结构，包括进行一次性营销活动的那些基础结构）。建议通过网络列表（“ ip4” /“ ip6”）为域设置允许的服务器。从SMTP信封中检查SPF以查找发件人地址。验证SMTP信封域（envelope-from）是否与From头中的域匹配。这篇文章中列出了常见的SPF错误（https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817）。

检查DKIM DNS记录，DKIM签名的有效性和组成。验证您使用的是至少1024位的DKIM密钥。推荐的DKIM签名的哈希模式：宽松/宽松。确保所有重要标头均已签名（“发件人”，“收件人”，“主题”，“日期”，“邮件ID”，MIME版本，“内容类型”），跟踪标头（“接收”，“传递至”，“返回路径”）未签名，并且DKIM已针对基本邮件服务进行了验证。设置转发到其中一个邮件服务到另一个； DKIM不应在转发的电子邮件中“跳动”。验证DKIM签名域是否与“发件人”标头中的发件人域匹配。

检查DMARC中的基本电子邮件服务。检查DMARC报告，确定基础结构的所有IP地址的SPF和DKIM并进行故障排除。

验证是否使用加密（TLS）将邮件传递到了外部服务器。您有时可以通过收件人服务器上的Received标头检查TLS：例如，指定ESMTPS协议或具有以下形式的参数（版本= TLS1_2密码= ECDHE-RSA-AES128-GCM-SHA256位= 128/128）；表示存在TLS。

验证生成的应用程序

电子邮件地址要求

信封地址

我们使用SMTP信封中的地址开始验证生成的应用程序。
信封地址是电子邮件基础结构级别的地址。它们对用户不可见，但是对于传递很重要，因为信封的地址决定了电子邮件进入哪个邮箱。

信封中的收件人地址 （ envelope-to ，也称为RCPT TO:是电子邮件实际发送到的地址。

对于除注册之外的所有电子邮件，必须根据管理要求对地址进行合法签名和验证以进行邮寄。
对于新闻通讯，该地址必须是“实时”的，不能定期向其发送电子邮件的地址应标记为无效，不应该发送邮件。但是，某些类别的电子邮件（例如访问恢复）也可能需要发送到以前标记为无效的地址。

SMTP信封中的发件人地址 （通常称为envelope-from ， smtp.mailfrom ， MAIL FROM:或Return-Path ）-有关无法发送电子邮件和自动回复的消息将被发送到该地址。该地址对用户不可见。此地址也用于SPF授权。我们验证：

地址可用；
它不是员工的地址，也不会重定向到他的位置，以排除自动答复，有关无法进入的消息等；
它由脚本处理，该脚本会将无法访问的用户的地址标记为不活动；
该地址可以自动生成，即每个电子邮件都唯一；
发送到该地址的电子邮件不应导致生成任何响应电子邮件，例如，有关邮箱溢出的消息。

电子邮件标题地址

这些地址对用户直接可见，或在回复电子邮件时使用。
发件人地址（标头From:是电子邮件列表中和阅读电子邮件时显示的地址和发件人名称。我们验证：

这是一个易于识别的友好地址，用于标识公司。
它不仅包含电子邮件地址，还包含发件人的姓名。
Noreply @是可能的，但是只有在我们要强调我们不希望收到对电子邮件的答复并且不会被阅读时，才可以。最好在电子邮件的文本中重复此想法。
在存在非ASCII字符（例如西里尔字母）的情况下，发件人名称必须按照MIME进行编码，在存在非ASCII字符的域中必须使用Punycode进行编码
相同类别的电子邮件应具有相同的地址；应避免使用自动生成的地址。这是由于以下事实：人们最常使用“发件人：”来使用过滤器按文件夹对电子邮件进行排序。
对于交易，市场营销和紧急电子邮件（例如来自支持服务的电子邮件），地址应该不同（最好在不同的子域中）。这也是由于用户可以将营销电子邮件标记为垃圾邮件或将其过滤到不可读的文件夹中。
地址From:和SMTP信封地址必须位于同一域或同一组织域的子域中，以便在DMARC中传递SPF。
地址必须来自组织的域。在From:使用免费邮件服务和其他公共邮件域是不可接受的From:因为这样的邮件将不会在DMARC框架内通过SPF和DKIM身份验证。

用户答复电子邮件时，地址“回复-'手动”回复将发送到该地址。它是可选的。如果不存在，则使用“发件人：”中的地址作为响应。检查“答复”：

它可以自动生成，即对于电子邮件是唯一的（允许您找出答案来自哪封电子邮件）。
它不应掉入员工的邮箱中以避免自动应答，而理想情况下应“包装”在CRM中。
它可以生成标准的CRM自动应答，但不应生成多余的内容，例如邮箱溢出或“正在通话”消息。生成自动响应时，必须采取避免循环的措施，它们在RFC 3834中列出。
它可以来自不一定与“发件人：”一致的任何域，但是有时这会在回答时使用户感到恐惧。
可能不存在，然后“ From:地址将执行其功能。
除地址外，还显示发件人的姓名。

地址To:

必须包含收件人的电子邮件（否则，它会使邮件的收件人害怕并打扰反垃圾邮件）。
理想情况下，它应该包含收件人的姓名。但是，如果姓名不明或可疑（例如，地址尚未确认），则最好不要注明（有人可能输入名字不正确的人的地址，而收件人可能会受到冒犯）。

电子邮件标题要求

文本的实际编码应与标题中指示的编码匹配。建议在电子邮件的所有标题和部分中使用一种编码。建议您将UTF-8用作广泛支持的UTF-8。编码在Content-Type标头和HTML部分的标签中指示。

“发件人：”，“消息ID：”和“日期：”标题应直接在用于发送电子邮件的脚本中形成（并按照标准-连同电子邮件的文本一起），并且始终采用正确的格式。如果它们不存在或格式不正确，则其中一个传输服务器可以添加这些标头，这将导致DKIM签名的完整性受到侵犯。

标头中应缺少8位字符，包括主题行（主题）和附件的文件名（Content-Type和Content-Disposition）；所有非ASCII字符（包括西里尔字母）都必须使用带引号的可打印字符或base64进行编码。

（使用奇怪编码的注册确认）

电子邮件结构要求

对于电子邮件的HTML部分，最好形成一个替代部分-文本（纯文本）部分。还必须检查电子邮件的纯文本部分（如果有）的一致性和可读性以及电子邮件的一般结构。

根据RFC 5322，电子邮件中的行长不应超过998个8位字符。请注意，在UTF-8中，一个字符可以占用几个八位字节。电子邮件中的行终止符是一对CRLF（ASCII 13，ASCII 10），其长度为2个八位字节。您需要检查字符串终止符的正确性，因为电子邮件通常是使用Unix脚本发送的，在Unix中，字符串终止符是单个字符-这是电子邮件的错误。您还应该检查字符串终止符是否破坏了UTF-8编码的字符：您不能允许在同一字符的两个八位字节之间存在字符串终止符，例如，西里尔符号。为避免这种情况，有必要在形成电子邮件之前先中断文本，或在base64中对文本进行编码，base64通常具有固定的行长。

有必要检查附件和内联的正确标记-即，如果邮件中显示的图片是“ Content-Disposition：inline”标头的正确性，或“ Content-Disposition：附件”如果附件文件旨在下载。

电子邮件的结构应尽可能简单：特别是，每种类型的多部分（混合，替代，相关）不得超过一个多部分，并且仅当电子邮件包含文件附件时才使用多部分/混合/相关-如果HTML带有内联图像，则是多部分/替代-如果存在纯文本和HTML部分。通常，在没有附件和嵌入式图片的情况下，电子邮件的结构应如下所示：

多部分/替代
-文字/纯文字
-文字/ HTML

零件的顺序很重要，text / plain必须在text / html或multipart /相关之前。这是必需的，以便在默认情况下显示HTML部件，并且仅当由于某些原因无法显示HTML部件时，才显示普通部件。

如果电子邮件中包含嵌入式图片，其结构应如下所示：

多部分/替代
-文字/纯文字
-多部分/相关
-文字/ HTML
-图像/ ...（在线图片）
-图像/ ...（在线图片）

内联图像必须具有Content-Disposition：内联并且严格位于multipart /相关部分内。
在最困难的情况下，当同时存在嵌入式图像和附件时，电子邮件将具有以下结构：

多部分/混合
-多部分/替代
-文字/纯文字
-多元/相关
——— text / html
———图片/ png
———图片/ png
...
-应用程序/八位字节字符串（内容处置：附件）
-应用程序/八位字节字符串（内容处置：附件）
...
必须先关闭多部分相关部分和多部分/替代部分，附件才属于外部多部分/混合部分）

（零件结构不正确的注册消息）

URI要求

任何URI（以src，href属性，样式等形式）必须包含协议和主机名（https://example.com/somepath）。典型的错误是使用相对链接（/ somepath）和缺少协议（//example.com/somepath），这对于电子邮件是不可接受的，因为在其中，默认协议可能是file:// 。

URI中的任何服务和非ASCII字符（特别是西里尔字母）都必须使用百分比编码进行编码。
仍应使用<>标记标记作为文本插入的链接（即，该链接对于用户而言是URL，而不是作为文本可见），否则，用户将无法单击它。一些网络邮件会自己标记此类链接，但这不是标准行为。在这种情况下，A中的href地址必须与链接文本匹配，否则，内容过滤器可能会对此类链接做出反应，以欺骗用户。当存在“点击器”来跟踪用户从电子邮件的转换时，这尤其值得关注。
最好限制自己使用协议http:// ， https://和mailto:
出于高安全性要求，您应该完全放弃使用http:// ，而转而使用https:// 。
不应使用非标准端口（例如example.com：8080 / somepath），因为用户可能无法访问它们。
单击HTML部分内的链接不应导致应用程序状态发生任何变化（订阅，取消订阅，取消订单等），而无需用户在页面上进行额外确认，因为某些内容过滤系统可以独立进行通过引用请求页面来验证这种过渡的安全性；邮件应用程序可以通过悬停上的链接显示页面的预览，现代浏览器可以在用户单击链接之前加载页面，以减少加载时间（在Web应用程序中，通常不建议对页面进行任何修改操作） GET请求，所有修改请求必须通过POST或PUT）。
相反，单击List-Unsubscribe标头中的链接不需要用户采取任何其他操作，因为此链接的退订通常是由电子邮件程序或Webmail代表用户完成的。另外，RFC 8058还引入了一个新的标题List-Unsubscribe-Post。
您不应该期望用户阅读电子邮件并在启动浏览器导致发送电子邮件的操作的同一浏览器中访问链接（例如，注册帐户）。该链接应可在任何其他浏览器或移动设备上使用。尤其是，用户可以在未经授权的情况下打开链接，也可以在未向其发送电子邮件的帐户中获得授权。
因为可以限制URI的长度；您不应将“ data：”类型的URI用于大型对象。出于同样的原因，请不要在超链接中使用太长的URI。
您不得使用外部链接缩短器，这会对电子邮件的传递产生负面影响。如果所有链接都指向您的域，则更好，这将减少其他人的声誉对电子邮件传递的潜在负面影响。
请勿将外部图像放置在某些公共服务或免费托管上，使用性能良好且声誉良好的可靠托管服务或CDN。

（由于缺少协议规范，因此无效的图片和锚定URI）

电子邮件布局要求

为什么编写电子邮件如此困难？

电子邮件客户端以一种或另一种方式在其界面中显示用户内容。这可能会导致各种安全问题-跨站点脚本（XSS，Crossite脚本），接口欺骗，DOM破坏，用户匿名，信息泄漏（例如，用户的IP地址或通过外部请求提供的cookie）等。因此，任何邮件服务和邮件应用程序都具有某种形式的保护措施，可抵御每种类型的攻击。不幸的是，没有单一的方法来组织这种保护。可以通过以下方式进行组织：

孤立的有限帧
过滤标签和/或属性，
绝对定位的限制，
禁止或限制使用块样式（这对自适应布局至关重要），
默认情况下禁止外部元素（例如，下载外部图像需要用户许可）或使用代理访问它们，
将HTML电子邮件转换为另一种中间格式（例如，Microsoft Exchange / Outlook使用RTF，这会使使用传统方法在Outlook中正确显示元素极为困难），
禁止或限制使用表格或其单个元素。

电子邮件还使用特定元素，例如嵌入式图像和URI cid:// ，其支持可能受到限制。例如，Mozilla Thunderbird不支持cid://用于背景图像。

由于其实现的特殊性和对电子邮件内容的过滤，即使是格式正确的电子邮件也可以在不同的界面中以不同的方式显示。

如果电子邮件格式中存在错误，则该行为将变得完全不可预测。例如，电子邮件客户端使用不正确的URI可能具有不同的行为，或者不正确的标头格式得到了不同的处理。此外，如果未指定或指定不正确，则文本编码自动检测的工作原理也有所不同。因此，必须在不同的界面中查看电子邮件：在一个界面中正确显示电子邮件并不意味着其构成正确（实际上，即使在所有界面中正确显示电子邮件也不能保证不会出现任何错误）。将来的显示问题）。

有必要注意以下几点：

检查电子邮件中的文本是否包含语义内容，显示，没有错字，句法，拼写和词法错误。
检查电子邮件模板或布局中应用程序数据替换的正确性。
在考虑允许的边界条件的情况下，检查数量，日期，数量，物品和其他信息的正确性。日期应为一年（某些用户很少输入该框）。时区必须及时存在。该地址必须包含城市，在某些情况下，有必要指明国家。
检查电子邮件中所有链接的运行状态（如果有）。
在确认地址之前发送的电子邮件中，包括带有确认链接的电子邮件，不应包含任何从外部控制的文本，甚至包括用户名，否则，它们可以用于垃圾邮件（在电子邮件显示的字段中，例如，在名称中，将插入垃圾邮件文本，该地址是受害者的指示地址）。例如，如果您可以代表您的服务在开发者的地址上发送淫秽文字，则说明存在问题。
检查第三方服务上是否没有外部映像。它可能会影响有关您的客户的交付和泄漏信息。
检查用于发送，递送，阅读电子邮件，转换的计数器的可用性。其中一些位于电子邮件本身中（例如，阅读电子邮件的反像素），一些则由邮件跟踪，但是通常，所有这些都可以在邮件的管理面板中找到。
通过电子邮件中的链接检查订阅类别和用户对该类别的取消订阅的正确性。
检查电子邮件的外观：
- 针对目标国家/地区的邮件的流行网络版本：俄罗斯的“三巨头”是Mail.Ru，Yandex，Gmail。您还可以添加Rambler和Outlook.com。
- 上述电子邮件提供商的移动应用程序；
- 考虑到流行的移动平台，使用IMAP的标准移动应用程序至少适用于iPhone，Pixel（Android参考平台），三星（Android最常见），MIUI（在俄罗斯Android平台上排名第二）；
- 各种桌面浏览器：Chrome，Firefox，Edge，Internet Explorer，Opera等；
- 桌面应用程序（电子邮件程序），尤其是Thunderbird，Outlook和Apple Mail，还可以选择The Bat !！和Opera Mail；
- 具有Web界面（Exchange，可能是Roundcube，Commungate，Zimbra，SquirrelMail）的流行企业解决方案-用于B2B解决方案；
- 不要忘记检查Retina显示器和分辨率较低的显示器的布局。
在每种情况下的检查期间，您需要注意：
- 传递授权标头SPF / DKIM / DMARC。
- 电子邮件下载速度：它应该快速加载，而不花时间。
- 在电子邮件列表中显示电子邮件：化身，发件人的姓名和属于消息摘要的主题，是否正确定义了其类别（例如，如果订单未属于“社交网络”类别）。
- 电子邮件的整体布局：如果布局保持一致，是否有任何不正确的分词符等，包括缩放窗口和调整窗口大小时。
- 字体不应太小或难以阅读。
- 背景图像和背景颜色。
- 匹配品牌书。
- 易于执行电子邮件中隐含的操作。例如，如果电子邮件中包含确认码或其他信息，可能需要将其存储在某个地方，那么它不仅应该易于阅读，而且即使在移动界面中也可以方便地选择和复制它。
跟踪电子邮件的整体大小（包括外部图像），不要超过合理的值。加载时间越长，一个人对其产生负面反应的可能性就越大。
即使是未修改的电子邮件也应定期检查，因为更改可能会在邮政服务方面发生，例如，“泄露”以前不可见的问题。
在所有测试中必须控制某些参数。例如，通过DKIM身份验证的问题可能是由于基础结构方面的问题（DNS问题或DKIM签名的形成，时间同步错误），生成程序中的错误（发件人地址格式错误，标头丢失或必需的“发件人”，“日期”或“ Message-ID标头”重复，并且由于内容错误（错误的行终止符，行太长，地址不正确）。同时，电子邮件可能不会“跳动”，并且该问题可能不会出现在任何服务上。

进行拆分测试

营销研究不在本文讨论范围之内，但应提及一些对电子邮件质量有重大影响的关键点。

The newsletter has a purpose, so it should entail through its quality, not quantity (which is the opposite for spammers). The newsletter must be segmented. When conducting an advertising campaign, you need to know exactly who gets into the segment sample, why they need the offered product and what they want to convey.

For each mailing list, it is necessary to calculate the CTR of the list of emails — this is the ratio of the number of emails read to the total number that has been sent out. In postmaster.mail.ru, you can see indicators for unique users. If the measurement goes through the counter in the email (pixel), then the absolute number of openings is estimated. CTR <10% is a very low indicator, it is undesirable to carry out such mailing. It should strive for a CTR> 30%. For marketing emails, the clickthrough rate of clickthroughs and the percentage of completed actions («sales») on these links are also of great importance. Be sure to monitor complaints (marking the email as spam). Typically, for one-time mailings, a tenth of a percent is a good indicator, for regular ones, a hundredth of a percent. The critical values, after which the mailing is always interpreted as spam, are indicated here: https://help.mail.ru/developers/mailing_rules/technical .

It is necessary to conduct split testing of various distribution options to obtain optimal performance. Just changing the name of the sender and the subject of the email can increase the CTR by several times and significantly reduce the number of complaints. The number of emails should be statistically significant for evaluating the results (for large projects, usually a few thousand). The final version of the email is sent in several stages for additional measurement of indicators and «warming up» — starting with about 10,000 recipients, with an increase of about an order of the day.

The main idea: emails are part of your application, perhaps one of the most complex and problematic. At the same time, this is often a «blind spot» in terms of testing. I hope that I was able to draw your attention to this issue.

I would like to thank Vladimir Dubrovin ( z3apa3a ) and Alena Likhacheva ( s4ever ) for helping me with this article. As well as that, the article utilised sources of Eduard Tyantov ( edT ) and Alexander Purtov ( 4Alexander ).

如何制作电子邮件而不是一团糟：实用技巧