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

A developer, who first encountered generating emails, has almost no chance to write an application, that will do it correctly. Around 40% of emails, generated by corporate applications, are violating some form of standard, and due to this, there are problems with delivery and display. There are reasons for this: emails are technically more difficult than the web, and operating emails is regulated by a few hundred standards, as well as an uncountable number of generally accepted (and not as much) practices, whereas the email clients are more varied and unpredictable than browsers. Testing may significantly improve the situation, but materials that are dedicated to testing the email system, are practically non-existent.

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

Mail.ru regularly interacts with its users by email. In our projects, all the components responsible for generating emails and even individual mailings, are subject to mandatory testing. In this article, we will share our experience (learning from our mistakes).

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

• What kind of emails are there?

  有什么样的电子邮件？

• Who is involved in the testing and control process?

  谁参与测试和控制过程？

• Mailing and mail transport

  邮寄和邮件运输

• The interface of the email infrastructure and the boundaries of the tested application

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

• Definition of test parameters

  测试参数的定义

• Typical structure of a generating application

  发电应用的典型结构

• What and when to test

  什么时候测试

  • Delivery infrastructure

    交付基础设施

  • Generating application

    生成应用

  • Structural and typesetting email templates

    结构化和排版电子邮件模板

• Basic requirements for checking infrastructure

  检查基础结构的基本要求

• Authentication requirements

  认证要求

• Verification of the generating application

  验证生成的应用程序

  • Requirements for email addresses

    电子邮件地址要求

    • Envelope addresses

      信封地址

    • Email header addresses

      电子邮件标题地址

  • Requirements for headers

    标头要求

  • Requirements for the structure of the email

    电子邮件结构要求

  • URI requirements

    URI要求

  • Email layout requirements

    电子邮件布局要求

• Conducting split tests

  进行拆分测试

有什么样的电子邮件？ (What kind of emails are there?)

The application can generate various types of emails. They can be classified into several categories. By the method of selecting recipients – personal/triggered – selective- group. By appointment: transactions- marketing- service. You can set different requirements for different types of email and apply various testing scenarios.

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

Triggered personal emails are generated in response to any events, for example, user actions or status changes of system objects. They are generated by the application, and therefore are the most interesting in regards to testing. Triggered emails can be transactional, marketing, and for service use. Selective emails are sent to a dynamic selection of users, that meet some form of a criteria. Group emails are sent to a permanent group of recipients, for example, all users or partners. Selective and group emails are often for marketing use, and sending such emails is started manually or on a schedule.

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

Transactional emails are generated in the process of a user completing some form of action. Such emails include, for example, invoices, tickets, or delivery status notifications. Transactional emails are always triggered and are meant to carry important information. They should be as simple and compatible as possible, and testing them should be done on a large number of mail clients.

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

Marketing emails encourage the user to take an action, for example, this can be an offer for a personal discount based on previous purchases. Transactional data can be utilized in these emails, and they can be triggered emails or mass-, periodic or one time. For these emails, efficiency is more important, and the results of the split-test usually determine it. Some aspects of compatibility can be sacrificed for efficiency.

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

Group marketing emails, for example, messages about seasonal offers, promotions, and sales, are often sent ‘manually’, and are not part of your application, but you can (and should) also apply general testing principles to them.

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

Also, there may be service emails: notifications generated for the staff, for automated CRM systems, journaling, auditing, or DWH. Such emails are usually triggered emails, meaning that they are also part of the application, and must be tested.

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

谁参与测试和控制过程？ (Who is involved in the testing and control process?)

1. QA engineer – participates at all stages of the process.

   质量检查工程师-参与过程的所有阶段。

2. Network engineer – responsible for configuring network infrastructure and message delivery infrastructure. Network engineer should be involved in planning and infrastructure testing.

   网络工程师–负责配置网络基础结构和消息传递基础结构。 网络工程师应参与计划和基础架构测试。

3. Delivery specialist – person who monitors the deliverability of emails, who also participates in monitoring the technical and administrative parameters of all emails sent, and monitors the progress of the mailing process. He is responsible for ensuring that the sent emails reach the highest percentage of users, and do not end up in spam. For this purpose, the specialist must have specific knowledge and contacts. If there are any problems with the delivery of emails, he is the one who must understand the probable cause and eliminate it; either by eliminating technical obstacles; or changing something in the content of the emails; or try and solve the problem with the support service of the mail provider, to which the emails don’t reach. Such a specialist (if any) should also be involved in coming up with the checklist, and testing infrastructure generating applications and emails. However, the testing process itself should be under the control of the QA service.

   传递专家–监视电子邮件的传递能力的人员，还参与监视所有已发送电子邮件的技术和管理参数，并监视邮件处理的进度。 他负责确保已发送的电子邮件达到用户的最高比例，并且不会最终成为垃圾邮件。 为此，专家必须具有特定的知识和联系方式。 如果电子邮件的发送有任何问题，他就是必须了解可能原因并消除它的人。 消除技术障碍； 或更改电子邮件内容中的某些内容； 或尝试使用邮件提供商无法提供的支持服务来解决问题。 此类专家(如果有)还应参与制定清单，并测试生成应用程序和电子邮件的基础结构。 但是，测试过程本身应在质量检查服务的控制之下。

4. Email-marketer – determines the effectiveness of marketing newsletters. Under his control, the split-testing for the distribution of marketing to the audience occurs. Email-marketer also controls the segmentation of the user base, the composition, and frequency of the sent emails, the visual ‘presentation’ of the email to the user.

   电子邮件营销人员–确定营销通讯的有效性。 在他的控制下，进行了将营销分配给受众的拆分测试。 电子邮件营销人员还控制用户群的细分，已发送电子邮件的组成和频率，电子邮件向用户的可视化“呈现”。

