320

线段是这样的

{64} @ {255}

64 + 1 + 255 = 320

如果你正在验证电子邮件，你也应该阅读这篇文章:我知道如何验证一个电子邮件地址，直到我阅读RFC

邮件地址长度不超过254个字符。

IETF在提交勘误表后接受了这一点。任何给定地址的完整诊断都可以在网上找到。RFC 3696的原始版本将320描述为最大长度，但John Klensin随后接受了一个不正确的值，因为路径被定义为

Path = "<" [ A-d-l ":" ] Mailbox ">"

因此Mailbox元素(即电子邮件地址)周围有尖括号，以形成一个Path，其最大长度为254个字符，以限制Path长度为256个字符或更少。

RFC 5321中规定的最大长度说明:

反向路径和正向路径的总长度最大为256个字符。

这里更正了RFC 3696。

人们应该特别注意RFC 3696的勘误表。其中三个典型示例实际上是无效地址。

我整理了几百个测试地址，您可以在http://www.dominicsayers.com/isemail上找到它们

320

线段是这样的

{64} @ {255}

64 + 1 + 255 = 320

如果你正在验证电子邮件，你也应该阅读这篇文章:我知道如何验证一个电子邮件地址，直到我阅读RFC

其他的回答把水搅浑了一点。 简单的回答:我们控制的电子邮件的总字符为254个 256个代表整个电子邮件地址，其中包括开头隐含的“<”和结尾的“>”。因此，剩下254个供我们使用。

不幸的是，其他答案都是错的。大多数人引用了RFC 2821或更新的版本，该版本甚至没有定义电子邮件地址。它所做的就是定义路径。电子邮件地址由RFC 2822(或更新的版本)定义，可以更长。有效地址不是有效路径的例子有:

(Firstname Lastname) user@domain
Firstname Lastname <user@domain>

这两个都是相同的邮箱，但写得不同。因此，如果您的目标是在数据库中存储电子邮件地址，254、256或320个字节的限制可能太低了，尽管在实践中，这很少会成为问题。

根据以下文章:

https://www.rfc-editor.org/rfc/rfc3696(第6页第3节)

其中提到:

“有长度限制 电子邮件地址。该限制是最大64个字符(八位字节) 在“本地部分”(@前面)，最大长度为255个字符 (八位字节)在域部分(“@”之后)，总长度为320 字符。处理电子邮件的系统应该准备好处理 有那么长的地址，尽管很少有 遇到。”

因此，一个电子邮件地址的最大总长度是320个字符 (“本地部分”:64 +“@”:1 +“域部分”:255，总和为320)