Cost

9 min read

What does email cost for an organisation of a thousand people?

At a thousand people the interesting number is not the seats. It is the addresses that are not people — and at this size there are usually more of those than there are staff.

Short answer

At a thousand employees, the seats are rarely the negotiable part: staff who need a mailbox, calendar and document suite need a licence, and that cost scales with headcount. What is negotiable is everything else — role addresses, departments, aliases, functional identities and the mail of people who have left. Those routinely outnumber staff, need no mailbox of their own, and are the part of the bill worth engineering.

Cost comparison
Category	Roughly how many	Needs a full mailbox?
Staff who need a workplacemailbox, calendar, documents	Most of the headcount	Yes
Department and role addresses`hr@`, `invoices@`, `security@`, per-site addresses	Dozens to hundreds	No
Functional and system addressesalerts, monitoring, ticketing, `noreply@`	Dozens	No
Name-format aliases`j.smith@` as well as `jane.smith@`	One or more per person	No
Leavers still receiving mailredirected to a successor	Grows every year	Usually not
Compliance and legal addresses`dpo@`, `privacy@`, `abuse@`, `postmaster@`	A handful, mandatory	No

The tinted rows are addresses rather than workplaces. Whether they cost anything depends entirely on whether your model prices addresses or people.

Only the first row needs a workplace per person. Every other row is an address, and addresses do not need licences unless the model forces it.

The number that grows fastest is not headcount

At small scale, addresses and people are roughly the same number. At a thousand people they diverge sharply, and the divergence is structural rather than accidental.

Every department wants an address. Every site, every product, every regulatory obligation, every integration that sends alerts. Then there is the name-format problem: once you have a thousand people you have collisions and inconsistencies, so most organisations end up carrying more than one address per person just to keep old mail flowing.

Then there are leavers. At a thousand people with normal turnover, a hundred or so people leave each year, and a significant fraction of their addresses must keep receiving mail — because customers, suppliers and regulators keep writing to them. Under a per-seat model that is a licence for someone who no longer works there, renewed annually, forever.

At scale the question is not what a seat costs. It is how many things you are paying seat prices for that are not people.

One address

[email protected]

What the outside world writes to

Two licensed mailboxes in Finance
Both people read it in the inbox they already use
A shared archive address
Optional — keeps a copy where records live

No mailbox is created and no licence is consumed. The published address outlives whoever staffs it.

The address is a rule, not an account. Changing who staffs the desk is a routing change made in seconds, rather than an account handover.

The leaver problem, which compounds

This is the cost that surprises finance teams, because it is invisible in year one and unavoidable by year five.

Keep the licensed mailbox

The default, because it needs no decision

Their mail history stays accessible and exportable (advantage)
Satisfies retention and legal-hold obligations (advantage)
A recurring licence for someone who has left (drawback)
The count only ever grows (drawback)

Archive once, then route the address

A deliberate decision per leaver

History is exported once and retained wherever records live (advantage)
The address keeps working, pointed at a successor (advantage)
No recurring per-person cost after the export (advantage)
Needs a process and someone to run it at exit (drawback)

Both are legitimate and most organisations need some of each. The mistake is using the first for every leaver by default, because it is the path of least resistance.

What a mixed model looks like at this size

The realistic answer at a thousand people is not replacing the suite. It is being deliberate about which identities need a workplace and which need only an address.

1
Licence the people who use a workplace
Mailbox, calendar, documents, central administration and retention. For most staff this is the correct purchase and there is no saving worth pursuing.
2
Move role and department addresses to routing
invoices@, hr@, security@, per-site addresses. Each delivers into the licensed mailboxes of whoever staffs it. No licence, no mailbox, and changing who receives it is a routing change rather than an account change.
3
Route system and alert addresses
Monitoring, ticketing, integrations. These need to receive and be replied to, never to hold history of their own.
4
Route the name-format aliases
Every alternative spelling of a person's name points at their one real mailbox. This is the largest count and the smallest complexity.
5
Handle leavers with an explicit rule
Export at exit, then route the address to the successor. Applied consistently, this stops the licence count growing independently of headcount.

What scale changes about governance

A thousand addresses is a system, not a list, and the operational questions matter more than the price.

