Per-property mailboxes
You can run an entire portfolio through one intake address, and plenty of companies do. You can also give every building its own. This page is about choosing between them, and about what changes once mail arrives at a building's own address.
It is written for whoever administers the workspace, since creating mailboxes is an admin task.
What a mailbox is
A mailbox is an address on your organization's subdomain of inlet-ap.com, with a label, a note of what it routes to, and optionally the property it belongs to.
ap@yourcompany.inlet-ap.com
lakeshore@yourcompany.inlet-ap.com
riverside-jv@yourcompany.inlet-ap.com
Each one shows its verification state, how many messages it has taken in the last thirty days and when the last one arrived. That volume figure is the useful one in practice: an address with a proud label and no traffic for six weeks is a forward that somebody switched off.
Addresses must be on your own intake domain, and the part before the @ may use letters, numbers, dots, dashes, underscores and plus signs. The free plan includes one mailbox; more than one needs a paid plan.
When it is worth it
The question is not how many buildings you have. It is where the routing information lives.
| Your situation | The simpler answer |
|---|---|
| Vendors email a central AP address and the invoice names the building | One catch-all, plus rules on the property alias |
| Each building has its own vendors and its own published address | A mailbox per building |
| Separate owners or joint ventures whose books must not mix | A mailbox per entity |
| An outside bookkeeper handles two of your buildings only | A mailbox for those two |
| Fewer than a dozen buildings and one AP specialist | One catch-all until it hurts |
A mailbox per property is worth it when the address a vendor used already tells you the answer. It is not worth it when you would be creating fifty addresses so that a rule can be avoided — fifty forwards at your provider is fifty things that can be silently turned off, and a rule on Property alias reads the building's name off the invoice whichever address it arrived at.
The honest test: if you cannot say which forward would break first, you have too many.
Creating one
Mailboxes are created in settings. You give the part before the @, a label for your own benefit, and what it routes to. The address is checked against your own intake domain, so a workspace cannot claim an address belonging to somebody else's subdomain — which matters more than it sounds, because inbound mail is resolved by address alone.
The mailbox exists as soon as it is created. Send it an invoice before configuring anything else.
Plus addressing does not create a mailbox
An address such as ap+lakeshore@yourcompany.inlet-ap.com is delivered to ap@yourcompany.inlet-ap.com. The tag is stripped, and the mail lands in the base mailbox rather than in a new one.
This is normal mail behavior rather than a decision of ours, and it is worth knowing before you hand out forty tagged addresses expecting forty routes. If you want the tag to mean something, create the mailbox, or write a rule.
How routing is then decided
Give a mailbox a property when you create it, and mail arriving there is coded to that property. This is a fallback rather than an override, and the distinction matters:
| Situation | Property used |
|---|---|
| The invoice names a property your aliases recognize | The property the invoice names |
| The invoice names nothing recognizable | The mailbox's property |
| Neither | None — the document goes to review |
The invoice wins because a vendor who sends a Maple Street invoice to the Lakeshore mailbox has made an addressing mistake, not a coding decision. The mailbox fills a gap; it does not argue with the page.
Rules can also match the mailbox directly. Intake mailbox is a rule field, so a rule can read "if the intake mailbox contains lakeshore@, code to 6120 and assign Priya". Use contains with the local part — lakeshore@ — rather than typing your whole intake subdomain.
The resulting division of labor:
| Decision | Made by |
|---|---|
| Which workspace the mail belongs to | The address the vendor sent to |
| Property, when the invoice names one | The extracted property hint, matched against your aliases |
| Property, when it does not | The mailbox it arrived at |
| GL code, reviewer, quarantine, auto-approval | Your rules, in priority order |
Two things are still worth doing even with per-property mailboxes in place:
- Give each building aliases that vendors actually type. "Lakeshore", "Lakeshore Ct" and "123 Lake Shore Drive" all resolving to one property does more for coding accuracy than any number of addresses, and it works for mail that arrives at the catch-all.
- Keep the mailbox property and the aliases in agreement. They are two statements about the same building, and a building that has moved between entities is the usual reason they drift apart.
Property, unit, entity, GL account, class and cost center are fields on the document rather than attributes welded to the vendor, so an invoice can still be split across three buildings when the roofer worked on all of them.
Forwarding into a per-property mailbox
If you already publish per-building addresses on your own domain, forward each one to its InletAP counterpart:
lakeshore@yourcompany.com -> lakeshore@yourcompany.inlet-ap.com
InletAP cannot receive mail addressed to a domain you own, so this is the route in. Forwarding your existing mailbox covers the setup and the confirmation step both Google and Microsoft require.
One caution about rules in this arrangement. Forwarding at your provider usually preserves the original sender, so rules on Source email keep working. A person pressing Forward by hand does not: the message then comes from your colleague, and a sender rule written for the vendor will not match it.
Housekeeping
A mailbox per property is a small standing commitment. Two habits keep it honest.
Review the volume figures once a quarter. A property that changed managing agent, or a forward that expired when somebody left, shows up as a mailbox that has gone quiet while its building is still sending you bills through somebody else's address.
Retire nothing in a hurry. A vendor will use last year's address next spring, and a mailbox that still exists is a message that arrives rather than one that bounces back to a vendor who then telephones your office.
Where to go next
- Intake addresses — how your subdomain and first mailbox are issued.
- Forwarding your existing mailbox — bringing your published addresses in.
- Your first coding rule — refining what a mailbox routed.
- Plans and limits — how many mailboxes each plan includes.