2026-09-25

Suppressions you import, spam complaints and abuse reports stay until you remove them

A deliverable verdict now clears only an email suppression entry a verdict added, and imports on the email, phone and postal lists stay until you remove them and never go stale: no lookup or report clears one, and importing an entry that is already listed makes it yours. A spam complaint, a phone opt-out and a phone abuse report now stay until you remove them too, on an entry you imported as well. Plus a phone fix for drama numbers in batch, bulk and monitor runs, and a closer note on time zones.

A lookup no longer clears what you put on the list. A recovered verdict used to remove an email suppression entry whoever added it, so an address you had imported, or one a complaint had put there, came off the list the next time it was verified afresh: a single lookup, the MCP tool, a visitor typing it into the form on your site, or a batch, bulk or monitor run once the entry was more than 90 days old. A verdict that is not undeliverable now clears only an entry an earlier undeliverable verdict added. Imports stay until you remove them, and an entry a bounce report added stays until you remove it or report a delivery to that address.
An undeliverable verdict no longer relabels your entries. It used to rewrite an imported or reported entry as an automatic one, which the next recovered verdict would then clear. It now only renews the entry, which keeps a bounce report's entry past the 90-day staleness check, and leaves its source and reason as they were.
Importing an address already on the list makes it yours. It keeps the verdict stored with it and is counted as already_suppressed, as before, but becomes an import, so no later lookup or delivery report takes it off. Importing an address again is harmless and never needed to keep it listed.
Stale entries are still re-checked, imports never. Batch, bulk and monitor runs still verify an entry a verdict or a bounce report added afresh once it is untouched for 90 days, instead of trusting it. An import is never stale, on any of the three lists, and is served for as long as it is listed. A verdict or lookup answer an import kept from before you imported it is a measurement, though, and nothing measures an import again: it is served for 90 days after the entry was last renewed, and after that the import answers suppressed like any other, so an answer months old is never repeated as today's.
Phone and postal imports work the same way. Importing a number or an address that a lookup or your own reports already put on the list keeps its reason, and any stored answer, but makes it an import, so a later valid lookup, delivery or verified report no longer takes it off. And a moved, refused or returned report about a postal address you imported no longer takes it over: it used to relabel the entry as a report, which the next delivery report then cleared.
A spam complaint stays until you remove it. A complaint is the recipient's objection, not a fact about the mailbox, so it is now treated like an import. A later delivery report no longer clears it, a later bounce report no longer relabels it as a bounce (which a delivery then cleared), a complaint reported beside a bounce in one batch wins whichever comes first, and it never goes stale, so batch, bulk and monitor runs keep serving it after 90 days instead of re-verifying the address. An erasure request from the address itself keeps it as well, as it keeps a phone number's opt-out, because deleting it would put the address back in front of your next campaign; the privacy policy and the trust page say so.
A phone abuse report stays until you remove it. An abused report puts the number on your phone suppression list with reason abuse, and that entry used to leave once the report was more than 90 days old and a delivery was reported after it — or it was relabelled undelivered by later failures, which a delivery then cleared. Now no delivery, verification, failure or lookup clears or relabels it, and it never goes stale, so batch, bulk and monitor runs keep serving it. The reported_abuse risk signal on a single lookup still counts reports from the last 90 days, as before.
Removing an abuse entry sticks. Only an abused report in the feedback call that carries it now adds a number to the list with reason abuse, as only an opt-out in the call adds an opt-out. A removed abuse entry used to come back with the number's next report of any kind — delivered or undelivered — while the old abuse report was still inside its 90 days. A later delivered, verified or undelivered report no longer brings it back as an abuse entry; only a new abuse report does (an opt-out, or failures that would suppress any number, still add it with their own reason).
An opt-out, abuse report or complaint about an entry you imported is kept. An email complaint used to leave an imported entry exactly as it was, so it still went stale 90 days after the import, and a phone abuse report turned an imported number into an entry of your own reports, which a later delivery could clear once the report was 90 days old. The report's reason — opted_out, abuse or complained — is now written onto the import, which stays an import: it never goes stale, meta.opted_out answers true, and an erasure keeps it. An opt-out still replaces an abuse reason, never the other way round. A report that justifies the entry without standing for good — a permanent failure, repeated failed deliveries, an email bounce, post reported moved, refused or returned — leaves an import's reason alone, and a delivery or verification still never clears an import. A report that says nothing against the number or the address — a failure your SMS provider puts on the sender's side, or a late delivery receipt dated before the failures — renews nothing and never puts back an entry you removed. An import never goes stale, on any of the three lists.
Drama numbers stop answering unassigned in batch, bulk and monitor runs. Before Ofcom's drama ranges answered valid where Ofcom's own table lists the block as protected, a lookup of such a number — 020 7946 0018 was the documented example — put it on your phone suppression list as unassigned_block, and batch, bulk and monitor runs kept serving that stored answer. Such an entry is now removed the next time a run meets it, and the number is looked up afresh: valid, with is_fictional true.
Time zones, precisely. Round four's note that timezones names the zones of the number's own country holds wherever the time-zone database files a zone under that country: a Palestinian number answers Asia/Gaza and Asia/Hebron rather than the Europe/Bucharest the numbering data gives, whose daylight-saving dates differ. The database files none under Kosovo, Ascension Island or Tristan da Cunha, so their numbers answer the zone the numbering data gives, Europe/Belgrade or Atlantic/St_Helena, which keeps the same clock.

markdown version: /changelog/2026-09-25-email-suppressions-stay-yours.md · atom feed: /changelog.atom

All releases