这与上面描述的智能主机路由方案配合得非常好。全局路由信息仅由网关维护；域内的小型主机只需一个手写的路径文件即可，该文件列出它们域内的路由以及到邮件枢纽的路由。即使是邮件网关也不必再拥有世界上每个 UUCP 主机的路由信息。除了它们服务的域的完整路由信息外，它们现在只需要在数据库中拥有到整个域的路由。例如，下面显示的 pathalias 条目会将所有发送到 sub.org 域中站点的邮件路由到 smurf
.sub.org swim!smurf!%s任何发送到 claire@jones.sub.org 的邮件都将被发送到 swim，信封地址为 smurf!jones!claire。
域名空间的层次结构允许邮件服务器将更具体的路由与不太具体的路由混合使用。例如，法国的系统可能具有针对 fr 子域的特定路由，但将发送到 us 域中任何主机的邮件路由到美国的某个系统。通过这种方式，基于域的路由（这种技术被称为）大大减少了路由数据库的大小以及所需的管理开销。
然而，在 UUCP 环境中使用域名的主要好处是，符合 RFC-822 标准允许在 UUCP 网络和互联网之间轻松进行网关连接。如今，许多 UUCP 域都与充当其智能主机的互联网网关建立了连接。通过互联网发送消息速度更快，并且路由信息更加可靠，因为互联网主机可以使用 DNS 而不是 Usenet Maps。
为了可以从互联网访问，基于 UUCP 的域通常会让它们的互联网网关为它们声明 MX 记录（上面描述了 MX 记录）。例如，假设 moria 属于 orcnet.org 域。gcc2.groucho.edu 充当它们的互联网网关。因此，moria 将使用 gcc2 作为其智能主机，以便所有发送到外国域的邮件都通过互联网传递。另一方面，gcc2 将为 orcnet.org 声明 MX 记录，并将所有发往 orcnet 站点的入站邮件传递到 moria。
唯一剩下的问题是 UUCP 传输程序无法处理完全限定域名。大多数 UUCP 套件被设计为处理最多八个字符的站点名称，有些甚至更少，并且对于大多数套件来说，使用点等非字母数字字符是完全不可能的。
因此，需要 RFC-822 名称和 UUCP 主机名之间进行某种映射。这种映射的完成方式完全取决于实现。将 FQDN 映射到 UUCP 名称的一种常见方法是使用 pathalias 文件
moria.orcnet.org ernie!bert!moria!%s这将从指定完全限定域名的地址生成纯 UUCP 风格的 bang path。一些邮件程序为此提供了特殊文件；例如，sendmail 使用 uucpxtable 来实现这一点。
当从 UUCP 网络向互联网发送邮件时，有时需要反向转换（俗称域名化）。只要邮件发送者在目标地址中使用完全限定域名，就可以通过在将消息转发到智能主机时不删除信封地址中的域名来避免此问题。但是，仍然有一些 UUCP 站点不属于任何域。它们通常通过附加伪域名 uucp 来进行域名化。