All of these roles are not necessarily performed by a dedicated employee; the role of the marketer can be performed by one of the product managers, and the role of the delivery-specialist, for example, can be performed by a support employee or a network engineer. In start-up companies, it is highly likely that all of this will have to be dealt with by one person, and they may turn out to be a quality specialist.

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

邮寄和邮件运输 (Mailing and mail transport)

The email structure is like a massive iceberg, and there are two levels in it. There are more than a hundred different standards governing emails, but almost all of them belong to one of these two levels:

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

冰山的水下部分 (The underwater part of an iceberg)

– network service, the basic protocol of which is the SMTP application protocol defined by RFC 5321. It is responsible for the delivery of emails. A so-called SMTP envelope is formed for the delivery of the email, which includes the addresses of the sender and recipient of the SMTP level. Other network services, such as DNS, are also responsible for delivering the email. The main component of the network infrastructure is the Mail Transfer Agent (MTA). The MTA is responsible for handing the message delivery queue and the delivery process itself to the recipient servers. MTA examples include Postfix, Sendmail, Exim, Microsoft SMTP service.

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

This underwater part of the iceberg, which includes the MTA, DNS parameters, and other network parameters, we will call the email infrastructure or the message delivery infrastructure.

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

冰山一角 (The tip of the iceberg)

— the email itself. The basic structure of the email is defined by the standard RFC 5322. The email consists of service headers and one or more data parts. The data may be in a plain text format and/or HTML or even AMP, with inline images or attachments of almost any type.

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

电子邮件基础结构的界面和已测试应用程序的边界 (The interface of the email infrastructure and the boundaries of the tested application)

The email infrastructure, as a rule, has one or several interfaces through which an email is sent (when it enters the MTA delivery queue). For example, the SMTP Submission service, the function mail() in PHP, data transfer to an external mail or sendmail application, API for internal or external service (such as GetResponse, SendPulse, or Amazon SES). We will consider these interfaces as part of the infrastructure. It often happens that Application A prepares data for an email and a list of recipients, and then sends it to Application B through its API (for marketing mass mailings, this can be done manually via the user interface- UI), and application B generates a mail message in RFC 5322, and delivers it to the MTA. For application A (and when testing it), application B will be part of the email infrastructure. The API or UI of application B will be for the application A interface of the mail infrastructure. Although for Application B, the situation will be different, and the mail infrastructure for it will be lower-level network applications or protocols.

电子邮件基础结构通常具有一个或多个接口，通过该接口发送电子邮件(当电子邮件进入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，情况将有所不同，并且其邮件基础结构将是较低级的网络应用程序或协议。

测试参数的定义 (Definition of test parameters)

When testing each application, it is important to select all the mail infrastructures used by it (there may be several of them), and for each infrastructure to single out the interfaces used (there may also be several of them for each infrastructure). For each interface, the composition and format of the data transmitted to it is determined as accurately as possible, e.g. email text in TEXT/HTML, email text in TEXT/PLAIN, email subject, recipient name, recipient address, sender name, sender address (RFC5321.From), the address of the sender of the SMTP convector (RFC5322.mailfrom). Next, a set of requirements is developed for each parameter (representations, encodings, boundary values, etc.), methods for monitoring each of the parameters are determined (how to compare the actual result with the expected one).

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

发电应用的典型结构 (Typical structure of a generating application)

As a rule, the same product that we are testing is responsible for the generation of emails and data in it. This is usually a server (but sometimes client) application. It defines the structure of the email, part of the service headers, data encapsulation formats, string representations, and text encoding. A simple example of such an application is the script that forms the email and calls the mail() function. The main elements of the application that must be controlled are:

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

• the code responsible for generating headers and / or email structure, if the email structure is dynamically generated, and / or static email templates describing its structure;

  如果电子邮件结构是动态生成的，则负责生成标头和/或电子邮件结构的代码，和/或描述其结构的静态电子邮件模板；

• HTML layout of the email (ideally, it is a separate entity or part of the email template / layout, but can be embedded in the application code);

  电子邮件HTML布局(理想情况下，它是单独的实体或电子邮件模板/布局的一部分，但可以嵌入到应用程序代码中)；

• substitution of application data into an email (or into an email template);

  将应用程序数据替换为电子邮件(或电子邮件模板)；

• integration of the application with the email delivery infrastructure, the correctness of the parameters passed to the infrastructure interface.

  应用程序与电子邮件传递基础结构的集成，传递给基础结构接口的参数的正确性。

什么时候测试 (What and when to test)

Whether we like it or not, the entire iceberg should be tested. There are several main components that require testing:

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

交付基础设施 (Delivery infrastructure)

Emphasis in testing should be done on: email deliverability; correct DNS records, including PTR / FCrDNS, MX and A records; SMTP protocol parameters (HELO, use TLS); email authorization (SPF / DKIM / DMARC); SMTP envelope addresses (if the application does not manage them); correctness of processing the input parameters of the infrastructure interface; tracking, recording and processing of undelivered emails.

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

It is necessary to test the infrastructure during the initial implementation and every time changes are made to the infrastructure itself (the configuration of the MTA, DNS or network changes) or the interface for sending an email; using a new domain, network, or API; additional testing is required if the characteristics of the emails sent, such as their language, size or numbers are significantly changed. According to experience, the infrastructure tends to change «by itself», so basic tests should be conducted periodically, even if there is no information about any changes.

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

It is possible and necessary to involve the network engineer and the deliverability-specialist in drawing up the plan and checklists for testing the infrastructure.

可能并且有必要让网络工程师和可交付性专家来制定计划和清单，以测试基础结构。

生成应用 (Generating Application)

The addresses of the SMTP envelope should be monitored (if the application controls them, that is, they are transferred to the interface — envelope-from, envelope-to), the values ​​of the service headers of the email (Date, Message-ID, List-Unsubscribe, Auto-Submitted, etc.). Clause), email authorization (DKIM / DMARC), MIME-encoding (base64, quoted-printable), general correctness of the email format, for example, the absence of non-ASCII characters in the headers, the composition of the data being injected, the correct triggering of triggers, unsubscribing mechanisms, tracking mechanisms writing and collecting statistics (postmaster headers, for example, Feedback-ID or X-Mailru-Msgtype, as well as tracking pixels).

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

