An inbox does not have one address, it has infinitely many

An inbox does not receive on one address: it receives on a whole domain.

anything@<inbox-identifier>.inbox.facteur.eu

Everything before the at sign is yours. qa@, customer-42@, signup+3f9a@, signup-2026-08-07@: all four land in the same inbox, and every message keeps the exact address it was sent to, in its to field.

Why this is the property that matters

A test suite running in parallel has a problem before it has a tool: two concurrent runs sign two accounts up, and both confirmation emails land in the same place. You then have to guess which one is yours — by subject, by timestamp, by a sleep.

With a unique local part per run, the question disappears:

signup+<run-id>@ab12cd34.inbox.facteur.eu

Each test reads its own message by filtering on to, with no ordering, no arbitrary wait, and no inbox to create and tear down every time.

What the ingester accepts, and what it refuses

Case	Answer
Known inbox, quota available	Accepted, stored, parsed
Unknown inbox	SMTP 550 — no inbox is ever created on the fly
Monthly quota exceeded	SMTP 5.7.x, and the message is neither stored nor parsed
Recipient outside the inbox domain	Refused: we relay nothing

We are not a relay. A server that accepts mail for a recipient it does not know ends up on blocklists, and takes every customer’s reception down with it. The refusal is therefore blunt and immediate.

The inbox domain is separate from the product domain

Inboxes live under inbox.facteur.eu, never under the site’s domain. This is deliberate: the sender reputation of a domain that receives test mail has nothing to do with the one that sends our own email, and mixing them would make each depend on the other.

How many inboxes

That is a plan limit, counted per organization rather than per workspace — see quotas-et-retention. Subaddressing exists precisely so that this limit rarely gets in the way: one inbox per test suite is almost always enough, and runs are told apart by the local part.