One person frequently needs to be several senders. The owner of a small business is sales@ to prospects, accounts@ to suppliers and their own name to everyone else. A consultant working with three clients writes as three different domains. Being able to send as multiple addresses from one mailbox is what stops that meaning three mailboxes to check.
This page covers how identities work, the difference between an identity and an alias, and the authentication detail that decides whether those messages arrive.
Identities, Aliases and Mailboxes
Before you can send as multiple addresses, three related things need separating, because they get confused constantly and the distinction determines what you actually need.
An alias is an additional address that delivers into a mailbox. It handles receiving.
An identity is a From address you're permitted to send as, together with its display name and signature. It handles sending.
A mailbox is an account with its own storage and login.
To send as multiple addresses you want identities, usually paired with aliases so the same addresses also receive. What you don't want is separate mailboxes, because that reintroduces the several-places-to-check problem you were solving.
Everything an Identity Carries
An identity is more than a From line, and the extras are what make sending as multiple addresses convincing to recipients rather than obviously improvised.
Each one has its own display name, so mail from accounts@ can appear as your finance function rather than your personal name. Each can have its own signature, which is the part recipients actually read — a consultant writing to three clients wants three sets of contact details, not one generic block.
Replies are the detail worth getting right. When mail arrives at one of your addresses, the reply should leave from that same address rather than your default, or the counterparty ends up with a different address than the one they wrote to and their records drift. Setting the identity to be selected automatically based on the receiving address handles this without you thinking about it each time.
The Authentication Part
This is where the attempt to send as multiple addresses goes wrong, and it fails quietly.
Sending as an address on a domain you host here is straightforward — the authentication is already aligned, and nothing extra is required. Sending as an address on a domain you don't host is a different matter entirely.
If you set an identity to you@someoneelsesdomain.com and send it through us, the receiving server sees a message claiming that domain while originating from a server that domain never authorized. That fails SPF, likely fails DMARC alignment, and lands in spam or is rejected outright. The message will appear to send perfectly.
There are two correct ways to handle it. Either connect that mailbox as an external account, so replies leave through its own provider with its own authentication — covered in reading mail you don't host. Or add the domain here properly and authorize our sending in its DNS. What doesn't work is simply typing the address into an identity and hoping.
When Aliases Beat Identities and Vice Versa
The two are usually configured together when you send as multiple addresses, but the emphasis differs by case.
If people write to an address and you reply, you need both: the alias to receive and the identity to reply as. This is the common case — info@, support@, bookings@.
If you only ever initiate, an identity alone is enough. An address used solely for outbound notices doesn't need to receive, though it's usually wise to let it anyway, because replies happen whether you planned for them or not.
If mail arrives and you never respond, an alias alone suffices, and adding an identity you'll never use is clutter.
Alias allowances run 30 per mailbox on Starter, 50 on Pro and 100 on Agency, with none on the free plan, so the ability to send as multiple addresses in any serious way starts at the first paid tier.
Where This Is the Wrong Tool
Two situations where the ability to send as multiple addresses looks like the answer and isn't.
When several people need the address. If support@ is answered by three colleagues, giving each of them an identity means three people sending as the same address with no shared record of what was said. A shared mailbox keeps the history in one place and is the correct arrangement.
When the addresses are genuinely separate roles. If your consultancy work and your side business have different obligations, different records and possibly different owners eventually, separate mailboxes are cleaner despite the extra checking. Identities are for one person wearing several hats, not for two businesses sharing a hat stand.
What the Recipient Sees
The display name carries more weight than the address itself, because most mail clients show it and hide the address behind it.
That means a reply from an identity with the wrong display name looks wrong even when the address is right, and it looks wrong in the recipient's threading, where your earlier messages now appear to come from a different person. Setting the display name deliberately on each identity is a two-second job that prevents a category of small confusion.
Practical Setup
A few points come up when people first arrange to send as multiple addresses.
- Set the default deliberately. Whichever identity is selected when you compose a new message should be the one you use most, because the errors happen on messages you start rather than replies.
- Check the display name on each. An identity carrying your personal name on a
noreply@address is the sort of small inconsistency recipients notice. - Test each identity once. Send to an outside address, check it arrived and check the headers, particularly for any domain not hosted here.
- Match signatures to identities rather than using one for everything, since that's the difference between looking like a business and looking like a person improvising.
Where a whole domain should carry consistent branding regardless of who sends from it, a per-domain signature does that centrally rather than relying on each person configuring their own — covered in per-domain signatures.