It is necessary to test an application during its development, when all its related components that are responsible for generating and storing data change, with significant changes in email templates, when changing the used infrastructure or interface to it, as well as within the framework of general regressions.

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

结构和排版电子邮件模板(可以是生成应用程序的一部分，也可以单独开发) (Structural and typesetting email templates (can be part of a generating application or are developed separately))

The structure of the email is checked (Content-Type, Content-Disposition, nesting of Multipart-parts of the email, text encoding, string parameters), the value of the target and displayed headers (From, To, Reply-to, Subject), the way email is displayed in the list of emails and when reading in various interfaces, microformats (for example, that a calendar event is recognized as a calendar event or an air ticket as an air ticket), branding.

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

Email templates should be tested every time you make at least the slightest changes, as well as separately, for example, in a situation where emails get into the application before the server part is ready.

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

It is recommended to involve an email marketing specialist and a deliverability specialist to compile a checklist for testing an email template.

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

检查基础结构的基本要求 (Basic requirements for checking infrastructure)

The IP address selected for the mail server should be as close as possible to the IP address of the mail server. It is recommended to check it using the whois utility. In particular, the sender's address should not belong to the network, which can be perceived as dynamic; the selected network must have active contacts to which complaints can be sent; the network must be used (have the status ASSIGNED in RIPE) The IP address must have a properly configured PTR record. It can be configured independently through the hosting control panel, or with the help of the service provider. A PTR record must point to the real hostname and still be meaningful, resolved back to the same IP address (so-called FCrDNS check), not remind the name of the dynamic host, and not include a large group of numbers or characters. A good example is mailserver.example.com.

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

Each domain used in envelope addresses or email headers must have a valid MX record pointing to a host A record, which, at a minimum, can handle undeliverable messages. MX is not allowed to directly refer to an IP address.

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

Control the passage of SPF, DKIM, DMARC. SPF allows the domain owner to specify in the TXT records a list of servers that are authorized to send emails with return addresses in this domain. It is configured for the address used in the envelope-from (SMTP-envelope) in the section of managing DNS zones of the domain. DKIM provides verification of the authorship of a message or of its originator to a specific domain using digital signature technologies, which is added to the email itself (in its DKIM-Signature header). Typically, a DKIM signature is configured at the MTA (infrastructure) level. DMARC sets the policy of checking incoming mail in a specific domain and actions on emails that do not pass SPF or DKIM authentication. When attempting to violate this policy, a structured report comes along with information about such an attempt. DMARC, as well as SPF, is published as a TXT record in the domain zone.

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

Check the deliverability of emails to the main postal services — for Russia Mail.Ru, Yandex, Gmail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. In the emails arrived, you need to check the correctness of HELO; the presence and passage of checks PTR / FCrDNS, SPF, DKIM, and DMARC; the validity of the headers and data in them, in particular, the synchronism of the clock in the dates and the correctness of the time zones.

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

(Registration mail has broken authentication due to freemail address used)

(由于使用了免费邮件地址，注册邮件的身份验证失败)

The formation of some parameters, for example, authorization, deliverability, and spam are integrally influenced by all components, but for their control, there are usually separate operational tools — DMARC and FBL reports, postmaster services API, email tracking tools, delivery statistics. Testing should take into account the level of implementation of operational monitoring tools in the company — for example, in the absence of operational control of DMARC reports, the authorization of emails should be regularly tested, whereas in the absence of operational control of deliverability, where and how the emails go, even if there is no development related to sending emails.

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

To test the infrastructure, you can use specialized services, for example, mail-tester.com, mxtoolbox.com. Detailed infrastructure requirements can be found in this article.

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

(an example of the broken SPF record)

(SPF记录损坏的示例)

认证要求 (Authentication requirements)

Checking the passage of SPF, DKIM, DMARC is usually possible using the Authentication-Results header on the recipient's server.

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

Check the validity of the SPF record for syntax, the limit for DNS queries (for example, using mxtoolbox.com). When forming an SPF, all sources of mailings should be taken into account (do not forget CRM systems, all currently utilized delivery infrastructures, including those through which one-time marketing campaigns are conducted). It is recommended to set allowed servers for the domain through the list of networks (‘ip4’ / ‘ip6’). SPF is checked for the sender address from the SMTP envelope. Verify that the SMTP envelope domain (envelope-from) matches the domain from the From header. Common SPF errors are listed in this article (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).

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

Check the DKIM DNS record, the validity and composition of the DKIM Signature. Verify that you are using a DKIM key of at least 1024 bits. Recommended hash mode of DKIM signature: relaxed / relaxed. Make sure that all important headers are signed (From, To, Subject, Date, Message-ID, MIME-Version, Content-Type), that tracking headers (Received, Delivered-To, Return-Path) are not signed, and DKIM is validated for basic mail services. Set up forwarding to one of the mail services to another; DKIM should not «beat» on forwarded emails. Verify that the DKIM signature domain matches the sender domain from the ‘From’ header.

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

