Email Hygiene for a Five-Person Company: A Working Playbook
Per-vendor addresses, role inboxes that survive staff changes, breach containment, and routing invoices and alerts into tools instead of one inbox.
Small company, outsized blast radius
A five-person company runs on a surprising number of external services: payroll, accounting, a CRM, hosting, a registrar, a bank, suppliers, and two dozen SaaS tools nobody remembers signing up for. In most small companies all of that mail flows into two or three personal-ish inboxes, plus one shared info@ that nobody really owns.
That setup fails in predictable ways. A vendor breach exposes the one address wired into everything. An employee leaves, and every account registered to their inbox drifts into limbo. An invoice sits unread in the shared inbox until a supplier calls about late payment.
None of this needs an IT department to fix. It needs addressing discipline, which is cheap, and somewhere sensible to route mail, which you already have in the tools the team watches all day.
One address per vendor
Give every external service its own address: stripe@acme.hidemy.world, hetzner@acme.hidemy.world, payroll@acme.hidemy.world. With HideMy.world the address exists the moment the vendor's first mail arrives, so adopting the pattern costs nothing per signup beyond typing it.
The payoff is attribution and clean exits. When spam arrives at the address only your registrar ever knew, you know exactly who leaked. When you drop a vendor, you delete one address and the offboarding is actually finished. When finance asks where the hosting invoices went, the answer is one address, not a search across three mailboxes.
Per-vendor addresses also make phishing look weird on arrival. A fake 'Stripe billing problem' sent to office@ announces itself, because the real Stripe only ever had stripe@.
Role addresses that outlive employees
The riskiest address in a small company is firstname@ used as the registered contact for something important. People leave. The domain registrar, the bank, and the ad account do not care that Dana moved on; recovery mail still goes to dana@, and whoever controls that mailbox now controls the account.
Register accounts to role addresses instead: billing@, ops@, security@. Behind an alias layer the role address stays stable while the humans change. Forwarding targets are verified real inboxes, so when Dana leaves you repoint billing@ at her successor once, and every vendor relationship survives untouched.
This is also the honest fix for the shared info@ mailbox: keep the address, stop making humans poll it, and route what arrives there to wherever work actually happens.
Route operational mail into tools, not inboxes
Most operational mail does not want to be read, it wants to be acted on or logged. Server alerts belong where the on-call person already looks. Invoices belong where bookkeeping happens. A shared inbox is where both go to be forgotten until they become urgent.
HideMy.world delivers per-address mail wherever it is useful: Slack or Discord for alerts the whole team should see, Telegram or ntfy for whoever is on call, Notion for a running log, or a webhook straight into your own systems. Webhooks are HMAC-signed, retried on failure, and replayable, which matters on the day your endpoint was down during the incident.
Transformers go a step further and extract fields into clean JSON, so an invoice email can arrive as sender, invoice number, amount, and due date, ready for a script or an n8n workflow through the n8n-nodes-hidemy community node, instead of as a PDF attachment nobody opens on Fridays.
{
"address": "hetzner@acme.hidemy.world",
"invoice_number": "R0012845772",
"amount": "214.60 EUR",
"due_date": "2026-09-30"
}Contain the breach you will eventually get
Across forty vendors and a few years, at least one breach touching your data is close to a certainty. The question is what the attackers end up holding. If every account shares office@acme.com, they hold a key that fits phishing campaigns against your entire vendor list, with perfect targeting included.
With per-vendor addresses they hold one address, useful against one relationship, and recognizable the moment it is misused. Mail claiming to be your bank but arriving at the address you gave a freight supplier is not a judgment call. Pause the exposed address, re-register that single account, and move on.
Authentication checks cover the judgment calls that remain. Inbound mail is checked against SPF, DKIM, and DMARC, so a forged sender shows up as forged instead of relying on a busy person to squint at headers between meetings.
A starter setup for one afternoon
You do not need a migration weekend. Fix addresses opportunistically: every time you touch a vendor, move it to the pattern. Within a quarter the accounts that matter are covered, and every new signup follows the convention from day one.
On plans: Pro at €24.90 a month covers 5,000 emails a month, API access, and 5 team members, which fits a five-person company exactly. Lite at €9.90 a month works for trying the pattern on a smaller slice first.
- Pick the naming pattern: vendor@acme.hidemy.world, agreed once, written down
- Create role addresses first: billing@, ops@, security@, each forwarding to a verified inbox a current human owns
- Move the five accounts that could hurt you most: registrar, bank, hosting, payroll, main SaaS
- Route alerts to Slack or ntfy, invoices to Notion or a webhook
- Add the convention to your onboarding notes so the next hire keeps it alive
The test of good hygiene
The test is boring on purpose. When someone leaves, does anything break? When a vendor is breached, do you know what to rotate? When an invoice arrives, does a human have to notice it in time? With addressing discipline and routing, the answers become no, yes, and no.
That is the whole pitch. No security transformation, no new platform to learn, just fewer single points of failure, built out of email addresses and an afternoon of setup.