What is the difference between a mailbox and an alias?

A mailbox is a destination that receives and holds mail - the architecture describes it as a conceptual entity that receives mail, usually paired with a long-term message store that a mail program reads through POP or IMAP [3]. An alias stores nothing. It is a simple re-addressing facility that swaps the envelope recipient address and lets the message continue on to one or more real mailboxes [3]. You pay for mailboxes; aliases are just routing.

How many paid mailboxes does a three-person business actually need?

Usually three - one per human who needs their own private inbox - plus possibly one shared mailbox for customer-facing mail. Everything else (info@, sales@, support@, billing@, accounts@, careers@) can be an alias pointed at one of those. Buying a separate paid mailbox for each address you want to exist is the single most common way small businesses overspend on email.

Which email addresses am I actually required to have?

Only one is a hard requirement in the standards: postmaster. Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox postmaster as a case-insensitive local name [2]. Everything else - info, sales, support, abuse, webmaster - is convention, and the standard is explicit that most organizations do not need the full set because not every organization offers every service [1].

Should customers email info@ or my personal address?

Customer-facing mail should land on a role address. Staff leave, and when the conversation lived at a personal address the history leaves with them. A role address is defined by the function, not the person, which is exactly why the standard defines names like INFO, SALES and SUPPORT by area and usage rather than by individual [1].

Is forwarding a role address to everyone good enough?

It works for a while, then it stops. Forwarding creates a private copy in each person's own mailbox, so nobody can see whether someone else replied, replies go out from a personal address, and there is no single record of the thread. A shared mailbox that several people open directly fixes all three. Multi-recipient aliases also make delivery problems harder to diagnose, because bounce reports go to the original sender, not to whoever administers the alias [3].

Does CASL require a particular email address on my marketing emails?

It does not name an address, but it requires that a commercial electronic message set out prescribed information identifying the sender, information enabling the recipient to readily contact them, and an unsubscribe mechanism [4]. The sender must ensure that contact information is valid for a minimum of 60 days after the message is sent [4]. A role address is the practical way to keep that route valid when the person who sent the campaign has left.

What address should a privacy or complaint request go to?

A stable role address that somebody actually monitors. PIPEDA's accountability principle requires organizations to establish procedures to receive and respond to complaints and inquiries, and to make available the name or title and address of the person accountable, to whom complaints or inquiries can be forwarded [5]. A title plus a role address survives staff turnover in a way a named personal address does not.

Do I need a catch-all address that accepts anything @mydomain.ca?

Generally no. A catch-all accepts every misspelling and every guessed name, which means it accepts every dictionary attack too. Set up the handful of aliases people plausibly type, and let the rest bounce so senders learn immediately that they got the address wrong. The role-name standard itself flags mailbox flooding as a foreseeable consequence of predictable names [1].

Does capitalisation matter in an email address?

For the standard role names, no. Well known mailbox names must be recognized independently of character case, so POSTMASTER, postmaster and PostMaster are all the same address [1], and the SMTP requirement for postmaster is explicitly case-insensitive [2]. For ordinary local parts the left side of the @ is technically opaque and interpreted only by the receiving domain [3], so treat it as case-insensitive in practice but never rely on case to distinguish two addresses.

Mailboxes, aliases and shared addresses: setting up email for a small team

The short answer

A mailbox stores mail and is what you pay for. An alias is a forwarding label that costs nothing extra. A shared or role address such as info@ or support@ belongs to a function rather than a person, so it outlives staff turnover. Most small teams need two or three mailboxes and a dozen aliases.

Almost every new business gets this wrong in the same direction. They decide they want info@, sales@, support@, billing@, accounts@ and careers@, they look at a per-user price, they multiply by six, and they either pay six times more than they need to or they give up and keep using a free personal address for business mail.

The multiplication is the mistake. Those six addresses are not six products. At most one or two of them is a thing you buy; the rest are labels.

Three different things with three different costs

A mailbox is a destination that receives and holds mail. The internet mail architecture describes a mailbox as a conceptual entity that receives mail, addressed as a local part and a domain name either side of the at-sign [3]. In practice it is paired with a long-term message store that your mail program reads over POP or IMAP [3]. That storage, that login, that sync - those are what a hosting bill is actually for.

An alias stores nothing at all. The architecture calls it a simple re-addressing facility: it substitutes one or more new addresses for the envelope recipient and the message carries on through the transfer service to those alternate addresses [3]. Almost nothing else about the message changes - the return address stays as the original sender wrote it [3]. An alias is a rule, not a container, which is why a well-designed email plan does not charge you per alias.

A shared or role address is a mailbox defined by what it does rather than who currently answers it. RFC 2142 exists precisely to standardise these. It sets out INFO for packaged information about the organization and its products, SALES for product purchase information, SUPPORT for problems with a product or service, and separately ABUSE for inappropriate public behaviour, NOC for network infrastructure and SECURITY for security bulletins and queries [1]. Note what is on that list and what is not - there is no BILLING in the standard. Billing@ is a perfectly sensible address to run, but it is your convention, not a published one.

The one address you are actually required to have

People conflate "standard" with "mandatory" here, and the distinction is worth getting right.

Exactly one address is a genuine protocol requirement. Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox postmaster as a case-insensitive local name, and that requirement extends to any of the domains for which the server provides mail service [2]. The same specification adds that mail systems are expected to make every reasonable effort to accept mail directed to postmaster from any other system on the internet, and that blocking it is an extreme measure that should be narrowly tailored [2]. It even notes that a server which identifies a contact point in its connection greeting has still not satisfied the requirement to maintain a postmaster address [2]. Postmaster is also where a mail system typically routes failed delivery notifications so a human can fix them [2].

