电子邮件地址至少由两部分组成。一部分是邮件域的名称，它最终会转换为收件人的主机，或代表收件人接受邮件的某个主机。另一部分是某种形式的唯一用户标识，可能是该用户的登录名、该用户的真实姓名（采用“名字.姓氏”格式）或将被转换为用户或用户列表的任意别名。其他邮件寻址方案（如 X.400）使用更通用的“属性”集，这些属性用于在 X.500 目录服务器中查找收件人的主机。
电子邮件地址的解释方式在很大程度上取决于您使用的网络类型。我们将专注于 TCP/IP 和 UUCP 网络如何解释电子邮件地址。
Internet 站点遵循 RFC-822 标准，该标准要求使用熟悉的 user@host.domain 表示法，其中 host.domain 是主机的完全限定域名。分隔两者的字符正确地称为“商业 at”符号，但如果您将其读作“at”，则会更容易理解。此表示法未指定到目标主机的路由。邮件消息的路由留给我们将稍后描述的机制。
如果您运行连接到 Internet 的站点，您会看到很多 RFC-822。它的使用不仅扩展到邮件，还蔓延到其他服务，例如新闻。我们在第 20 章中讨论了 RFC-822 如何用于新闻。
在最初的 UUCP 环境中，流行的格式是 path!host!user，其中 path 描述了消息在到达目标 host 之前必须经过的一系列主机。这种结构称为 bang path 表示法，因为感叹号俗称“bang”。如今，许多基于 UUCP 的网络已经采用 RFC-822 并理解基于域的地址。
其他网络仍有不同的寻址方式。例如，基于 DECnet 的网络使用两个冒号作为地址分隔符，从而产生 host::user 这样的地址。[1] X.400 标准使用完全不同的方案，通过一组属性-值对（如国家和组织）来描述收件人。
最后，在 FidoNet 上，每个用户都由一个类似 2:320/204.9 的代码标识，该代码由四个数字组成，分别表示区域（2 代表欧洲）、网络（320 代表巴黎和郊区）、节点（本地中心）和点（个人用户的 PC）。Fidonet 地址可以映射到 RFC-822；例如，上面的地址可以写成 Thomas.Quinot@p9.f204.n320.z2.fidonet.org。现在我们不是说过域名很容易记住吗？
当您将许多不同的系统和许多聪明人聚集在一起时，他们不可避免地会寻求方法来互连不同的系统，以便它们能够进行互联网工作。因此，有许多不同的邮件网关能够将两个不同的电子邮件系统连接在一起，以便邮件可以从一个系统转发到另一个系统。寻址是连接两个系统时的关键问题。我们不会详细研究网关本身，但让我们看一下在使用此类网关时可能出现的一些寻址复杂性。
考虑混合 UUCP 风格的 bang-path 表示法和 RFC-822。这两种类型的寻址方式不能很好地混合在一起。假设有一个地址 domainA!user@domainB。目前尚不清楚 @ 符号是否优先于路径，反之亦然：我们是否必须将消息发送到 domainB，由它将邮件发送到 domainA!user，或者是否应将其发送到 domainA，由它将其转发到 user@domainB?
混合不同类型地址运算符的地址称为混合地址。我们刚刚说明的最常见类型通常通过赋予 @ 符号优先于路径来解决。在 domainA!user@domainB 中，这意味着首先将消息发送到 domainB。
但是，有一种方法可以以符合 RFC-822 的方式指定路由：<@domainA,@domainB:user@domainC > 表示 domainC 上 user 的地址，其中 domainC 需要通过 domainA 和 domainB（按该顺序）到达。这种类型的地址通常称为源路由地址。依赖此行为不是一个好主意，因为描述邮件路由的 RFC 修订版建议忽略邮件地址中的源路由，而应尝试直接传递到远程目标。
然后是 % 地址运算符：user %domainB@domainA 首先发送到 domainA，它将最右边的（在本例中，是唯一的）百分号扩展为 @ 符号。地址现在是 user@domainB，邮件程序愉快地将您的消息转发到 domainB，后者将其传递给 user。这种类型的地址有时被称为“Ye Olde ARPAnet Kludge”，不鼓励使用它。
使用这些不同类型的寻址方式有一些含义，将在以下各节中描述。在 RFC-822 环境中，您应避免使用绝对地址以外的任何地址，例如 user@host.domain。
| [1] | 当尝试从 RFC-822 环境访问 DECnet 地址时，您可以使用 “host::user"@relay，其中 relay 是已知的 Internet-DECnet 中继的名称。 |