HELO、MAILFROM 和 From 是否应该使用相同的域？

Question

HELO 主机名可以与发送者不同

主机HELO名应该有一个匹配的A& PTR，但它们不必与使用的域匹配RFC 5321 MAIL FROM也不RFC 5322 发起者字段 From标题 – 甚至不共享组织域。

例如，mail1.example.com&mail2.example.com可以为example.com、example.net&发送邮件example.org。否则，每个域都需要一个具有匹配PTR记录的自己的 IP 地址。想想大型电子邮件服务提供商正在处理的域名数量，他们肯定为所有域名使用通用基础设施。

MX 记录用于接收邮件

这些MX记录与发送邮件无关，而是与接收邮件有关。就您的问题而言，它们之间没有任何关系。入站邮件可能由完全不同的一组服务器处理。例如，来自某个域的新闻稿可以使用 SendGrid 或 MailChimp 发送，而传入邮件则由 M365 或 Gmail 处理。

HELO/DNS 不匹配的原因

使用HELO//A不PTR匹配作为垃圾邮件的指示很常见，例如 MXToolBox 所描述的：

SMTP 横幅检查：

一些接收邮件服务器可能会使用不匹配或被屏蔽的横幅作为评分系统中可能的垃圾邮件来源的指示，但大多数不会仅基于此而拒绝收到的邮件。
SMTP 反向 DNS 不匹配：

一些接收邮件服务器可能会将此作为评分系统中可能的垃圾邮件来源的指示。大多数不会仅以此为由拒绝收到的邮件。我们建议您联系您的 ISP，并要求他们设置与您的邮件服务器主机名匹配的反向记录 (PTR)。

这种做法可能来自于RFC 5321, 2.3.5：

命令中给出的域名EHLO必须是主主机名（解析为地址 RR 的域名），或者，如果主机没有名称，则为地址文字，如中所述第 4.1.3 节EHLO并在讨论中进一步讨论第 4.1.4 节。

然而，这并不是一个硬性要求，因为4.1.4进一步定义：

如果可能，SMTP 客户端必须确保EHLO命令的域参数是主主机名，如第 2.3.5 节如果这不可能（例如，当客户端的地址是动态分配的并且客户端没有明显的名称时），则应该用地址文字代替域名。

SMTP 服务器可以验证命令中的域名参数是否EHLO 确实与客户端的 IP 地址相对应。但是，如果验证失败，服务器不得以此为由拒绝接受消息。

这里，SMTP 协议似乎遵循稳健性原则即“做事要保守，接受别人的事情要宽容”。

防晒指数

必须发件人策略框架（SPF）实施以保护MAIL FROM身份（RFC 7208, 2.4）并且可以选择保护HELO身份（RFC 7208, 2.3），也：

建议 SPF 验证者不仅检查MAIL FROM 身份，还HELO通过应用check_host()函数单独检查身份（第 4 部分)HELO的身份 <sender>。检查HELO可以提高结果的一致性，并可以减少 DNS 资源的使用。如果可以根据对的检查对消息做出结论性判断，则可以避免HELO使用 DNS 资源来处理通常更复杂的内容。MAIL FROM

由于这是独立完成的，因此 SPF 也不要求它们匹配。

SPF 可防止主机名被用作信封发件人未经许可，子域也不会继承该记录。因此，您应该A使用相应的 SPF 记录保护您拥有的每条记录TXT- 而不仅仅是您用于发送电子邮件的记录。

DMARC

这基于域的消息认证、报告和一致性（DMARC 要求匹配RFC5322.来自以及标识符对齐方式，定义在RFC 7439, 3.1。这些标识符可以是 DKIM 认证的(3.1.1）或 SPF 认证（3.1.2），并且根据模式的不同，可能需要精确匹配或共享组织域（3.2)。与 SPF 不同，DMARC 是继承的；域顶点的 DMARC 策略From还可以保护所有子域不被用在标头中。

SPF 对齐需要匹配MAIL FROM，但 DKIM 对齐不需要；只需具有匹配的有效且授权的 DKIM 签名即可签名域标识符（SDID）（d=字段）。总之，这两者都不需要匹配HELO/EHLO主机名。

Answer 1

HELO 主机名可以与发送者不同