Check DMARC for basic email services. Check for DMARC reports, identify and troubleshoot SPF and DKIM for all IP addresses of your infrastructure.

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

Verify that messages are delivered to external servers using encryption (TLS). You can sometimes check for TLS by the Received header on the recipient’s server: for example, specifying the ESMTPS protocol or having parameters of the form (version = TLS1_2 cipher = ECDHE-RSA-AES128-GCM-SHA256 bits = 128/128); indicates the presence of TLS.

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

验证生成的应用程序 (Verification of the generating application)

电子邮件地址要求 (Email address requirements)

信封地址 (Envelope addresses)

We begin the verification of the generating application with the addresses in the SMTP envelope.

我们使用SMTP信封中的地址开始验证生成的应用程序。

Envelope addresses are addresses of the email infrastructure level. They are not visible to the user, but they are important for delivery because the address of the envelope determines which mailbox the email goes into.

信封地址是电子邮件基础结构级别的地址。 它们对用户不可见，但是对于传递很重要，因为信封的地址决定了电子邮件进入哪个邮箱。

The recipient address in the envelope ( 信封中的收件人地址 ( envelope-to, aka envelope-to ，也称为 RCPT TO:) is the address to which the email will actually be delivered. RCPT TO:是电子邮件实际发送到的地址。

• for all emails except for registration, the address must be legally signed and validated for mailing in accordance with administrative requirements.

  对于除注册以外的所有电子邮件，必须根据管理要求对地址进行合法签名和验证以进行邮寄。

• for newsletters, the address must be «live», addresses to which email cannot be delivered regularly should be marked as inactive, mailings to them should not be made. But some categories of emails (for example, access recovery) may also need to be sent to addresses previously marked as inactive.

  对于新闻通讯，该地址必须为“实时”，不能将电子邮件定期发送至的地址应标记为无效，不应该向其发送邮件。 但是，某些类别的电子邮件(例如，访问恢复)也可能需要发送到以前标记为无效的地址。

Sender address in an SMTP envelope (usually called SMTP信封中的发件人地址 (通常称为 envelope-from, envelope-from ， smtp.mailfrom, smtp.mailfrom ， MAIL FROM: or MAIL FROM:或 Return-Path) — messages will be delivered to this address about the inability to deliver an email and automatic replies. This address is not visible to the user. This address is also used for SPF authorization. We verify that: Return-Path )-有关无法发送电子邮件和自动回复的消息将被发送到该地址。 用户看不到该地址。 此地址也用于SPF授权。 我们验证：

• The address is available;

  地址可用；

• It is not the address of the employee and is not redirected to him in order to exclude auto answers, messages about inaccessibility, etc.;

  它不是员工的地址，也不会重定向到他的位置，以排除自动答复，有关无法进入的消息等；

• It is processed by a script that will mark addresses of inaccessible users as inactive;

  它由脚本处理，该脚本会将无法访问的用户的地址标记为不活动；

• The address can be automatically generated, i.e. unique to each email;

  该地址可以自动生成，即每个电子邮件都唯一；

• An email to this address should not lead to the generation of any response email, for example, a message about a mailbox overflow.

  发送到该地址的电子邮件不应导致生成任何响应电子邮件，例如，有关邮箱溢出的消息。

电子邮件标题地址 (Email header addresses )

These addresses are either directly visible to the user or are used when replying to an email.

这些地址对用户直接可见，或在回复电子邮件时使用。

Sender address (the header From:) is the address and sender name displayed in the list of emails and when reading an email. We verify that:

发件人地址(标头From: ：)是电子邮件列表中和阅读电子邮件时显示的地址和发件人名称。 我们验证：

• This is a human-readable friendly address that identifies the company.

  这是一个易于识别的友好地址，用于标识公司。

• It contains not only an email address but also the name of the sender.

  它不仅包含电子邮件地址，还包含发件人的姓名。

• Noreply@ is possible, but only if we want to emphasize that we do not expect to receive a response to the email and it will not be read. It is better to duplicate this idea in the text of the email.

  Noreply @是可能的，但是只有在我们要强调我们不希望收到对电子邮件的答复并且不会被阅读时，才可以。 最好在电子邮件的文本中重复这个想法。

• In the presence of non-ASCII characters (for example, Cyrillic), the sender name must be encoded in accordance with MIME, the domain in the presence of non-ASCII characters must be encoded in Punycode

  在存在非ASCII字符(例如，西里尔字母)的情况下，发件人名称必须按照MIME进行编码，在存在非ASCII字符的域中必须使用Punycode进行编码

• Emails of the same category should have the same address; the use of auto-generated addresses should be avoided. This is due to the fact that ‘From:’ is most often used by people to sort emails by folders using filters.

  相同类别的电子邮件应具有相同的地址； 应避免使用自动生成的地址。 这是因为人们最常使用“发件人：”来使用过滤器按文件夹对电子邮件进行排序。

• The address should be different (preferably in different subdomains) for transactional, marketing and urgent emails (such as emails from the support service). This is also due to the fact that the user can mark marketing emails as spam or filter them in an unreadable folder.

  对于交易，市场营销和紧急电子邮件(例如来自支持服务的电子邮件)，地址应该不同(最好在不同的子域中)。 这也是由于用户可以将营销电子邮件标记为垃圾邮件或将其过滤在不可读的文件夹中。

• The address From: and SMTP envelope address must be in the same domain or in subdomains of the same organizational domain in order to pass the SPF within the DMARC.

  地址From:和SMTP信封地址必须位于同一域或同一组织域的子域中，以便在DMARC中传递SPF。

• The address must be from the organization’s domain. It is unacceptable to use free mail services and other public mail domains in From:, since such mailings will not pass SPF and DKIM authentication within the framework of DMARC.

  地址必须来自组织的域。 在From:使用免费邮件服务和其他公共邮件域是不可接受的，因为此类邮件在DMARC框架内不会通过SPF和DKIM身份验证。

The address Reply-to – ‘manual’ replies will be sent to this address when a user answers an email. It is optional. If it is absent, the address from ‘From:’ is used for the response. Check that ‘Reply-to’:

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

• It can be auto-generated, i.e. unique to the email (allows you to find out which email the answer came to).

  它可以自动生成，即对于电子邮件是唯一的(允许您找出答案来自哪封电子邮件)。

• It should not fall into the employee’s mailbox to avoid auto-answer, but ideally should be «wrapped» in CRM.

  它不应掉入员工的邮箱中以避免自动应答，而理想情况下应“包装”在CRM中。

• It can generate a standard CRM auto-answer, but it should not generate anything superfluous, for example, mailbox overflow or «on vocation» messages. When generating auto-responses, measures must be taken to avoid looping, they are listed in RFC 3834.

  它可以生成标准的CRM自动应答，但不应生成多余的内容，例如邮箱溢出或“在职”消息。 生成自动响应时，必须采取避免循环的措施，这些措施在RFC 3834中列出。

• It can be from any domain that does not necessarily coincide with ‘From:’, but sometimes this scares users when answering.

  它可以来自不一定与“发件人：”一致的任何域，但是有时这会在回答时使用户感到恐惧。

• May be absent, then the From: address performs its functions.

  可能不存在，然后“ From:地址将执行其功能。

• In addition to the address, the name of the sender is indicated.

  除地址外，还显示发件人的姓名。

The address To:

地址To:

• Must contain the recipient's email (otherwise it scares the recipient of the message and bothers the anti-spam).

  必须包含收件人的电子邮件(否则，它会使邮件的收件人害怕并打扰反垃圾邮件)。

• Ideally, it should contain the name of the recipient. But if the name is unknown or doubtful (for example, the address has not yet been confirmed), it is better not to indicate it (someone may enter someone else's address with a bad name, and the recipient may be offended).

  理想情况下，它应该包含收件人的姓名。 但是，如果姓名不明或可疑(例如，尚未确认地址)，则最好不要注明(有人输入名字不正确的人的地址，收件人可能会受到冒犯)。

电子邮件标题要求 (Email header requirements)

The actual encoding of the text should match the one indicated in the header. It is advisable to use one encoding in all headers and parts of the email. It is recommended that you use UTF-8 as a widely supported one. The encoding is indicated in the Content-Type headers and in the tag of the HTML part.

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

The From:, Message-ID: and Date: headers should be formed directly in the script for sending the email (and by standards — along with the text of the email) and always in the correct format. If they are absent or incorrectly formed, one of the transit servers can add these headers, which leads to a violation of the integrity of the DKIM signature.

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

8-bit characters in the headers, including the subject line (Subject) and the names of the attached files (Content-Type and Content-Disposition), should be absent; All non-ASCII characters, including Cyrillic, must be encoded in quoted-printable or base64.

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

(registration confirmation in weird encoding)

(使用奇怪编码的注册确认)

电子邮件结构要求 (Requirements to the structure of the email)

For the HTML part of the email, it is desirable to form an alternative — text (plain) part. It is also necessary to check the conformity and readability of the plain text part of the email (if any) and the general structure of the email.

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

According to RFC 5322, the length of a line in an email should not exceed 998 8-bit characters. Please note that in UTF-8, a character can occupy several octets. The terminator of lines in an email is a pair of CRLF ( ascii 13, ascii 10), which takes 2 octets. You need to check the correctness of the string terminator, since emails are often sent using a Unix script, and in Unix, the string terminator is a single character — this is an error for email. You should also check if the string terminators break UTF-8 encoded characters: you cannot allow the presence of a string terminator between two octets of the same character, for example, Cyrillic symbol. To avoid such situations, it is necessary to break the text before forming the email or encode the text in base64, base64 usually has fixed line length.

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

It is necessary to check the correct marking of attachments and inlines — that is, the correctness of the formation of the headers «Content-Disposition: inline», if it is a picture displayed inside the email, or «Content-Disposition: attachment» if file attached is intended for download.

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

The structure of the email should be as simple as possible: in particular, there should not be more than one multipart part of each type (mixed, alternative, related), and multipart/mixed is used only if the email contains file attachments, multipart/related — if HTML comes with inline images, multipart/alternative — in the presence of plain text and HTML parts. In general, the structure of the email, in the absence of attachments and inline pictures, should look like this:

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

multipart/alternative

多部分/替代

— text/plain

—文字/纯文字

— text/html

—文字/ html

The order of the parts is important, text/plain must go BEFORE text/html or multipart/related. This is necessary so that the HTML part is displayed by default, and only if its display is unavailable for some reason, the plain part is displayed.

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

If there are inline pictures in the email, its structure should look like this:

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

multipart/alternative

多部分/替代

— text/plain

—文字/纯文字

— multipart/related

—多部分/相关

—— text/html

-text / html

—— image/… (inline-picture)

-图片/…(在线图片)

—— image/… (inline-picture)

-图片/…(在线图片)

Inline images must have Content-Disposition: inline and be strictly inside the multipart/related part.

内联图像必须具有Content-Disposition：内联并且严格位于多部分/相关部分内。

In the most difficult case, when there are both inline images and attached files, the email has the following structure:

在最困难的情况下，当同时存在嵌入式图像和附件时，电子邮件具有以下结构：

multipart/mixed

多份/混合

— multipart/alternative

—多部分/替代

—— text/plain

-文字/纯文字

—— multipart/related

-多重/相关

——— text/html

——— text / html

——— image/png

——— image / png

——— image/png

——— image / png

…

…

— application/octet-string (content-disposition: attachment)

— application / octet-string(内容处置：附件)

— application/octet-string (content-disposition: attachment)

— application / octet-string(内容处置：附件)

…

…

multipart related- and multipart/alternative-parts must be closed before attachments, attachments belong to the external multipart/mixed part)

必须先关闭多部分相关部分和多部分/替代部分，附件才属于外部多部分/混合部分)

