PuglieseWeb LTD · Shared Inbox
Team email that never lies to you about delivery.
A multi-tenant shared inbox for teams handling client mail across several domains. Built and operated in Europe, on infrastructure whose exact location we will name in writing — because for most of our buyers, that is the question that actually decides it.
Delivery
An accepted request is not a delivered email.
Most inbox tools show a reply in the thread the moment the server accepts the request, and leave you to discover days later that the mail server rejected it. We treat those as two separate facts, and show you both.
Every outbound message carries an explicit acknowledgement from the mail server. If the message was recorded in the thread but never accepted for delivery, it says so — on the message, where you will see it — and offers a retry that is safe to press.
- Sent
The mail server accepted the message for delivery. This is a positive acknowledgement, not an assumption drawn from a successful API call.
- Not sent
Recorded in the thread, rejected by the mail server. The message did not go out, and the thread says so rather than quietly implying success.
- Retry
Idempotent by design. Retrying a message that did in fact go out returns it unchanged — it never sends your client a duplicate.
Privacy
Senders do not get to watch your team read their mail.
Marketing and sales email is instrumented with tracking pixels — invisible images that report back when a message is opened, from which IP, and how often.
The inbox refuses to load remote images at the browser policy level, so those pixels never fire. Reading a message tells the sender nothing. This is enforced by the page’s content security policy rather than a preference a user has to find and switch on, which means it holds for every mailbox, every user, on the first day.
Sanitised before it renders
Hostile markup, scripts and event handlers are stripped from every received message rather than trusted and displayed.
Authenticated, never public links
Files are fetched with the caller’s credentials and time-limited storage URLs. No unguessable-URL-as-security.
Scoped per mailbox and tenant
Every query pivots on the mailbox the caller is entitled to. Unauthenticated requests are refused at the gateway.
Residency
We will tell you exactly where every byte sits.
“Hosted in Europe” is the vaguest claim in this market. Here is the specific version, which you are welcome to put in front of your own compliance reviewer.
| Component | Region | Location |
|---|---|---|
| Inbox, threads & attachments | eu-west-2 | London, United Kingdom |
| Application & API | eu-west-2 | London, United Kingdom |
| Identity & sign-in | eu-west-2 | London, United Kingdom |
| Inbound mail receipt | eu-west-1 | Dublin, Ireland |
Data rights
Erasure is a workflow, not an email to support.
Deletion of a client or a person is a tracked process with a cancellable grace window, an auditable trail, and evidence you can produce on request.
- A grace window before destruction. Deletion is scheduled, not immediate, and remains cancellable for the whole window — an accidental deletion is recoverable, and the record shows who requested it and when.
- Cascade and self-service in one view. Whether a person is erased because their organisation was removed or because they exercised their own request, both appear on the same compliance surface with the reason attached.
- Evidence, not assertions. Completed erasures are recorded with residual scans confirming nothing was left behind, so “we deleted it” is a record you can show rather than a claim you have to be believed on.
- Retention you can override, on the record. Correspondence is deleted automatically once it has been idle past the retention window. Anything you must keep — a contract, a complaint, a legal hold — is held with a stated reason and an end date, and the sweep evidences what it spared.
- Destructive actions require a fresh sign-in. The compliance view itself is read-only; anything irreversible sits behind re-authentication, so a borrowed session cannot destroy a tenant.
Operations
Releases are boring, on purpose.
The interesting engineering in a mail platform should be invisible to you. Ours goes into making deployment uneventful.
Staged, never straight to live
Changes land on a pre-production environment first. Production is a separate, deliberate promotion — not a side effect of merging code.
Contract-checked before promotion
Automation probes every endpoint the application depends on against live production and refuses to promote if one is missing. A broken release is blocked before it reaches you, not rolled back after.
Every request carries an ID
A correlation identifier follows each action through the stack, so “what happened to this specific message on Tuesday” is an answerable question.
Checked on every change
Automated secret detection and infrastructure template validation run against every proposed change before it can be merged.
In the inbox
The day-to-day, without the sharp edges.
Many domains, one view
Run several brands or client domains side by side, filtered to one or viewed together.
Open, archived, held, trash
Delete is reversible and moves to a Trash tab. Deleting the message you are reading opens the next one, so a backlog clears without a click between each.
CC tracked per message
A reply that added or dropped someone shows its own list, so who saw what is never a guess.
Rich text, files, contacts
Formatted replies, attachments, a contact picker, saved drafts and reusable templates.
AI drafting with a review step
Draft a reply from thread context, and pass it through a review before sending. Skipping the review is an explicit, deliberate choice.
Works on a phone
The list and reading pane adapt to a single column, so triage away from a desk is a real option.
Worth a conversation?
The platform is in production use today. If you are weighing a shared inbox and residency, auditability or delivery honesty are what make the decision hard, those are the parts we have already done the work on — and the parts we are happy to be interrogated about.