tmailrFor developers
When two safety checks hide each other
31 July 2026 · 2 min read · TMailr
This one is specific enough to sound like it could not happen to you, and general enough that it certainly can. It cost the better part of a night, and the shape of it turns up anywhere two systems both have a say in the same decision.
The setup
Our mail edge decides whether to accept a recipient in two places. There is a policy hook, an HTTP call the mail server makes during the SMTP conversation, which answers accept or reject. And there is the mail server’s own configuration, which independently decides whether it is willing to relay for that domain.
Both have to say yes. Either can say no. That is a reasonable design: the hook holds the logic that changes, the configuration holds the coarse rules. The trouble is what it does to testing.
The symptom
Mail to a customer’s own domain was refused. The hook was clearly correct, and we could prove it: send an address the hook should reject and it was rejected with our wording, send one it should accept and the hook logged an accept. The hook worked.
The mail was still refused, with a message that looked like ours.
Why the testing did not find it
Every test used addresses that did not exist. Those are refused at the first gate, which is the hook, and the second gate is never consulted. The tests exercised one gate and reported on the system.
The second gate only matters for a recipient the first gate accepts, which is precisely the case nobody had a convenient test for, because setting one up means a real domain in a real configuration. So the one path where the two gates could disagree was the one path never walked.
The bit that wasted the most time
The rejection message read like ours. We spent a long stretch reading our own code trying to work out which branch produced it, because we recognised the words.
One grep settled it: the phrase existed in our source, so the message really was ours in the sense that we had written it somewhere, but the refusal in front of us came from the other gate saying something similar. Two systems refusing the same thing with almost the same words is a genuinely nasty coincidence, and it is not as unlikely as it sounds, because both were written by people describing the same event in the same vocabulary.
What we changed
- A reconciler keeps the configuration side in step, on a timer, because a rule kept in two places by hand will drift.
- The test now uses an address the first gate accepts, so it reaches the second gate at all.
- Refusals from each side are worded distinctly, so the message identifies who refused.
The general version
Wherever two components can independently veto the same decision, your tests will naturally exercise whichever one fires first, and will report success or failure for the whole system on that basis. The second veto is invisible until something reaches it.
The questions worth asking of any such arrangement: which gate answers first, is there a test that gets past it, and can you tell from the response which one refused? If the answer to the last one is no, you will spend an evening reading the wrong code, recognising your own words in somebody else’s error.
More on for developers
