Unthought.

Messaging, consent and opt-out

The area where a technically flawless implementation can still be unlawful, so the requirement is part of the specification.

Messaging automation is where a technically flawless implementation can still be unlawful. The code sends what it was told to send, to the list it was handed, and not one of the questions that decide legality — how consent was obtained, whether it remains current, whether an unsubscribe has been honored everywhere — is visible anywhere inside it.

Consent is stored as data, not assumed from the existence of a contact record: when it was given, through what mechanism, and the exact wording shown at the time. A claim that somebody opted in is worth precisely as much as the record standing behind it, and the moment that record is needed is the moment somebody is disputing it.

Opt-out is checked against a single suppression list at the point of sending. The characteristic failure is a person unsubscribing in one platform and continuing to receive from another because every system holds its own copy of the list, and each one is individually behaving correctly.

Suppression is evaluated at send time rather than when the list was assembled. A list built on Monday and sent on Thursday will message everyone who opted out on Tuesday, and the gap between assembly and delivery is invisible in the sending platform's own reporting.

Channel requirements are handled separately rather than generically, because they differ: identification of the sender, a working unsubscribe mechanism, quiet hours where they apply, and the boundary between transactional and promotional content. A single promotional line inside an otherwise transactional message can reclassify the entire message and the obligations that attach to it.

Transactional automations are therefore scoped narrowly and defended against well-meant additions. An appointment reminder carrying an offer has stopped being an appointment reminder, and the person who added the offer will not be the person who has to account for it.

Sending is rate-limited and volume-capped as a safety property instead of for deliverability. A loop that sends is the most damaging defect available here, because unlike almost every other failure it cannot be undone — the messages have arrived, and the remedy is an apology, not a fix.

Non-production environments cannot reach real people, and the guarantee is structural rather than procedural: outbound messaging in any environment that is not production routes to a sink. A rule that depends on somebody remembering to point the test at a safe address is a rule that holds until the first busy afternoon.

Bounces, complaints and delivery failures are recorded against the contact rather than discarded. A rising complaint rate is simultaneously a deliverability problem and a consent problem, and the two have the same root cause often enough that treating it only as the former is how a sending reputation degrades quietly.

Exclusions

What this does not cover.

  • Unsolicited outbound messaging, and any sending program without a working, honored opt-out.
  • Purchased or scraped contact lists.
  • Promotional content inserted into transactional messages.