If you are on hosted email, your provider handles that one. You will rarely see the mail.

Everything else is convention with teeth. RFC 2142's own framing is that organizations are encouraged to support at least each mailbox name for which the associated function exists within the organization, and that additional names and aliases are not prohibited [1]. Its rationale section is blunter still: most organizations do not need to support the full set of mailbox names defined here, since not every organization will implement all of the associated services - but if a given service is offered, then the associated mailbox name must be supported and must reach someone appropriate for that role [1].

Two mechanical details from that document save real support calls. First, well known mailbox names must be recognized independent of character case, so POSTMASTER and postmaster and PoStMaStEr are one address [1]. Second, the scope of a well known name is its domain name - abuse@yourcompany.ca must work at the top level even if the activity in question came from a subdomain [1].

Why role addresses should own your customer conversations

The argument for role addresses is not tidiness. It is that people leave.

When a customer has been emailing jenna@ for two years and Jenna moves on, the entire history of that relationship is inside Jenna's mailbox. You now have three bad options: keep paying for a departed employee's mailbox indefinitely, forward it somewhere and hope the new person can reconstruct context, or let the customer's next email bounce. Businesses discover this at the worst possible moment, usually mid-dispute.

When the same customer has been emailing sales@, nothing happens when Jenna leaves except that a different person opens the same inbox. The thread, the attachments, the quote history and the promises all stay where they were. That is the whole benefit, and it is worth far more than it costs.

There is a compliance dimension too. Under CASL, a commercial electronic message must set out prescribed information identifying the person who sent it, set out information enabling the recipient to readily contact that person, and set out an unsubscribe mechanism [4]. Critically, the sender must ensure the contact information is valid for a minimum of 60 days after the message has been sent, and the same 60-day validity applies to the unsubscribe address or web page [4]. Effect must be given to an unsubscribe request without delay and in any event no later than 10 business days [4]. If your newsletter's reply-to is the personal address of the person who happened to build the campaign, and that person leaves in week three, you have a problem that a role address would never have created.

The same logic runs through PIPEDA. Schedule 1 requires organizations to implement policies and practices including procedures to receive and respond to complaints and inquiries [5], to make available the name or title and the address of the person accountable for the organization's policies and to whom complaints or inquiries can be forwarded [5], and to put procedures in place that are easily accessible and simple to use [5]. Note "name or title" - the statute anticipates that you may publish a role rather than an individual. Schedule 1 also makes you responsible for personal information in your possession or custody including information transferred to a third party for processing, requiring contractual or other means to provide comparable protection [5], which is a good reason to know exactly where mail sent to that address is stored.

Forwarding to everyone stops working sooner than you think

The usual first setup is an alias that fans out: info@ forwards to Jenna, Marc and the owner. With one person answering, that is fine. With three, it breaks in three specific ways.

Nobody can see who replied. Each recipient got a private copy in a private mailbox, so all three either answer the same customer or all three assume someone else did. There is no shared read state, no assignment, no record.

Replies go out from the wrong address. Marc answers from marc@, and the customer's next message goes to marc@ forever, which quietly undoes the reason you created the role address.

Problems get harder to diagnose. The architecture warns that when an alias replacement list includes more than one address, delivery problems become more likely, and any problem reports go to the original author rather than to the administrator of the alias - the sender has no idea the alias even exists [3].

A shared mailbox fixes all three because there is one actual mailbox with one copy of each message, opened by several people, with replies sent from the role address. The moment more than one person answers a given address, that is the upgrade to make.

The honest concession: do not fake a org chart

If you are a one-person business, do not set up info@, sales@, support@ and billing@ all pointing at the same inbox. It does not fool anyone. Customers who email sales@ and get the same voice that answered support@ ten minutes ago work it out immediately, and it reads as puffery in a market where being small and reachable is usually the advantage.

One clear address - hello@ or your own first name @ your domain - is better. It sets an honest expectation and it is one less thing to maintain. This is exactly what RFC 2142 is saying when it notes that a role mailbox is expected where the associated function exists within the organization [1]; if there is no sales department, there is no sales function to route to.

The split starts earning its keep at the point where different addresses genuinely go to different places or different priorities. That is usually one of three moments: a second person joins and needs to own one lane of the mail; you start sending invoices and want payment questions separated from sales enquiries so cash flow does not hide inside general chatter; or volume gets high enough that you need to triage. Before any of those, a role split is overhead you are carrying for appearance.

A setup that fits most small Canadian businesses

Pay for a mailbox per human who needs a private inbox, plus one shared mailbox for customer-facing mail. That is typically three or four paid mailboxes for a team of three.

Then create aliases freely against those: info@, hello@, sales@ and support@ onto the shared mailbox; billing@ and accounts@ onto whoever handles money; careers@ onto the owner. Add abuse@ and security@ if you run anything internet-facing that could generate complaints, since the standard scopes those at your top-level domain [1]. Skip the catch-all - predictable names already invite mailbox flooding [1], and a catch-all invites every guess as well.

Publish a role address wherever a customer, a regulator or a stranger might need to reach you: your website contact page, your invoices, your email signatures, your marketing footers. Keep personal addresses for internal mail and for relationships where a named human genuinely is the point.

This week, do one concrete thing: list every email address printed on your website, your invoices and your last marketing email, and mark each one as mailbox or alias, personal or role. Any customer-facing address that is a personal mailbox is a thread that walks out the door with that person. Convert it to a role address, alias the old personal address into it so nothing bounces, and update the printed copies. It takes an afternoon and it stops being a problem permanently.

How to set up email addresses for a small team