The sixty-second answer
Forward when one person handles the address and never replies as it. Use a shared mailbox the moment a second person works the queue, or a reply must come from info@ rather than from a named individual. Forwarding is a routing rule with no memory; a shared mailbox is one store several people open.
They are not two versions of the same thing
Forwarding and shared mailboxes get compared as if they were competing products. They are not. They are different mechanisms that happen to solve the same problem for a while.
Forwarding is a rule applied at delivery time. The mail standard describes alias expansion precisely: the recipient mailer "simply replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged", and the message is delivered or forwarded onward [1]. Nothing is stored at the alias. There is no state, no history, and nothing that knows a second message on the same subject arrived last Tuesday.
A shared mailbox is a real store with real credentials, opened by more than one authenticated person. IMAP has this in the protocol: an Other Users' Namespace, in which "the currently authenticated user MUST be explicitly granted access rights" before they can see another user's folders, and a Shared Namespace for mailboxes that are meant to be shared and do not belong to any individual [5]. Rights are granted per user and per mailbox through the access-control extension, which defines the specific rights required for different operations [4].
The practical distinction: forwarding gives several people several copies. A shared mailbox gives several people one copy.
The test
Answer three questions about the address.
How many people work it? One, and forwarding is fine. Two or more, and you need a shared mailbox - not as a preference, but because forwarding to two destinations means two independent copies and no way for either person to know the other has replied. In a shared mailbox, the server pushes updates to every connected client when another agent changes a flag or expunges a message [5], so "read" and "answered" are facts everyone can see.
Does a reply have to come from the address? If a customer writes to accounts@ and the answer arrives from someone's personal address, half of them will not connect the two and some will treat it as suspicious. Forwarding cannot solve this; it only moves mail inbound. Replying as an address requires credentials for that address.
Does it need to outlive the person? If the address is on a contract, an invoice or a regulator's file, it should not depend on a forwarding rule pointing at a staff member who may leave. See what to do with an employee's email account when they leave for how badly this can unwind.
Any "yes" past the first question and the answer is a shared mailbox. All three "no" and forwarding is genuinely the simpler, cheaper, correct choice - there is nothing wrong with it.
The authentication cost nobody mentions
Forwarding has a side effect that shows up as a deliverability problem weeks later, and it is worth understanding before you build a business process on it.
When a message is forwarded, the final receiving server sees your forwarder's IP address, not the original sender's. Path-based authentication - checking whether the sending IP is authorised by the original domain - therefore fails, because your forwarder was never listed by the sender. The SPF specification addresses this directly in its guidance for mediators: "Mediators can solve the problem by rewriting the MAIL FROM to be in their own domain", noting that this means rejected mail then has to be handed back to the original sender by the forwarding service, and that the various schemes for doing so "vary widely in complexity and resource requirements" [2].
That matters because of what sits on top. DMARC asks for Identifier Alignment between the domain in the visible From field - what it calls the Author Domain, "the domain name of the apparent author, as extracted from the RFC5322.From field" - and an authenticated identifier, and treats a message as passing on the signature side if any aligned signature verifies [3]. Signature-based authentication generally survives forwarding, because it travels with the message; path-based authentication generally does not, because the path changed.
Two consequences for a small business. First, mail forwarded into your business can arrive looking less authentic than it is, which is one route to legitimate messages landing in junk. Second, if you forward mail out of your domain to a big consumer provider, you are handing that provider a stream of messages that fail one of the checks it cares about, from your infrastructure. Neither is fatal. Both are avoided entirely by delivering into a shared mailbox instead of relaying to somewhere else. The wider picture is in SPF, DKIM and DMARC explained for small business and why business email goes to spam.
Forwarding to a free personal account is the version to avoid
The most common real-world forwarding setup in a small business is: create info@ on the company domain, forward it to the owner's free personal account, answer from there. It costs nothing and it works on day one.
What it also does is put your customers' personal information into an account the business does not administer, cannot audit, and cannot revoke. PIPEDA's Schedule 1 requires knowledge and consent for the collection, use and disclosure of personal information, forbids using or disclosing it for other purposes without consent, and entitles an individual on request to be informed of the existence, use and disclosure of their information [6]. If a customer asks where their file went, "into my personal inbox, and I think I forwarded it to my brother-in-law who does the books" is a true answer and a bad one.
It also makes replies come from the wrong place, which brings you back to the second test question. Business email on your own domain versus a free address covers why this matters commercially as well as legally.
Where lists come in
There is a third mechanism people reach for and should usually not: a distribution list. The standard distinguishes it from an alias explicitly. A mailing list "may be said to operate by 'redistribution' rather than by 'forwarding'", and critically the return address in the envelope is changed "so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator" [1].
That is a sensible design for a newsletter and a poor one for a customer queue: bounces stop reaching the person who sent the message, which means a customer who mistypes an address gets silence. Use lists for announcements, not for the address on your website.
What a shared mailbox costs you in practice
Honestly: a seat and a small amount of discipline. Providers bill for mailboxes, and a shared mailbox is a mailbox - though some, including us, do not charge for the aliases layered on top of one. That trade-off is worth doing deliberately rather than by default; how many email addresses your business actually needs walks through the counting exercise, and addresses, aliases and shared mailboxes compares the three side by side.
The discipline part is agreeing what "handled" looks like - a folder, a flag, a reply - so that the shared state the protocol gives you actually means something to the humans using it.
Where we sit
MapleMail supports all three patterns, because all three are legitimate in the right place. Aliases and forwarding rules are configuration, not billed seats. Shared mailboxes are real mailboxes with per-user access rights, so two people can work a queue without sharing a password and access can be removed the day someone leaves. Everything runs on your own domain, hosted in Canada.
Our practical advice is the boring one: start with forwarding if you are one person, and move the address to a shared mailbox the first time two people touch it. Do not wait for the duplicate-reply incident to tell you which one you were.
Plan details and what a mailbox includes are on the pricing page. If you already have a tangle of forwarding rules pointing at personal accounts and want to unpick it, switching business email providers without losing mail describes the migration honestly, including the parts that take patience.