That does sound like there's an exploitable element there isn't it?

Statistically speaking, most people use one of the biggest email providers, which use their own models to detect spam (or even quietly drop messages). If you're doing an unpopular TOS change, why not set the mail up to still be RFC compliant but in such a way where the mail isn't going to be allowed through by any of the providers. Then you can just claim the problem is userside.

For example, the Message-ID header is technically not required (SHOULD rather than MUST), but as a spam detection measure, Gmail just drops the message entirely for workspace domains: https://news.ycombinator.com/item?id=46989217