Scaling a portfolio
From a Handful of Domains to Dozens: Email That Doesn't Charge You Per Name
Nobody decides to own forty domains. You register the third to protect the second, grab the fifth at 1am because the name was perfect, inherit the eighth from a client — and one ordinary afternoon you realize you are running a small forest and can't recall what half of it is for. The question was never whether your portfolio would grow. It is whether your mail setup falls apart when it does.
This is the operations manual for that growth: a running log you keep as the names pile up, the same short onboarding ritual for every new domain, and the handful of things worth standardizing at each stage — so domain forty is genuinely the same small task as domain four.
Where the setup you started with breaks
The arrangement that was perfect at two domains tends to fail in one of two ways as the count climbs. The money side belongs to another article; the one that bites day to day is operational drag. A separate account per domain means a separate login, a separate app, a separate place to check — and ten of those is worse than ten times the work of one, because now you also have to remember which is which. Growth turns a tidy setup into a scavenger hunt. The fix is not more discipline; it is a system where adding a name adds a row, not a chore.
The log that keeps a growing portfolio legible
The single habit that separates a calm portfolio from a chaotic one is keeping a log — not a mental note, an actual table you update the moment a domain joins. It takes seconds per name and saves you the afternoon, far enough down the road, when you cannot remember whether oldproject.io still forwards anywhere. One row per domain, seven columns: the Domain; its Purpose in a phrase (the thing you will have forgotten); whether MX is pointed so its mail reaches you; whether Auth — SPF, DKIM, DMARC — is published and passing; the Mode, catch-all or a named-address list; the Token it carries if you run a per-service address scheme; and Tested, the mark that says a real message landed and authenticated. Filled in and mid-flight, it reads like this:
| Domain | Purpose | MX | Auth | Mode | Token | Tested |
|---|---|---|---|---|---|---|
acme-client.com | Client: Acme retainer | ✓ | SPF·DKIM·DMARC ✓ | Named: hello@, billing@ | — | ✓ |
acrne-client.com | Defensive misspelling | ✓ | SPF·DKIM ✓, DMARC p=none | Catch-all | — | ✓ |
lunchpail.io | Parked 1am idea | ✓ | DKIM pending | Catch-all | lp | ✗ |
oldproject.io | Retired side project | Forward-only | SPF ✓ | Catch-all | — | ✓ |
This log is the artifact that makes everything else repeatable. It turns "do I even have this set up?" from a worry into a glance, and it is the first thing that saves you when a domain misbehaves — you already know its purpose, its mode, and whether it ever passed a test.
The onboarding ritual, identical every time
Every new name runs the same short sequence, and the last step writes its row into the log:
- Add the domain to your setup.
- Point its mail at your inbox so it starts receiving.
- Publish SPF, DKIM, and DMARC so it can send and prove it is really you.
- Choose its mode — catch-all, or the few named addresses you want — and note it.
- Send a test, confirm it lands and authenticates, and fill in the row.
That is the whole thing. There is no "but at scale you also have to…" footnote hiding at the bottom. The fortieth domain is these same five steps as the fourth — the ritual does not grow, which is the entire point.
Step five is the one people fake with a glance at a dashboard, and it is the one that actually protects you — so run it from the command line instead. A single query confirms the records resolve on the public internet, which is the only place that decides whether your mail is trusted:
$ dig +short MX yourdomain.com route1.mx.cloudflare.net. route2.mx.cloudflare.net. route3.mx.cloudflare.net. $ dig +short TXT yourdomain.com | grep spf1 "v=spf1 include:_spf.mx.cloudflare.net ~all"
Those three route{1,2,3}.mx.cloudflare.net hosts are Cloudflare Email Routing's own inbound servers: seeing them come back is proof the domain's mail is pointed at the right place, and the SPF line is proof it is cleared to send. (No dig on hand? nslookup -type=mx yourdomain.com is the Windows-friendly equivalent.) Only when both return what you expect does the Tested column earn its ✓ — and that is the one check that turns a row in the log from a hopeful note into a verified fact.
A domain portfolio should be an asset, not a chore. If adding a name makes your email worse, your tooling is fighting your growth.
What hardens as the count climbs
The onboarding steps never change; the habits around them should, each locked in at the point it starts to hurt. Early, while changing your mind is still free, fix your conventions — a default mode, an address scheme, and the log's first row. Once publishing records from memory gets error-prone, templatize the DNS so every new domain is paste, not recall, and label mail by the address it arrived on. Once you are into the dozens, run a periodic sweep of the log: does every row still authenticate, is any catch-all collecting leaked-address spam, are there names quietly receiving mail you forgot you owned? Past thirty the only real risk is forgetting — retire names you no longer use, and keep the purpose column honest so a name's reason for existing never dies with your memory of it.
Who actually lives at this scale
This is daily reality for more people than you'd think: indie makers with a graveyard-and-garden of projects, each on its own name; domain investors holding a portfolio who still want every name to receive and answer mail; agencies and freelancers juggling their own brands plus client domains; small teams that spin up a new brand faster than a traditional provider's billing can keep up. What unites them is that names are cheap to acquire and, under old pricing, expensive to service — so the system that treats name forty like name two is the one that lets the collection keep growing.
Growth without the dependency
One last reason the model matters more the bigger you get: the more domains you run, the more it hurts to be at the mercy of one provider's policy. When your whole portfolio's mail depends on a single company's current rules, one change can upend all of it at once. Running your own mail on your own account removes that single point of failure. And with a zero-access design your growing archive is encrypted at rest under a key only you hold — the host stores ciphertext it cannot open. That is not a promise that anything is unbreakable: mail still arrives in the clear and is encrypted on receipt, and sending still leans on a provider to relay it. But no matter how large the forest gets, your correspondence is not sitting readable on someone else's server.
- Is there really no limit on domains?
- There is no per-domain fee and no seat count, so the number of domains is not the thing you are billed or capped on. You run on your own infrastructure, which has a modest cost you control, but adding names does not change the deal.
- Does adding domains make the inbox messier?
- Not if you sort by the address mail was sent to. More domains means more labels, not more chaos. Everything still arrives in one place you already read.
- How long does onboarding a new domain take?
- A few minutes of DNS changes plus a quick test. It is the same short checklist whether it is your third domain or your thirtieth.
- What if I only have a few domains now but expect to grow?
- That is the ideal time to choose a model that scales flatly. Starting on a per-domain plan and migrating later is more work than beginning on one that already handles unlimited names.