Because they are not in the business of filtering spam they are in the business of receiving and delivering messages. The spam filtering outbound is to protect their own core service. Running spam protection for your own service is a lot different to offering spam protection for customers.

If you're going to hold people responsible for meeting a metric, you need to ensure they have a way of measuring the thing in question. To do otherwise is unreasonable by definition. If Twilio's definition of "sending spam" matched the OP's, where it's about sending messages the user did not agree to receive, then that would be reasonable. But instead it's something more intangible.

And like you say, they do need to prevent their system being used for sending spam. But if they're not going to provide a way for honest parties to avoid sending spam, they need to be reasonable about how they react to spam reports.

Exactly. Also I should point out that we weren't sending spam. It's just relaying the messages that we receive internally.

I would think sending spam would be more if we allowed people to sign up for a our service and then people used it to send spam.

But these are all internal communications.

You weren't sending spam just relaying is saying the same thing. Otherwise you could spam yourself and use that to send messages to a group of phones who could do the same thing. See the problem? I'm sure if this was a feature it was already exploited and patched.

Do you not see how spam protection for customers IS spam protection for your own service?

They already detect outgoing spam. Good customer service in this case would be to detect that a customer is attempting to send spam and blocking it and potentially notifying them about it.

Someone sending 50 maybe 100s of spam messages at the same time is going to get anyome automatically shutoff.

Sending one and the system might not have detected the spam. It's not visiting the link. But send many at once the system gets curious.