主机HELO名应该有一个匹配的A& PTR，但它们不必与使用的域匹配RFC 5321 MAIL FROM也不RFC 5322 发起者字段 From标题 – 甚至不共享组织域。

例如，mail1.example.com&mail2.example.com可以为example.com、example.net&发送邮件example.org。否则，每个域都需要一个具有匹配PTR记录的自己的 IP 地址。想想大型电子邮件服务提供商正在处理的域名数量，他们肯定为所有域名使用通用基础设施。

MX 记录用于接收邮件

这些MX记录与发送邮件无关，而是与接收邮件有关。就您的问题而言，它们之间没有任何关系。入站邮件可能由完全不同的一组服务器处理。例如，来自某个域的新闻稿可以使用 SendGrid 或 MailChimp 发送，而传入邮件则由 M365 或 Gmail 处理。

HELO/DNS 不匹配的原因

使用HELO//A不PTR匹配作为垃圾邮件的指示很常见，例如 MXToolBox 所描述的：

SMTP 横幅检查：

一些接收邮件服务器可能会使用不匹配或被屏蔽的横幅作为评分系统中可能的垃圾邮件来源的指示，但大多数不会仅基于此而拒绝收到的邮件。
SMTP 反向 DNS 不匹配：

一些接收邮件服务器可能会将此作为评分系统中可能的垃圾邮件来源的指示。大多数不会仅以此为由拒绝收到的邮件。我们建议您联系您的 ISP，并要求他们设置与您的邮件服务器主机名匹配的反向记录 (PTR)。

这种做法可能来自于RFC 5321, 2.3.5：

命令中给出的域名EHLO必须是主主机名（解析为地址 RR 的域名），或者，如果主机没有名称，则为地址文字，如中所述第 4.1.3 节EHLO并在讨论中进一步讨论第 4.1.4 节。

然而，这并不是一个硬性要求，因为4.1.4进一步定义：

如果可能，SMTP 客户端必须确保EHLO命令的域参数是主主机名，如第 2.3.5 节如果这不可能（例如，当客户端的地址是动态分配的并且客户端没有明显的名称时），则应该用地址文字代替域名。

SMTP 服务器可以验证命令中的域名参数是否EHLO 确实与客户端的 IP 地址相对应。但是，如果验证失败，服务器不得以此为由拒绝接受消息。

这里，SMTP 协议似乎遵循稳健性原则即“做事要保守，接受别人的事情要宽容”。

防晒指数

必须发件人策略框架（SPF）实施以保护MAIL FROM身份（RFC 7208, 2.4）并且可以选择保护HELO身份（RFC 7208, 2.3），也：

建议 SPF 验证者不仅检查MAIL FROM 身份，还HELO通过应用check_host()函数单独检查身份（第 4 部分)HELO的身份 <sender>。检查HELO可以提高结果的一致性，并可以减少 DNS 资源的使用。如果可以根据对的检查对消息做出结论性判断，则可以避免HELO使用 DNS 资源来处理通常更复杂的内容。MAIL FROM

由于这是独立完成的，因此 SPF 也不要求它们匹配。

SPF 可防止主机名被用作信封发件人未经许可，子域也不会继承该记录。因此，您应该A使用相应的 SPF 记录保护您拥有的每条记录TXT- 而不仅仅是您用于发送电子邮件的记录。

DMARC

这基于域的消息认证、报告和一致性（DMARC 要求匹配RFC5322.来自以及标识符对齐方式，定义在RFC 7439, 3.1。这些标识符可以是 DKIM 认证的(3.1.1）或 SPF 认证（3.1.2），并且根据模式的不同，可能需要精确匹配或共享组织域（3.2)。与 SPF 不同，DMARC 是继承的；域顶点的 DMARC 策略From还可以保护所有子域不被用在标头中。

SPF 对齐需要匹配MAIL FROM，但 DKIM 对齐不需要；只需具有匹配的有效且授权的 DKIM 签名即可签名域标识符（SDID）（d=字段）。总之，这两者都不需要匹配HELO/EHLO主机名。

HELO、MAILFROM 和 From 是否应该使用相同的域？

答案1

HELO 主机名可以与发送者不同

MX 记录用于接收邮件

HELO/DNS 不匹配的原因

防晒指数

DMARC

相关内容