Mail That Falls Through
Five connected accounts are tried in a fixed order before the platform sends anything itself, and a failure at any of them is not an error — it is a fall-through to the next. Which is a good design with one uncomfortable consequence worth naming.
There is a class of decision in software where two reasonable people will pick opposite answers and both be right, and the useful thing is not to argue but to say clearly which you picked. Here is one: when a message can be delivered by any of six routes and the first one fails, do you try the second, or do you stop and report the failure? We try the second. The reasoning is straightforward and the cost is real.
The order, and what each step decides
When an email is sent with a workspace and a category attached, five connected routes are offered it in a fixed order, and the first one that succeeds ends the search.
-
Your own Google mailbox
A workspace connector sending as a real person's mailbox. First because it is the most identifiably yours.
-
Your own Microsoft mailbox
The same arrangement on the other side of the office-software divide.
-
Your first bulk provider account
A dedicated transactional sending account rather than a mailbox.
-
Your second bulk provider account
Same again, different provider.
-
Your third bulk provider account
And again.
-
The platform's own sending
What happens when none of the above took it — including when one of them tried and failed.
Most workspaces have one of the five configured, so in practice this is a single check that succeeds and four that are skipped instantly. The order only matters to somebody who has connected more than one, and there it is a stated precedence rather than a race.
Three reasons a step is skipped, and they are indistinguishable
This is the design decision, stated exactly.
Each step answers either I sent it or not me. And not me covers three quite different situations:
| Situation | What it means | What the chain does |
|---|---|---|
| No connector configured | You never asked for this route | Move on — correct and expected |
| Category not enabled | You asked for other mail here, not this | Move on — correct and expected |
| The send was attempted and failed | Something is wrong with that route | Move on — and this is the interesting one |
A failed send and an unconfigured connector produce the same answer, and the mail goes out either way.
Why that is the right way round
Because of what the mail is. A purchase order that does not reach a supplier is not a notification somebody missed — it is a commercial document that a business decision is waiting on. An invoice that does not reach a customer is money not collected.
And because of what the failure usually is. A workspace email connector fails for ordinary, temporary, unglamorous reasons: an expired credential, a provider rate limit, a domain verification that lapsed, a mailbox over quota. All of those are somebody's afternoon to fix and none of them should mean an invoice does not go out.
The alternative — stop and report — treats the choice of sending account as more important than the mail arriving. A preference about which envelope it goes in should not be able to stop the letter.
And the uncomfortable half
A workspace connector that has quietly stopped working produces mail that still arrives, from a different address, with nothing on any screen saying so.
That is a real cost and it deserves to be stated rather than buried. Somebody who connected their own domain in March so that invoices would come from their finance address might be sending from the platform in June without knowing, because the invoices kept arriving and nobody reported anything.
Two things bound it. The failure is logged with its reason at the moment it happens, so there is a record rather than nothing. And the connection test on the settings screen sends a real message through the same path — so the question is this still working has a definite answer available in about ten seconds.
The honest summary is: the design prefers the mail arriving over the routing being observed, and the routing being observed is something you check rather than something that interrupts you. Reasonable people would order those differently. This is the order we picked, and it is picked for the mail rather than for the configuration.
Two things that stop mail before the chain begins
Both are suppressions rather than failures, and both are worth knowing because they look like a broken connector and are not.
The first is the test environment. Mail is never actually sent from a test run; it is recorded with a summary of what it would have been. That is the difference between a test suite and an incident involving several hundred suppliers.
The second is a blocked recipient list. Certain recipient domains are refused before any provider is chosen, and the refused addresses are logged by name. It exists so that a fixture, a seeded dataset or an example address cannot cause real mail to real strangers.
Both are recorded as suppressed rather than as sent or failed — a third outcome, distinct from both, because collapsing it into either would be a lie in one direction or the other.
What is in place, layer by layer
How an email finds a route
A fixed, stated precedence
Five connected routes in a defined order, then the platform. Not a race and not a rotation — a precedence you can read.
Fall-through on a miss
A route with no connector or with this category switched off simply declines, which is the ordinary case for four of the five.
Fall-through on a failure
A route that tried and failed also declines, so an expired credential delays nothing and loses nothing.
The reason logged at the point of failure
A failing route records why before the chain moves on, so a connector that has stopped working leaves a trail rather than nothing.
A test that proves a route end to end
The connection test sends a real message through the same path, so whether a connector is currently working is a ten-second question.
Test runs suppressed entirely
No mail leaves a test environment; what would have been sent is recorded instead.
A blocked recipient list, checked first
Certain recipient domains are refused before any provider is chosen, with the addresses logged, so fixtures and examples cannot reach real people.
Suppressed as its own outcome
Not sent and not failed but deliberately withheld, recorded as a third result rather than collapsed into either.
A default reply-to applied first
Set before any routing decision, so a reply reaches the right place whichever account ultimately sends.
The cost of this design is stated plainly: a connector that has quietly stopped working produces mail that still arrives from elsewhere. The reason is logged and the test is quick, and the trade is deliberate.
Three positions held on purpose
- The mail matters more than the route. A purchase order is a commercial document somebody is waiting on, and a preference about which account sends it should not be able to stop it.
- The cost of that is named rather than buried. A workspace whose connector has failed is sending from the platform without a banner saying so, and anybody relying on their own domain should know that is how it behaves.
- Suppressed is its own outcome. A message withheld deliberately is neither sent nor failed, and recording it as either would misreport what happened in one direction or the other.
Five questions about email routing
What if our sending account fails?
A good answer sounds like
The mail still goes.
What ours actually is
The chain falls through to the next route and ultimately to the platform. Nothing is lost or delayed.
Would we know?
A good answer sounds like
An honest answer.
What ours actually is
The reason is logged when it happens; there is no banner. The connection test answers it in ten seconds.
If we connect two accounts, which sends?
A good answer sounds like
A stated order.
What ours actually is
A fixed precedence, readable rather than a race or a rotation.
Can test data email real people?
A good answer sounds like
No.
What ours actually is
Test runs never send, and a blocked recipient list is checked before any provider is chosen.
Is a suppressed message reported as sent?
A good answer sounds like
No.
What ours actually is
It is a third outcome, distinct from both, because calling it either would be inaccurate.
Our take
Fall-through is one of those designs that is obviously correct for the failure it prevents and quietly awkward about the one it creates. Nobody wants an invoice held up because a credential expired. Nobody wants to discover in June that their own domain has not sent anything since March either. There is no arrangement that avoids both, so the useful thing is to pick deliberately, write down which you picked, and make the other one cheap to check. What is not acceptable is a system that falls through silently and never mentions it — which is the same design with the documentation left out, and it is by far the most common version.
Check the route, not just the mail
If it matters that invoices come from your domain, the connection test is a ten-second habit worth having on the calendar rather than the incident list.
Talk through email deliveryFrequently asked questions
If our email connector breaks, do invoices stop going out?
No. The route declines and the next one takes the message, ending with the platform's own sending. The mail arrives; what changes is the address it comes from. The failure is logged with its reason at the moment it happens.
How would we notice that we had fallen back?
The log records it, and the connection test on the settings screen sends a real message through the same path and reports what happened. There is no banner on the screen, which is a deliberate trade and worth knowing if sending from your own domain is important to you.
We have connected two accounts. Which one is used?
A fixed precedence rather than a race: personal mailboxes are offered the message before dedicated sending accounts. The first route that accepts it ends the search, and the order is stable rather than varying by message.
Could a test run email our real suppliers?
No. Mail is suppressed entirely in test environments — what would have been sent is recorded instead of delivered. Separately, a blocked recipient list is checked before any provider is chosen, so example and fixture addresses cannot reach real people even outside tests.
Does a suppressed message count as sent?
No, and it does not count as failed either. It is recorded as its own outcome, because a message deliberately withheld is a different thing from one that went and one that could not go, and reporting it as either would be inaccurate.
