Some addresses do not deserve an inbox. Free unlimited forwarding to anywhere, no copy kept, no seat used, plus the honest part most providers leave out: what forwarding does to SPF and DKIM, and when to use an alias instead.
Some addresses do not deserve a mailbox. invoices@yourcompany.eu should land wherever your bookkeeper already works. careers@ should go to the agency handling the search. The address on the old domain should follow whoever inherited that relationship. None of these needs an inbox, a password, or a person checking it.
Forwarding is the feature that handles them, and it is one of those features that is either free and unlimited or a line item, depending on how a provider feels about you. Ours is free and unlimited. This post is how it works, and more usefully, what forwarding does to your mail on the way out.
You pick an address on one of your verified domains, you give a destination anywhere else in the world, and mail sent to the first arrives at the second. No mailbox is created. No seat is used. The address does not appear in your workspace as a person.
Owners and admins can set them up, and every change is recorded in your audit trail, because a forwarding rule is a redirect of your company's mail to somewhere outside your company. That is exactly the kind of change you want a record of, especially the ones you did not make.
When mail hits a forwarded address, it is redirected out and nothing is stored on our side. That is a deliberate default rather than an oversight.
The alternative, keeping a copy in some hidden mailbox, means your company is silently accumulating a shadow archive of forwarded mail that nobody looks at, nobody manages, and nobody remembers when they think about where their data is. If you want a copy, the honest way to get one is to make the address a real alias on a real mailbox and forward from there, deliberately, in the open.
Under the surface, a forward needs two things to be true: your mail server has to accept mail for an address that has no mailbox, and something has to send it back out again.
We do that with one hidden holding account per workspace. It has no password and belongs to no group, so nobody can log into it, and it is not a billable seat. Every forwarded address in your workspace is registered on it, and a single set of rules on that account redirects each one to its destination.
The reason that matters to you: because we own that account entirely, the rules we generate live somewhere no human uses. We never touch the filters your colleagues write for themselves on their own mailboxes. Your own rules and our forwarding machinery cannot collide, because they are not in the same place.
A few things are not allowed, and each one is preventing a specific failure.
The source has to be on a domain you have verified with us. Forwarding an address on a domain whose mail does not reach us would create a rule that silently never fires. Better to refuse it than to let you configure a fiction.
The source cannot collide with an existing mailbox or alias. If it did, two systems would both have a claim on the same address, and which one wins would be a matter of ordering. That is the kind of ambiguity that is fine for months and then ruins a Tuesday.
The destination has to be outside your workspace. This is the one that trips people up, and it is worth understanding. If you forward sales@yourcompany.eu to you@yourcompany.eu, the mail comes back into the same system, which may match the same rule, and now you have built a loop. For delivering to a colleague inside your workspace, an alias is the right tool: it is instant, it has no loop risk, and you can send from it too.
Here is the part most providers do not put in writing, and you should know it before you rely on forwarding for anything important.
Forwarding is hard on email authentication. When we redirect a message to your accountant's inbox at some large consumer provider, that provider sees mail arriving from us carrying a From address belonging to whoever originally sent it. The sender's SPF record does not list us, because the sender has no idea this forward exists. That is not a flaw in our setup, it is what forwarding is: an intermediary that the original sender never authorised.
| Check | Survives forwarding | Why |
|---|---|---|
| SPF | No | It authorises the sending server, and we are not on the original sender's list |
| DKIM | Yes | It signs the message, not the route, so the signature travels with it |
| DMARC | Passes on DKIM alone | One of the two aligning is enough, which is why keeping DKIM intact matters |
Two things follow. DKIM, which signs the message itself rather than the route, survives, so a message that was signed still verifies at the destination. And because it survives, we are careful not to break it. We strip our own spam-assessment headers before sending the message on, both because our verdict on a message is not something to hand to a third party, and because those headers are added after the message arrives and are not part of what the sender signed, so removing them leaves the signature intact.
The practical advice: forwarding is excellent for low-stakes routing, and it is the wrong tool for the mail your business depends on. If a real person needs an address permanently, give them a mailbox and use aliases. Keep forwarding for the addresses that genuinely belong to somebody outside your company.
We would rather tell you that than sell forwarding as magic and have you discover the limitation with an invoice you never received.
Because charging for it is a tax on tidiness. A company that has to pay per forwarded address will either buy a seat it does not need or leave the address unrouted, and both of those are worse for them than the few kilobytes it costs us.
Forwarding is on every plan, with no cap on the number of rules. It sits under Settings once you have a verified domain.