Inboxes
An Inbox is an email address Kiln watches. Mail arrives, and if it is from somebody you trust, a flow decides what it means and a case opens from it.
A great many real processes still begin with something landing in a mailbox, and this is how that becomes a process rather than somebody’s morning.
What you declare
Section titled “What you declare”An Inbox is a document you author, per tenant. It is not something we configure for you on a deploy, which matters because the list of who you trust changes more often than software does.
Four things:
Which sender domains you trust. The list that decides whether a message is even looked at.
A classifier flow, which reads an accepted message and says what it is.
A flow to run once a case has opened from one.
A prefix, stamped on a message before classification, so the same message arriving twice does not become two cases.
The two flows can be left unset, and unset is honest rather than broken: an Inbox with no classifier accepts mail and leaves it on file.
How a message is trusted, in the order it happens
Section titled “How a message is trusted, in the order it happens”First, alignment. The domain the message claims to be from must be the same domain the receiving mail server recorded a signature pass for. Not a signature from anywhere, a signature from the domain in the From line.
That is the check that makes a trust list mean anything. Without it, anyone could write your supplier’s address in the From field and be believed. A message that fails alignment is refused before any Inbox is consulted at all, so an unaligned message never reaches your configuration, let alone your flows.
Second, trust. Alignment only says the message really is from the domain it claims. Whether that domain is one of yours to care about is your declaration, and if no published Inbox trusts it, the message is refused.
Third, classification. Your classifier flow reads the message and says what it is. If it answers with nothing, the message stays on file and no case opens. The ingest does not guess a shape from a message it was not told how to read.
Then a case opens, and your on-opened flow runs.
Every message ends in one of six states, and you can see which
Section titled “Every message ends in one of six states, and you can see which”Not a log to interpret. Six named outcomes:
| Outcome | What happened |
|---|---|
| Refused, not aligned | The From domain and the signing domain did not match, or nothing was signed |
| Refused, not trusted | Aligned, but no Inbox trusts that domain |
| Left on file | Accepted, but this Inbox has no classifier authored |
| Refused, classifier said nothing | The classifier ran and returned nothing to act on |
| Failed to open | Trusted and classified, but opening the case was refused |
| Opened | A case exists |
This is the surface that answers “where did my email go”, which is otherwise one of the worst questions in any system. The answer is a row, not an investigation.
What is kept, and for how long
Section titled “What is kept, and for how long”Arrival records last thirty days and then expire.
The reasoning is worth knowing because it is the opposite of the usual instinct. Anybody on the internet can send mail to the address, so a refusal record contains a sender domain that a stranger chose. That makes this a debugging window for finding a misconfigured trust list, not a ledger of what happened. Keeping hostile input longer serves no reader.
Arrival records never contain a subject or a body. Those are attacker controlled free text and are exactly where a person’s name or address would land, so they are not copied into anything permanent. The record says which Inbox, which domain, when, and what happened.
The message itself stays where it arrived, and what the platform keeps is a reference to it. Somebody with access to that drive can read the message; the audit trail cannot leak it, because it never held it.
Setting one up without being surprised
Section titled “Setting one up without being surprised”Start with the trust list, because everything else is downstream of it. A domain you have not listed is refused, and the refusal is visible, so an empty list fails in the way you want rather than accepting everything.
Then leave the classifier unset for a while and watch what arrives. Mail lands, the arrivals list fills, nothing opens. That is a deliberate configuration rather than a broken one, and it is the cheapest way to see what real traffic looks like before writing a flow that acts on it.
Then author the classifier, and the same messages start becoming cases.
What it is not
Section titled “What it is not”It is not a mailbox. Nobody reads mail here, there are no folders, and there is no reply. An Inbox is an intake point.
It is not the way a system integrates with you. If the sender is a system rather than a person, an App client is a better answer: it authenticates rather than being trusted by domain, and its authority is a grant rather than an inference from an address.