(registration message with incorrect parts structure)

(零件结构不正确的注册信息)

URI要求 (URI requirements)

Any URIs (in src, href attributes, styles, etc.) must contain the protocol and hostname (https://example.com/somepath). Typical errors are the use of relative links (/somepath) and the lack of a protocol (//example.com/somepath), which is unacceptable for emails, because in them, the default protocol may be file://.

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

• Any service and non-ASCII characters (in particular, Cyrillic) in the URI must be encoded using percent encoding.

  URI中的任何服务和非ASCII字符(特别是西里尔字母)都必须使用百分比编码。

• A link inserted as text (that is, visible to the user as a URL, and not as a piece of text) should still be marked up with the <а> tag, otherwise, the user will not be able to click on it. Some webmails mark up such links on their own, but this is not standard behavior. In this case, the href address inside A must match the link text, otherwise, the content filter may react to such a link as an attempt to deceive the user. This is especially worth paying attention to when there are «clickers» that track the user's transitions from the email.

  仍应使用<а>标记标记为文本插入的链接(即，该链接对于用户来说是URL，而不是文本可见)，否则，用户将无法单击它。 有些网络邮件会自己标记此类链接，但这不是标准行为。 在这种情况下，A中的href地址必须与链接文本匹配，否则，内容过滤器可能会对此类链接做出React，以欺骗用户。 当存在“点击器”来跟踪用户从电子邮件的转换时，这一点尤其值得关注。

• It is better to limit oneself to the use of the protocols http://, https:// and mailto:.

  最好限制自己使用协议http:// ， https://和mailto:

• With high-security requirements, you should completely abandon the use of http:// in favor of https://.

  出于安全性高的要求，您应该完全放弃使用http:// ，而应该使用https:// 。

• Non-standard ports should not be used (for example, example.com:8080/somepath), as they may not be accessible to the user.

  不应该使用非标准端口(例如example.com：8080 / somepath)，因为用户可能无法访问它们。

• Clicking on the link inside the HTML part should not lead to any changes in the state of the application (subscription, unsubscribe, cancellation of the order, etc.) without additional confirmation by the user on the page, because some content filtering systems can independently verify the security of such a transition by requesting a page by reference; the mail application can show the preview of the page by the link on hover, and modern browsers can load the page before the user clicks the link to reduce load time (in the web application it is generally not recommended to do any modifying actions on the GET request, all modifying requests must go through POST or PUT).

  单击HTML部分内的链接不应导致应用程序状态发生任何变化(订阅，取消订阅，取消订单等)，而无需用户在页面上进行额外确认，因为某些内容过滤系统可以独立进行通过引用请求页面来验证这种过渡的安全性； 邮件应用程序可以通过悬停上的链接来显示页面的预览，现代浏览器可以在用户单击链接之前加载页面以减少加载时间(在Web应用程序中，通常不建议对页面进行任何修改操作) GET请求，所有修改请求必须通过POST或PUT进行。

• Clicking on the link in the List-Unsubscribe header, on the contrary, should not require any additional actions from the user, because the unsubscribe by this link is usually done by email program or webmail on behalf of the user. Also, there is a new header List-Unsubscribe-Post introduced by RFC 8058.

  相反，单击List-Unsubscribe标头中的链接不需要用户采取任何其他操作，因为此链接的退订通常是由电子邮件程序或Webmail代表用户完成的。 此外，RFC 8058还引入了新的标头List-Unsubscribe-Post。

• You should not expect the user to read the email and follow the link in the same browser in which it initiates the action leading to the sending of the email (for example, registers an account). The link should work in any other browser or mobile device. In particular, the user can open the link without being authorized, or authorized in an account other than the one to which the email was sent.

  您不应期望用户阅读电子邮件并在启动浏览器导致发送电子邮件的操作的同一浏览器中访问链接(例如，注册帐户)。 该链接应可在任何其他浏览器或移动设备上使用。 尤其是，用户可以在未经授权的情况下打开链接，也可以在未向其发送电子邮件的帐户中获得授权。

• Because the length of the URI can be limited; you should not use URIs of the ‘data:’ type for large objects. For the same reason, don't use URIs that are too long in hyperlinks.

  因为可以限制URI的长度； 您不应将“ data：”类型的URI用于大型对象。 出于同样的原因，请不要在超链接中使用太长的URI。

• You must not use external link shorteners, this negatively affects the delivery of emails. It is better if all links point to your domain, this will reduce the potential negative impact of someone else's reputation on the delivery of emails.

  You must not use external link shorteners, this negatively affects the delivery of emails. It is better if all links point to your domain, this will reduce the potential negative impact of someone else's reputation on the delivery of emails.

• Do not place external images on some public services or free hosting, use a reliable hosting service or CDN with good performance and reputation.

  Do not place external images on some public services or free hosting, use a reliable hosting service or CDN with good performance and reputation.

(invalid image and anchor URI due to missing protocol specification)

(invalid image and anchor URI due to missing protocol specification)

Email layout requirements (Email layout requirements)

Why is it so difficult to make up emails?

Why is it so difficult to make up emails?

Email clients in one way or another display user content within their interface. Potentially, this can lead to various security problems — cross-site scripting (XSS, Crossite scripting), interface spoofing, DOM clobbering, user deanonymization / information leakage (for example, the user's IP address or cookies through external requests), etc. ., therefore, any mail service and mail application has some form of protection against each class of attacks. Unfortunately, there is no single approach to organizing this protection. It can be organized through:

Email clients in one way or another display user content within their interface. Potentially, this can lead to various security problems — cross-site scripting (XSS, Crossite scripting), interface spoofing, DOM clobbering, user deanonymization / information leakage (for example, the user's IP address or cookies through external requests), etc. ., therefore, any mail service and mail application has some form of protection against each class of attacks. Unfortunately, there is no single approach to organizing this protection. It can be organized through:

• isolated limited frames,

  isolated limited frames,

• filtering tags and / or attributes,

  filtering tags and / or attributes,

• restrictions on absolute positioning,

  restrictions on absolute positioning,

• prohibition or restriction on the use of block styles (which is critical for adaptive layout),

  prohibition or restriction on the use of block styles (which is critical for adaptive layout),

• banning external elements by default (i.e. downloading external images requires user permission) or using a proxy to access them,

  banning external elements by default (ie downloading external images requires user permission) or using a proxy to access them,

• converting HTML emails to another intermediate format (for example, Microsoft Exchange / Outlook uses RTF, which can make it extremely difficult to display elements properly in Outlook using conventional methods),

  converting HTML emails to another intermediate format (for example, Microsoft Exchange / Outlook uses RTF, which can make it extremely difficult to display elements properly in Outlook using conventional methods),

• prohibition or restriction on the use of forms or their individual elements.

  prohibition or restriction on the use of forms or their individual elements.

The emails also use specific elements, such as inline images and URI cid://, whose support may be limited. For example, Mozilla Thunderbird does not support cid:// for background images.

The emails also use specific elements, such as inline images and URI cid:// , whose support may be limited. For example, Mozilla Thunderbird does not support cid:// for background images.

Even a correctly formed email can be displayed differently in different interfaces due to the peculiarities of their implementation and filtering of the contents of the email.

Even a correctly formed email can be displayed differently in different interfaces due to the peculiarities of their implementation and filtering of the contents of the email.

If there are errors in the email format, the behavior becomes completely unpredictable. For example, email clients may have different behavior with incorrect URIs, or that incorrect header formatting is handled differently. Also, text encoding auto-detection works differently if it is not specified or is specified incorrectly. Therefore, the email must be viewed in different interfaces: the correct display of the email in one interface does not mean that it is composed correctly (in fact, even the correct display of the email in all interfaces does not guarantee that there will be no problems with the display in the future).

If there are errors in the email format, the behavior becomes completely unpredictable. For example, email clients may have different behavior with incorrect URIs, or that incorrect header formatting is handled differently. Also, text encoding auto-detection works differently if it is not specified or is specified incorrectly. Therefore, the email must be viewed in different interfaces: the correct display of the email in one interface does not mean that it is composed correctly (in fact, even the correct display of the email in all interfaces does not guarantee that there will be no problems with the display in the future).

It is necessary to pay attention to the following points:

It is necessary to pay attention to the following points:

• Check the text of the email for semantic content, display, absence of typos, syntactic, spelling and lexical errors.

  Check the text of the email for semantic content, display, absence of typos, syntactic, spelling and lexical errors.

• Check the correctness of the substitution of application data in the template or layout of the email.

  Check the correctness of the substitution of application data in the template or layout of the email.

• Check the correctness of the amounts, dates, numbers, items of goods and other information, taking into account the permissible boundary conditions. The dates should have a year (some users enter the box very rarely). A time zone must be present in time. The address must contain a city, and in some cases, it is necessary to indicate the country.

  Check the correctness of the amounts, dates, numbers, items of goods and other information, taking into account the permissible boundary conditions. The dates should have a year (some users enter the box very rarely). A time zone must be present in time. The address must contain a city, and in some cases, it is necessary to indicate the country.

• Check the operational status of all links in the email, if any.

  Check the operational status of all links in the email, if any.

• In emails sent before confirmation of the address, incl. emails with a confirmation link, there should not be any text controlled from the outside, even the username, otherwise, they can be used for spam (in the field displayed in the email, for example, in the name, spam text is inserted and the address is the indicated address of the victim). For example, if you can send an obscene text on the developer's address on behalf of your service, then there is a problem.

  In emails sent before confirmation of the address, incl. emails with a confirmation link, there should not be any text controlled from the outside, even the username, otherwise, they can be used for spam (in the field displayed in the email, for example, in the name, spam text is inserted and the address is the indicated address of the victim). For example, if you can send an obscene text on the developer's address on behalf of your service, then there is a problem.

• Check for the absence of external images on third-party services. It can affect delivery and leak information about your customers.

  Check for the absence of external images on third-party services. It can affect delivery and leak information about your customers.

• Check the availability of counters for sending, delivery, reading email, transitions. Some of them are located in the email itself (for example, the counter-pixel of reading the email), some are tracked by the mailer, but, as a rule, all are available in the mailer’s admin panel.

  Check the availability of counters for sending, delivery, reading email, transitions. Some of them are located in the email itself (for example, the counter-pixel of reading the email), some are tracked by the mailer, but, as a rule, all are available in the mailer's admin panel.

• Check the correctness of the subscription category and the user's unsubscription for this category through the link in the email.

  Check the correctness of the subscription category and the user's unsubscription for this category through the link in the email.

• Check how the email looks to:

  Check how the email looks to:

  • Popular web versions of mail for a targeted country: the «big three» for Russia are Mail.Ru, Yandex, Gmail. You can also add Rambler and Outlook.com;

    Popular web versions of mail for a targeted country: the «big three» for Russia are Mail.Ru, Yandex, Gmail. You can also add Rambler and Outlook.com;

  • Mobile applications of the above email providers;

    Mobile applications of the above email providers;

  • Standard mobile applications using IMAP, taking into account popular mobile platforms, for at least the iPhone, Pixel (Android reference platform), Samsung (the most common for Android), MIUI (takes the second place in Russia for Android platforms);

    Standard mobile applications using IMAP, taking into account popular mobile platforms, for at least the iPhone, Pixel (Android reference platform), Samsung (the most common for Android), MIUI (takes the second place in Russia for Android platforms);

  • Various desktop browsers: Chrome, Firefox, Edge, Internet Explorer, Opera, etc .;

    Various desktop browsers: Chrome, Firefox, Edge, Internet Explorer, Opera, etc .;

  • Desktop applications (email programs), especially Thunderbird, Outlook and Apple Mail, optionally The Bat! and Opera Mail;

    Desktop applications (email programs), especially Thunderbird, Outlook and Apple Mail, optionally The Bat! and Opera Mail;

  • Popular corporate solutions with a web interface (Exchange, maybe Roundcube, Communigate, Zimbra, SquirrelMail) — for B2B solutions;

    Popular corporate solutions with a web interface (Exchange, maybe Roundcube, Communigate, Zimbra, SquirrelMail) — for B2B solutions;

  • Do not forget to check the layout on both Retina monitors and monitors with lower resolution.

    Do not forget to check the layout on both Retina monitors and monitors with lower resolution.

• During the check in each case, you need to pay attention to:

  During the check in each case, you need to pay attention to:

  • Passing the authorization headers, SPF / DKIM / DMARC.

    Passing the authorization headers, SPF / DKIM / DMARC.

  • Email download speed: it should load quickly, and not take its time.

    Email download speed: it should load quickly, and not take its time.

  • Displaying an email in the list of emails: avatar, sender’s name and the subject that falls into the message’s snippet, whether its category was correctly defined (for example, if the order did not fall into the «social networks» category).

    Displaying an email in the list of emails: avatar, sender's name and the subject that falls into the message's snippet, whether its category was correctly defined (for example, if the order did not fall into the «social networks» category).

  • The layout of the email as a whole: if the layout remained consistent, were there any incorrect word breaks, etc., including when scaling and resizing the window.

    The layout of the email as a whole: if the layout remained consistent, were there any incorrect word breaks, etc., including when scaling and resizing the window.

  • Fonts should not be small or hard to read.

    Fonts should not be small or hard to read.

  • Background images and background colors.

    Background images and background colors.

  • Matching the brand book.

    Matching the brand book.

  • Ease of performing the actions implied by the email. For example, if the email contains a confirmation code or other information that may need to be stored somewhere, then it should not only be well-read, it should also be convenient to select and copy it even in the mobile interface.

    Ease of performing the actions implied by the email. For example, if the email contains a confirmation code or other information that may need to be stored somewhere, then it should not only be well-read, it should also be convenient to select and copy it even in the mobile interface.

• Keep track of the overall size of the email (including external images) and that it does not exceed reasonable values. The heavier the load time, the more likely that a person will have a negative reaction to it.

  Keep track of the overall size of the email (including external images) and that it does not exceed reasonable values. The heavier the load time, the more likely that a person will have a negative reaction to it.

• Even emails that have not been amended should be checked periodically, as changes can occur on the side of the postal service, and, for example, «reveal» a previously invisible problem.

  Even emails that have not been amended should be checked periodically, as changes can occur on the side of the postal service, and, for example, «reveal» a previously invisible problem.

• Some parameters must be controlled in all tests. For example, problems with passing DKIM authentication can be due to problems in the infrastructure (problems with DNS or the formation of a DKIM signature, time synchronization errors), due to errors in the generating program (sender address is incorrectly formed, incorrect characters in the headers are missing or mandatory From, Date, or Message-ID headers have been duplicated) and due to content errors (incorrect line terminators, lines are too long, incorrect addresses). At the same time, the email may not «beat», and the problem may not appear on any service.

  Some parameters must be controlled in all tests. For example, problems with passing DKIM authentication can be due to problems in the infrastructure (problems with DNS or the formation of a DKIM signature, time synchronization errors), due to errors in the generating program (sender address is incorrectly formed, incorrect characters in the headers are missing or mandatory From, Date, or Message-ID headers have been duplicated) and due to content errors (incorrect line terminators, lines are too long, incorrect addresses). At the same time, the email may not «beat», and the problem may not appear on any service.

Conducting Split-Tests (Conducting Split-Tests)

Marketing research is beyond the scope of this article, but a few key points that significantly affect the quality of emails should be mentioned.

Marketing research is beyond the scope of this article, but a few key points that significantly affect the quality of emails should be mentioned.

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.

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.

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.

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.

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).

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 ).

翻译自: https://habr.com/en/company/mailru/blog/464515/