Hosts and Hostnames

Chapter 2 gave you role vocabulary: MUA, MSA, MTA, and MDA name what a participant is doing on an email path. That still leaves a gap. A role is not a place. Software that performs a role still runs somewhere, and independently operated systems still need a way to refer to that “somewhere” when they cooperate.

People often fill the gap with loose language—“the mail server,” “the domain,” “the IP.” Those phrases mix several ideas. This chapter separates them at map depth.

Why This Matters

If you cannot tell a role from a host, you will treat every product label as if it were an architectural job. If you cannot tell a hostname from a domain name, or a name from an address, later DNS and addressing chapters will feel like jargon piles instead of answers to a question you already understand.

Operators diagnose clearer when they can say: this is the transfer role; it is running on that networked system; we are referring to that system by this name. That sentence is the bridge from Chapter 2 into the rest of Foundations.

Roles Tell You What; Hosts Tell You Where

Chapter 2’s safeguard still stands: learn the role, then ask how an implementation packages it.

Chapter 3 adds the next distinction:

An MTA is not “a host.” An MTA is a transfer role. Software implementing that role runs on one or more hosts. The same host may also perform other roles. Collapsing “MTA” into “server” undoes the precision Chapter 2 built.

What Is a Host?

In Internet architecture, a host is an end system: a networked system that uses communication services and generally executes application programs or services (RFC 1122).

That definition is broader than “a metal box in a rack.” A host is an architectural idea—the system at the edge of the network that runs applications—not a requirement that the packaging be one physical machine forever.

SMTP uses a related, scoped wording: for mail transfer, a host is a computer system attached to the Internet (or a private TCP/IP network) that supports SMTP. Such hosts are known by names, and ordinary practice is not to identify them by numerical addresses (RFC 5321).

Keep both layers in view:

General Internet sense: host as networked end system (RFC 1122).

Mail sense: host as a system participating in SMTP, referred to by name (RFC 5321).

A host may also be multihomed—attached through more than one network interface (RFC 1122). That detail belongs lightly here: it reinforces that “host” is not a one-cable appliance stereotype. Addressing depth comes later.

What Is a Hostname?

A hostname (or host name) is a name used to identify or refer to a host.

That sentence is the useful operator meaning. The standards history is less tidy than beginners hope. Modern DNS terminology notes that “hostname” is widely used but is not given a single crisp definition in the core domain-name and host-requirements documents people often assume define it (RFC 9499). In practice, people often mean a domain name written in the preferred name syntax (RFC 1034; RFC 1123); they also sometimes mean only the first label, or speak loosely of any name that points at a machine (RFC 9499).

This chapter does not need that historical fog as a glossary fight. It needs one durable habit:

Names Are Not Addresses

Names and addresses are different kinds of identifiers.

DNS design goals include that names should not be required to contain network identifiers, addresses, or routes (RFC 1034). SMTP’s host terminology likewise treats hosts as known by names and discourages identifying them by numerical addresses in ordinary naming (RFC 5321).

So:

A hostname is a naming handle.

An address is how a system is reached at the network layer.

They are related through naming infrastructure. They are not synonyms. How addresses work in detail is Chapter 4’s job.

A Domain Name Is Broader Than a Hostname

A domain name is an ordered sequence of labels in the Internet’s naming hierarchy (RFC 1034; RFC 9499). Domain names can identify hosts—and they can identify other entities in that hierarchy.

SMTP is explicit on the mail-relevant point: domain names may be used as names of hosts or other entities. A domain used in mail need not itself represent the hostname of the host that accepts the message (RFC 5321).

That is why this beginner trap is false:

It identifies the mail domain for that address. Finding which hosts participate in receiving for that domain is a later question. Do not collapse mailbox-domain, hostname, and receiving host into one word.

Teaching Model: Role, Host, Hostname, Naming

ROLE
  what is this participant doing?
        ↓  performed on
HOST
  which networked system is doing it?
        ↓  referenced by
HOSTNAME
  what name are we using to refer to that host?
        ↓  associated through naming infrastructure
DNS
  how can other systems learn information associated with that name?

A compact retention device for the same idea:

In plain language:

Role — the function being performed (Chapter 2).

Host — the networked end system where applications/services run.

Hostname — a name used to refer to a host.

Address — network-layer reachability information (kept light here; Chapter 4 deepens it).

These are different abstractions. Do not read the ladder as four mandatory one-to-one boxes. It does not mean one host equals one role, one hostname equals one address, or that DNS “creates” the host.

One Host, Several Roles — and the Reverse

Because a host runs applications and services (RFC 1122), one host can perform more than one email role. Submission and transfer software may share a host. Delivery software may live elsewhere. Packaging varies.

The reverse is also true at architecture depth: a single role can be distributed across more than one host. Chapter 2 already allowed roles to combine, co-locate, or distribute. Chapter 3 only adds that those arrangements still land on hosts.

Do not memorize a required machine count. Memorize the separation: role is not host.

One Host, Several Names

Hosts and other resources often have several names that identify the same resource (RFC 1034).

So different hostnames do not prove different physical machines. Likewise, seeing one hostname does not prove you have discovered the only name that system is known by. Alias and record mechanics belong later; the map-level fact is enough: names can multiply for one host.

A name can also be associated with more than one Internet address (RFC 1034). Keep that as orientation. How addresses are assigned, selected, or inspected is Chapter 4 and later DNS chapters—not this one.

Why Stable Names Matter

Independent systems cooperate across administrative boundaries. They need a shared way to refer to the hosts that perform roles.

Names give cooperating systems a stable reference that is not tied to a particular product dashboard string and is not identical to a numerical address. SMTP’s practice of knowing hosts by names exists for that kind of interoperability (RFC 5321). On the public Internet, those names are expected to be usable through naming infrastructure so other systems can learn information associated with them—without this chapter teaching the mechanisms.

Without stable names, every conversation about “which system?” collapses into local labels, temporary addresses, or vendor UI text that other operators cannot use.

Where DNS Enters — Without Becoming DNS

If systems need names, they also need naming infrastructure: a way for other systems to learn information associated with those names.

DNS is that distributed naming system. It associates domain names with resource information, including addresses, and replaced earlier host-table approaches to name-and-address translation (RFC 1034; RFC 1123).

That is all this chapter needs:

Names matter.

Names are not addresses.

Independently operated systems need a shared way to publish and learn name-associated information.

DNS is the Internet’s naming infrastructure for that job.

How lookups work, which record types mail depends on, and how operators inspect answers are later chapters. Finish this chapter wanting those explanations—not already holding the machinery.

Operator Perspective

Chapter 2 asked:

Chapter 3 adds:

Role-first reasoning still comes first. Host-and-name reasoning comes second. Product names and dashboard labels come after that, and only when you know whether the string in front of you is actually an Internet hostname or merely a local nickname.

Common Misconceptions

Key Takeaways