A sign-up email lands in some recipients' junk folder. What can an automated check honestly assert about that?

## Who owns the verdict Whether a message reaches the main folder or the junk folder is decided by the receiving side, using inputs the sending team can neither see nor reproduce. Those inputs fall into three groups: - **Sender history** - the accumulated record of the identity the message came from, which the message itself cannot change. - **Content signals** - the structure of the message, where its links point, how much of it is image rather than text, how closely it resembles other mail the receiver has recently classified. - **Recipient signals** - what this particular person has previously opened, moved, or marked as unwanted, and what rules they have configured. The third group alone guarantees that two recipients of a byte-identical message can get two different outcomes. That is not a flaw to engineer around; it is what the feature is for. ## Why the verdict makes a bad oracle An assertion is worth writing when its result has a stable relationship to the change under test. "The message was not filed as unwanted" has no such relationship: | Property a good oracle needs | What the classification verdict does | | --- | --- | | Deterministic for a fixed input | Varies by recipient and by the receiver's current model | | Changes only when the code changes | Changes when the sender's record moves, or when the receiving side retrains | | Reproducible locally | Requires real receiving systems and real elapsed history | | Actionable when red | Says nothing about which property to fix | A check like that eventually goes red on a branch that touched nothing relevant. The team then does the predictable thing - re-runs it, then adds a tolerance, then ignores it - and the signal is lost anyway, having first cost a week of build confidence. ## What you can assert The useful move is to stop asserting the outcome and start asserting the **inputs you own**. These are deterministic, cheap, and each one maps to a real reason a message gets filtered: | Assertion | Why filtering weighs it | | --- | --- | | Every link resolves and its host is a domain the organisation owns | A mismatch between the claimed sender and the click destination is a strong unwanted-mail signal | | A text alternative is present beside the rich body | Rich-only messages resemble bulk mail and are treated accordingly | | The message is not a single image with no readable text | Image-only bodies are a long-standing evasion pattern | | An unsubscribe path exists and resolves, on message types that require one | Its absence on promotional mail is both a compliance and a filtering problem | | The visible sender address is the one the product is supposed to use | Sending as an unexpected address invites both complaints and refusals | | The body carries no tracking host belonging to a third party the product does not advertise | Redirectors inherit the reputation of everyone else using them | Each of these fails loudly, points at one line to fix, and never fails because a receiving system changed its mind overnight. ## Where the placement signal does belong The verdict is still worth knowing - it is simply not a build gate. The usual arrangement: 1. **Seed a small panel of real mailboxes** across several receiving systems, and send each of them the current rendering of the message types that matter on a schedule. 2. **Record the placement** for each, over time, as a trend rather than a pass or fail. 3. **Give it an owner** who is not the feature team, since most of what moves it is the sending identity's record rather than the copy. 4. **Set a review trigger**, not a build failure - a sustained drop across several receivers is worth investigating; one receiver moving one message for one day is noise. ## Reading a drop when it happens When placement really does fall, the first question is whether the cause is content or sender, because they have different owners and different fixes. Two clues separate them: - **Content causes are message-specific.** One template drops while the others hold, and the change correlates with an edit to that template - a new link host, a new image-heavy layout, a subject that reads like promotion. - **Sender causes are indiscriminate.** Every message type drops together across several receiving systems at once, with no content change behind it, and the sending identity's own bounce or complaint numbers moved first. That distinction is why the deterministic assertions above earn their place even though they never assert the verdict: when the drop is content-shaped, they name the property that changed; and when they all still pass, they are the evidence that the cause lies with the sending identity instead. The suite's job is to make the message defensible, not to guess what a classifier will do with it.