Provisioning has to be bulk. Creating identities one at a time does not survive a reorganisation. Import from the source of truth you already maintain.
Deprovisioning has to be as easy as provisioning. An organisation that can create four hundred addresses in a minute and remove them one at a time will accumulate addresses nobody owns.
Every address needs an owner. Not a person who reads it — a person accountable for whether it should still exist. Role addresses with no owner are how a domain ends up with entries nobody can explain.
Authentication has to be watched, not configured once. At this size several teams send on the domain's behalf, and the sending list changes without anyone telling the domain owner. A DMARC policy with reports being read is the only way that stays visible.
Review annually against the directory. Addresses for people who left, departments that merged, and products that were retired do not remove themselves.

The last two are where organisations of this size are most often exposed. A domain with a thousand identities and no one reading authentication reports is a domain where a supplier can be sending as you and nobody would know.

Making the case internally

This is a procurement conversation as much as a technical one, and it goes better with a count than with an argument. The count is also the part nobody has, because no single system holds it.

Week 1
Export every identity that exists
From the directory, the mail platform and the DNS. The three lists will not agree, and the disagreement is itself a finding worth reporting.
Week 1
Classify each one
Person needing a workplace, role address, functional address, alias, or leaver. Most organisations have never had this breakdown and it is the whole argument.
Week 2
Price the classes separately
Seats at your current per-user rate; addresses at whatever a per-domain plan costs. The gap is the case.
Week 3
Pilot one department
Move that department's role and functional addresses only. Nobody's personal mailbox is touched, so the blast radius is small and the evidence is real.
Week 4
Report what actually changed
Licences released, addresses still working, incidents raised. If the answer is “none” on the last one, that is the number the decision turns on.

Every step produces a number somebody can check. The proposal at the end is arithmetic rather than opinion, which is what makes it survive a finance review.

Two things are worth stating explicitly in that report, because leaving them out is what makes a proposal look like cost-cutting rather than engineering. Say which identities you are deliberately not moving and why — the regulated ones, the ones under hold, the ones whose mail the organisation must be able to read. And say what the migration costs in effort, because a proposal that claims a saving with no offsetting work is not believed, and should not be.

What to remember

At a thousand people, addresses substantially outnumber staff, and the extra addresses are what is worth engineering.
Seats for people who use a workplace are rarely the negotiable part. Role, functional, alias and leaver addresses are.
The leaver count compounds: with normal turnover, per-seat licences for departed staff grow independently of headcount.
Anything requiring central control, retention or legal hold needs a licensed mailbox. That boundary is not a cost decision.
At this scale, bulk provisioning, per-address ownership and someone actually reading DMARC reports matter more than the unit price.

Questions people ask next

Can we cut our email licence count without losing control of mail?

For identities that are not people, yes — role, functional, alias and most leaver addresses need an address rather than a workplace. For anything requiring retention, legal hold or the ability to read a person's mail after they leave, no: that requires a licensed mailbox, and treating it as a cost line is how organisations lose access to records they later need.

What do we do about employees who have left but still receive mail?

Export their mailbox once at the point of departure into wherever your records live, then route the address to their successor. The address keeps working for the customers and suppliers who still write to it, and the recurring per-person cost stops. The important part is doing it at exit, while the export is still straightforward.

How do we handle a thousand aliases without a week of clicking?

Import them from the directory you already maintain, using a dry run that validates every row before anything is created. The work is in producing an accurate list; the creation itself is a minute. Deprovisioning needs to be equally bulk, or the list only ever grows.

Does routing weaken our security posture?

Not on the authentication side — SPF, DKIM and DMARC apply to the domain regardless of which model an address uses. It does change where mail rests: routed mail lands in the recipient's mailbox rather than one you administer, which is exactly why identities under retention or legal hold must stay licensed.

Who should own a role address?

A named person accountable for whether it should still exist, separately from whoever reads it. Without that, role addresses accumulate: nobody creates one by accident, but nobody removes one either, and after a few years a domain carries entries no one can explain.

What is the single biggest email risk at this size?

Nobody reading the authentication reports. At a thousand people, several teams and suppliers send on the domain's behalf and the list changes without anyone telling the domain owner. A DMARC policy whose reports are actually read is the only mechanism that makes unauthorised sending visible before a customer reports it.

How do we produce the numbers to justify a change?

Export every identity from the directory, the mail platform and the DNS, then classify each one as a person needing a workplace, a role address, a functional address, an alias, or a leaver. The three exports will disagree, which is itself worth reporting. Price the classes separately, pilot one department's role addresses, and report licences released against incidents raised.

Trusted references

Last reviewed 2026-08-16 · Brand My Inbox current