Esse tipo de coisa (spam snowshoe / hailstorm) é melhor detectado com o aprendizado de máquina. Certifique-se de que você está fazendo pleno uso de Bayes no SpamAssassin (ou seja, você deve treinar regularmente em spam e ham; autolearn não é suficiente).
A única coisa mais eficaz que fiz quando executei o e-mail de uma empresa foi devolver corretamente as rejeições de tempo de SMTP NO SUCH USER em usuários inexistentes. Isso reduzirá radicalmente o spam de remetentes que rastreiam as métricas de entregabilidade (alguns criminosos e um lote de profissionais de marketing sujos). Evidentemente, isso não vai ajudar muito em relação ao subtipo de snowshoe que você está sofrendo, mas pode aliviar outros problemas que você está tendo (ou você pode ser dependente de um curinga e, portanto, não pode considerar isso). Se você puder configurar o SpamAssassin para rejeitar mensagens no horário do SMTP, isso fornecerá o mesmo benefício para spam enviado com remetentes de rastreamento de rejeição.
Você mencionou nos comentários que tentou várias coisas, mas não Nolisting . Eu tive sucesso anedótico com a não-existência, mas teria sido um fardo extra para implementar alguma forma de medir seu impacto. Eu implementei o nolisting da maneira prescrita (um registro MX primário solitário que responde ao ping e tem a porta 25 fechada - mas não filtrada: deve ser uma rejeição rápida) e de maneira não padrão (que nolisting.org insiste deve ser chamado de outra coisa ): um registro MX de prioridade mais baixa que tenha a porta 25 filtrada (assim, o tempo limite expirará e, portanto, consumirá recursos de spam). (Medir isso exigiria colocar um servidor em pé apenas para contar as conexões e comparar esses registros com os logs do retransmissor de e-mail real para ver quantas mensagens não sobrevivem.)