Skip to main content

Email Address Architecture

Email addresses are identity surfaces. Every address we publish encodes who it routes to, what trust level it carries, what services authenticate against it, and how outbound mail signed with it gets validated. Addresses chosen casually create real cost: mail to former employees that no one reroutes, vendor accounts no one can recover, "billing@" that no one watches, password resets landing in the wrong inbox, DMARC drift that creates spoofing surface.

The principle: the address is architecture, not a label. Decide structure before assigning addresses, not after.

This page is the architectural standard for email addressing across DTC and client environments. Vendor-specific implementation lives in the relevant operations book.

A. Address Taxonomy

One address per workflow. Two addresses serve the same workflow if and only if they go to the same humans doing the same work. If they do, they are aliases of each other. If they don't, they are separate addresses with separate routing. Treating distinct workflows as a single address ("send everything to info@ and we'll sort it") creates a queue no one owns and triages poorly.

The address carries information. Reading the To-line should reveal the scope at a glance. A piece of mail addressed to a customer service queue should look different from a piece of mail addressed to a credential bucket from a financial institution. Visual triage gets free.

Customer-facing addresses live on the bare domain. Anything advertised publicly (help@, billing@, contact@) uses the primary domain. Operational and credential-holding addresses do not.

B. Routing & Per-Vendor Traceability

Scope by subdomain, not by alias proliferation. Every responsibility area gets a catch-all subdomain that delivers to a single mailbox in that scope. A vendor signs up with vendorname@scope.example.com, and the mail self-routes by domain. No per-vendor alias creation, no alias caps, and any vendor leak is instantly attributable to its source by the local-part of the address.

Why subdomains over the alternatives:

  • Plus-addressing (mailbox+vendor@example.com) gets rejected by roughly 5-10% of vendor signup forms and exposes the underlying address by trivial substring removal.
  • Dotted aliases (mailbox.vendor@example.com) hit hard caps in most email platforms (typically 30 per mailbox or group). At any operational scale, this cap will be hit.
  • Single bare-domain catch-all (*@example.com) catches every typo and dictionary spam attack, and provides no scope information from the address alone.

Triage before route. Don't pre-split queues by sub-type at small or medium scale. One incident queue with tagging beats two incident queues where one becomes the "definitely watching" inbox and the other becomes dead. Split when there is a dedicated owner for each side, not before.

C. Identity & Credentials

Unique logins over shared credentials, always when the vendor supports it. Most modern SaaS supports multi-user collaborative workspaces with named logins. Use them. Shared credential buckets exist only as a fallback for: (a) legacy or single-tenant systems that don't support multi-user, (b) accounts that fundamentally can't be split (the vendor's notion of "owner" is one human), or (c) vendors whose collaboration features are paid upsells we're declining. The "save a seat" reasoning is how shared credentials sprawl.

Receive and send are separate decisions. A credential-holding address (a shared bucket where password resets and 2FA codes land) is a receive-only address. Outbound mail goes from a person address or a role address, never from the credential bucket. This isolates the high-value receive surface from outbound exposure and reduces phishing-target visibility.

Mailbox type follows function, not feel. Two mailbox types:

  1. Shared distribution or collaborative queue. Group-style: members assigned, ownership tracked, no full mailbox login. Costs nothing per address in most platforms. Used for service queues, role addresses, and noise channels.
  2. Full user mailbox with delegated access. A real user account in the email platform with one or more delegates, carrying the platform's per-seat license cost. Used only when the address must (a) authenticate to external services that require a real account login (banks, vendor portals where 2FA codes land), or (b) hold a calendar (household, scheduling, shared availability).

Defaulting to type 1 keeps licensing cost proportional to credential-holding surface, not to operational queue count. In a well-architected taxonomy, most addresses are type 1 and the credential-holders and calendar-holders are type 2.

D. Operations

Vendor billing routing hierarchy. When a vendor's billing is locked to the owner account by default, prefer in this order:

  1. Ask the vendor's support team. Most vendors that don't expose a billing email field in the UI will add one via a support request. This is overlooked constantly.
  2. If supported, add the AP address as the billing recipient. Owner stays a person, billing routes correctly.
  3. If neither, sign up with the AP address as the owner email itself. Works only when the vendor doesn't require a "real human" owner (most don't, they default to assuming).
  4. As last resort, set up a forwarding rule on the owner's mailbox matching billing patterns (subject contains "invoice", "receipt", or sender domain matches vendor). Brittle and invisible. Document the rule on the vendor's record so it doesn't become tribal knowledge.

Required addresses (RFC 2142). postmaster@ and abuse@ must exist on every domain that sends mail. Forward them to a real human-watched mailbox (typically the administrative queue). Spam complaints, bounce reports, and abuse notifications all land here. Skipping them is a compliance gap and can break legitimate inbound flow during incident response from upstream providers.

Sender hardening for receive-only subdomains. When a domain has receive-only subdomains (per the per-vendor traceability principle), DMARC at the org level should be set with strict subdomain policy (sp=quarantine or sp=reject) so spammers can't spoof receive-only addresses to phish the org. SPF and DKIM align on the bare domain only; the subdomains have no legitimate sender, so any spoofing attempt is unambiguous.

When this applies

  • Greenfield design of a new domain's email taxonomy.
  • Audit or remediation of an existing taxonomy that has grown organically.
  • Migration between email platforms. The principles are platform-neutral; only the implementation changes.
  • Client environments where DTC architects or recommends communication structure.

When it does not apply

  • Personal accounts handled outside organizational scope. The principles hold philosophically but the implementation cost rarely justifies it for individuals.
  • Domains that exist solely to receive (no outbound at all). Some hardening principles drop in priority.
Back to top