comms-blast

Comms blast

There is no unsend. An email that has been accepted by a receiving mail server is gone in a way a database row never is: it is on someone's phone, at 6am, and no amount of access to your own systems retrieves it.

A COMMS_BLAST change always carries a SCOPE certificate, and the exclusion list is the part that matters. Anyone can produce a list of recipients. The evidence that the send is safe is the list of people you deliberately did not write to, and why.

---

1. The audience is people, not addresses

Deduplicate by person, then by address, in that order. The failure otherwise is mundane and awful: one customer with three addresses on the account receives the apology three times, which reads as a second incident.

-- count what the policy ceiling actually measures
SELECT count(DISTINCT user_id)  AS people,
       count(DISTINCT lower(trim(email))) AS addresses
  FROM audience;

Report both. If addresses materially exceeds people, say so — it means the send is larger than the incident.

Normalise before comparing: lowercase, trim, and treat Gmail dots and +tags as the same mailbox for deduplication purposes only. Never rewrite a stored address to a normalised form; normalise for comparison and send to what the customer gave you.

---

2. Suppression is not optional and not one list

Four separate exclusions. Check each, count each, report each.

Exclusion	Why	Consequence of getting it wrong
Global unsubscribe	They asked you to stop	Unlawful under PECR/CAN-SPAM; also the reason they unsubscribed
Topic-level unsubscribe	They opted out of this category	Same, and harder to defend because you had the preference
Hard bounces in the last 30 days	The mailbox does not exist	Damages the sending domain's reputation for every other message
Spam complaints	They marked you as spam	Repeat sends to complainers is the fastest route to a blocklist

Plus one that is easy to forget and worst to get wrong: