We built an email gateway that NEVER blocks

Our email wasn't arriving. And the culprit was a dot.

In late July 2026 we were setting up company mail: six aliases on @byit.pl (info, kontakt, biuro, faktury, ksiegowosc, admin), Cloudflare Email Routing, then a worker, then a Gmail inbox. All our communication — clients, our accountant, government offices — was supposed to flow through that one pipe.

It didn't.

The reason? A forwarding address typed without a dot. Gmail treats "[email protected]" and "[email protected]" as the same mailbox — dots in the name mean nothing to it. Cloudflare verifies addresses character by character. No dot, no verification, no forwarding. [to be confirmed by Kamil: how did you catch it — a test message? how long did it take?]

One dot. The whole mailbox.

In the previous post I promised this story has a second layer. It does. And I think that dot is what settled the decision that stuck with us: our email gateway never blocks.

What "never" means

Fail-open. A system that stays open when something breaks, instead of slamming shut.

Before we changed it, the gateway worked like a classic guard: something suspicious — reject. An error — reject. Worker down — reject. Makes sense, right? Except "reject" in email terms means: the message disappears. The sender gets an error, and you get nothing. You don't even get a chance to see that something passed you by.

We flipped it. The whole philosophy fits in one config line: REJECT_ON_BLOCK=false.

Now a "blocked" email doesn't bounce back to the sender. It lands in the inbox — with a label. Spam (threshold 0.75)? You get it, with a header that says "this looks like spam". Something that failed the compliance gate (threshold 0.70)? Also delivered, flagged. The worker crashes, classification fails, the model goes silent? The email goes through, raw, with a note about what happened. The only case where a message doesn't arrive is when it physically cannot be sent.

Why we did it

Do the math.

Spam costs five seconds: delete. A lost invoice costs a deadline, a fine, a client. Sometimes all three at once. A small company doesn't drown in spam — it drowns in the fear of spam, which makes it block everything in sight. And then it turns out it blocked something that mattered. Sorting can be redone. Losing — can't.

One place where we do block

I'd be dishonest if I said we never reject anything. We do: catch-all is set to drop. Mail to an address that doesn't exist — a typo, a bot guessing mailbox names — disappears.

But that's a decision, not a failure mode. Narrow, deliberate, reversible. Blocking is fine when it's a decision, not the default behavior of a scared system. The difference: a decision can be changed in an hour. Fear — can't.

A system that stays quiet

We also watch the worker from the outside: every 30 minutes we ping the /health endpoint and ask "are you alive?". If it answers — silence. If it doesn't — an alert. [to be confirmed by Kamil: has the watchdog caught anything since July?]

Seems like a detail. It's probably the core of it. A system that screams for no reason stops being listened to. Then it screams when it really matters — and nobody reacts. Silence is part of the design, not a gap.

What it taught us

We stopped asking "is this safe?". We started asking "what happens when this fails?". That question changes everything. Security stops being a wall and becomes a guarantee that nothing important disappears. A wall also stops the things that matter. A guarantee — doesn't.

I'm not sure this approach makes sense for every company. With an inbox that gets a thousand messages a day, you probably need stricter thresholds and filters on the receiving side. But I think the direction holds: design the system so that failure costs the least. Not so that failure never happens — because it will.

Next week: our deadline manager stays silent when there's nothing to do. Because a system that screams for no reason… well, you know.