Can one email address deliver to several people's inboxes?

The problem this actually solves

Small organisations publish addresses that are not people: info@, bookings@, support@, hello@. Those addresses need to reach whoever is available, and the people who staff them usually already live in a personal inbox they check constantly.

The usual answers are worse than they look. A shared mailbox means another set of credentials and another app to check, which in practice means it gets checked less. Setting up a full mailbox for every published address costs a licence per address at most providers, for addresses that are not people. Manual forwarding rules set up inside one person's mailbox work until that person is on holiday or leaves.

Routing an address to several existing inboxes gets the mail in front of people in the place they already look, without giving anyone a new thing to check.

Setting it up

1. 1

   Create the address you want to publish

   info@, bookings@, whatever the outside world will write to. It does not need a mailbox of its own — it is a routing rule, not a place mail is stored.

2. 2

   Add each destination inbox

   Personal addresses, work addresses, addresses at other providers — they can be anywhere. Mixing providers is fine and common.

3. 3

   Let each destination confirm itself

   Every inbox receives a confirmation and its owner clicks the link. Warn people first: an unexpected confirmation is the single most common reason a destination stays pending.

4. 4

   Send a real test message

   From outside — a phone, a personal account — to the published address. Check that it arrives in every destination, not just the first one you look at.

5. 5

   Agree the reply convention before you publish it

   This is the step everyone skips, and the one that decides whether the setup works. See below.

The reply problem, and how to solve it

Delivery is the easy half. Three people receive a copy of the customer's message — and then three people each have their own copy, in their own inbox, with no shared record of what anyone did about it.

Two failures follow, and both damage trust with the customer rather than merely annoying the team. Either two people answer the same enquiry with slightly different information, or everybody assumes somebody else has it and nobody replies at all. The second is more common and much more expensive.

Set up replies to go out as the published address rather than as the individual. A customer who wrote to info@ and gets an answer from [email protected] learns your personal address, loses the thread, and often replies to the wrong place next time. Sending as the shared address keeps the conversation where it belongs and means the next reply reaches everyone again.

What to watch out for

Duplicate copies for people who are on two lists

If someone is a destination for both info@ and sales@, and a customer writes to both, they get two copies. This is correct behaviour and it looks like a bug. Decide who genuinely needs each address rather than adding everyone to everything.

Bounces from one destination affect nothing else

If one person's inbox is full or their address stops working, only their copy fails. The others still arrive. That is the intended behaviour, but it means a destination can quietly stop working without anyone noticing — which is why a destination that starts failing is worth an alert rather than a silent retry.

Automatic replies multiply

Three destinations with out-of-office replies enabled means a customer who writes once receives three out-of-office messages. Before a holiday period, it is worth deciding which single destination should answer automatically.

Forwarding and strict authentication

Mail forwarded onward is a well-known edge case in email authentication, because the message arrives at the final inbox from a server that is not the original sender's. Reputable services handle this correctly so that forwarded mail still passes the checks that matter. It is worth knowing the issue exists, because it is the reason forwarding to some strict corporate systems occasionally needs an allowlist entry on their side.

Deciding who is actually on the list

The technical limit is generous and the useful limit is not. Adding people to a shared address feels free — it is one line — and every person added makes it slightly less likely that any individual acts on a message.

There is one more reason to keep the list short, and it only appears later. Every person on a shared address is a person who can forward, reply to, or accidentally expose whatever arrives — including the things customers send to info@ that they should probably have sent somewhere more private: account details, complaints about a colleague, occasionally a password. A short list is a smaller surface for that, and it is much easier to explain to a customer who asks who reads their mail.