--- title: Intake addresses description: How your organization's intake mailboxes work, what to publish to vendors, and why mail sent to a domain you own has to be forwarded rather than intercepted section: Getting started order: 3 --- # Intake addresses An intake address is where invoices enter InletAP. This page covers what your addresses look like, when to create more than one, and the one structural limitation worth understanding before you print an address on a purchase order. ![Mailbox settings listing three intake addresses, each with DNS verification, routing target and 30-day volume.](/screens/mailboxes.png "A portfolio catch-all plus one address per property. Each shows where it routes and how much mail it has seen.") ## Your intake domain Your organization is issued its own subdomain of `inlet-ap.com` when the workspace is created, and every intake mailbox lives on it: ``` invoices@yourcompany.inlet-ap.com lakeshore@yourcompany.inlet-ap.com ``` The address works from the moment it is created. There is no propagation delay to wait out and nothing to configure before a vendor can send to it. The part left of the `@` is yours to choose, within the characters a sane mailbox name uses: letters, numbers, dots, dashes, underscores and plus signs. The part right of the `@` is not negotiable — an address on any other domain is refused, which is what stops one workspace claiming another's mail. ## Creating a mailbox Mailboxes live in settings, on the Mailboxes tab. Creating one takes three things: | Field | What it is | | --------- | ----------------------------------------------------------------------------------- | | Address | The local part. The domain is your own and is filled in for you. | | Label | What your team calls it, for example "Lakeshore intake". | | Routes to | Where mail here belongs by default — the whole portfolio, a property, or an entity. | Only an Admin can add a mailbox. Everyone else can read the list, which is deliberate: the addresses are the first thing a new AP specialist needs, and a disabled button with a reason beside it tells them what to ask for. The free plan includes one intake mailbox. Additional mailboxes begin at the Starter plan. See [plans and limits](/docs/plans-and-limits). ## One address, or one per property Most organizations start with a single catch-all and add property addresses when the routing is worth the administration. | Approach | Suits | Trade-off | | ----------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------ | | One portfolio address | Small portfolios, a single AP inbox today, anyone starting out | Every invoice needs its property from the document or a rule | | An address per property | Portfolios where vendors are building-specific, separate entities, joint ventures | Somebody has to hand the right address to the right vendors | You can mix the two. A catch-all for general suppliers and dedicated addresses for the buildings with their own vendor lists is a common and sensible shape. See [per-property mailboxes](/docs/per-property-mailboxes). ## What a mailbox tells you Each mailbox in the list carries its own operational detail: its label and what it routes to, a verification state for the address, the number of messages it received in the last 30 days and when mail last arrived. The volume figures are more useful than they look. An address you handed to twelve vendors six months ago and which has received nothing since March is telling you that those vendors are still sending somewhere else, which is a question worth asking before month end rather than during it. ## A mailbox can fill in the property When a mailbox is associated with a property, mail arriving there is coded to that property if the invoice itself names nothing your aliases recognize. This is a fallback and not an override. What the invoice says about itself always wins. A vendor who sends a Maple Street invoice to the Lakeshore address has made an addressing mistake rather than a coding decision, and treating the address as the final word would quietly turn one mistake into a wrong journal entry. The address is also visible to the rules engine. `Intake mailbox` is a condition field with the operators `is` and `contains`, so a rule can act on where mail arrived rather than only on who sent it: ``` Intake mailbox contains "lakeshore@" ``` `contains` matches the local part on its own, so a rule written this way survives any later change to how you name things. The full vocabulary is in the [rules reference](/docs/rules-reference). The rules engine begins at the Starter plan. ## Plus addressing does not create a mailbox Plus tags fold into the base address. Mail sent to either of these arrives in the same mailbox: ``` ap+lakeshore@yourcompany.inlet-ap.com ap@yourcompany.inlet-ap.com ``` That is standard mail behavior rather than a decision on our part, and it is worth knowing because a plus tag looks like routing and is not. If you want Lakeshore mail handled separately, create a `lakeshore@` mailbox. If you want it merely labeled, write a rule. ## Mail sent to a domain you own InletAP cannot receive mail addressed to `ap@yourcompany.com`, and neither can any other vendor of this kind. Routing for a domain you own is decided by your DNS records and your mail provider, and InletAP only receives mail on domains it controls. The way in is auto-forwarding. Set a forwarding rule at your own provider from the address you already publish into the InletAP mailbox that should handle it. Vendors keep using the address they have, the mail arrives here, and nothing has to be announced to anyone. The destination mailbox decides the default routing, so this works per property as well: forward `lakeshore-ap@yourcompany.com` to `lakeshore@yourcompany.inlet-ap.com` and that building's mail lands where it belongs. Forwarded mail arrives with the InletAP address as its envelope recipient, so if you want to treat it differently once it is here, write a rule on the sending address rather than on the address it was originally sent to. The full procedure, provider by provider, is in [email forwarding](/docs/email-forwarding). ## What to publish Two waves, run at the same time, get you to full coverage without a migration project. | Where | What to put | | ----------------------- | -------------------------------------------------------------------------------- | | New purchase orders | The InletAP address for that property, or the portfolio address | | Vendor onboarding forms | The same address, in the "send invoices to" field | | Existing vendors | Nothing. Auto-forward your current mailbox and let them update in their own time | Chasing every vendor to change their records is the part of this that never finishes, so it is better not to depend on it. Forwarding covers the ones who never get round to it, and both routes land in an InletAP mailbox, so both are processed identically. One practical note: put the address on the document vendors actually read. An address in the footer of a contract is not the address their accounts receivable clerk will use. ## Where to go next - [Email forwarding](/docs/email-forwarding) — bring your existing AP mailbox in without telling anyone. - [Per-property mailboxes](/docs/per-property-mailboxes) — when an address per building pays for itself. - [Rules reference](/docs/rules-reference) — including the intake mailbox condition. - [Plans and limits](/docs/plans-and-limits) — mailbox counts and what each plan includes.