Email routing when every site has its own address

Mail is where a carefully separated network most often gives itself away, because a message carries the sending address, the sending host and the authentication records of the domain it came from. Getting this right is less about deliverability than about not undoing the separation you paid for.

The three ways a site can send

  1. From the server, as the domain. Simplest. The message leaves from the address the site sits on and is authenticated by that domain's own records.
  2. Through an external provider. The message leaves from the provider's infrastructure. Reputation is theirs, not yours.
  3. Through one shared account for everything. Convenient, and the one that quietly links your sites together.

Option three is the trap. Thirty sites on thirty distinct addresses, all sending through one mailbox, announce a common owner in every message header.

Authentication records are public

SPF, DKIM and DMARC are DNS records anyone can query. They are also, therefore, a fingerprint. If every domain in your network publishes an identical, unusual SPF record pointing at the same third party, that pattern is visible to anyone who thinks to look, in exactly the way a shared nameserver is.

This does not mean avoid authentication. Unauthenticated mail simply does not arrive, so you need the records. It means configure them per domain, from that domain's own position, rather than copying one template across the whole estate.

Set them per domain

  • SPF: list what actually sends for that domain, nothing more. A record inherited from another site permits hosts that domain never uses.
  • DKIM: a distinct key per domain. Sharing one key across many domains is both a fingerprint and a single point of failure.
  • DMARC: start in monitoring mode, read the reports, then tighten. Publishing a strict policy before you know what sends on your behalf breaks legitimate mail.

Sites that should not send at all

Many content sites send exactly one kind of message: a contact form notification to you. That does not need a mailbox on the domain, and every mailbox you create is inodes, backup weight and one more thing to secure.

Decide per site whether it needs mail at all. If the honest answer is no, do not enable it. This also removes an entire category of compromise, since abandoned mailboxes on forgotten sites are a standard way in.

Reputation follows the address

Sending from a dedicated address means the reputation earned belongs to that address alone, which is the same logic as the rest of the network. A shared sending address means a stranger's behaviour affects whether your notification arrives.

The converse also holds and matters more: if one of your own sites is compromised and starts sending, the damage is contained to that address rather than spreading across everything you own. That containment only exists if the sites are genuinely separated at the mail layer too.

A workable default

  1. Enable mail only on sites that need it.
  2. Send from the domain, on its own address.
  3. Publish SPF, DKIM and DMARC per domain, written for that domain.
  4. Never route the whole network through one shared mailbox.
  5. Check where each domain's records point during the periodic audit described in Running Your Estate.

The mail interface is documented at docs.cpanel.net. For the DNS side of separation, including private nameservers per domain, see Nameservers and DNS, and for what address diversity does generally, IP diversity and footprint.

Still not sure which way to go?

Tell us what you are building. If it needs less than you think, we will say so.

Talk to us · 24/7/365