Rejection Rules stop unwanted messages at the door. When one of your SMPP clients sends a submit_sm, the platform checks the sender ID and destination number against your rules. If they match, the request is refused in the submit_sm_resp, so the message is never queued, routed or sent to a vendor.

This matters for aggregators because anything that reaches a vendor costs you money and can risk the route. Blocking at submission is the cheapest place to stop it.

Where to find it

Sidebar → SMPP Server → Rejection Rules, then Manage SMPP Server Rejection Rules.

Create a rule

1. Click + (Add).
2. UserName: leave it as Universal to apply to all your SMPP clients, or pick one client.
3. Name: something descriptive, e.g. Block spoofed bank headers – client XYZ.
4. SenderName Match Criteria: exact match, starts with, ends with, contains, and more.
5. SenderName Details: comma-separated values.
6. Series Match Criteria and Series Details: the destination number patterns, comma-separated.
7. Status: ENABLED.
8. Click Save Changes.

Typical uses

Scenario	Rule
A client tries to send with a brand’s sender ID they aren’t authorised for	Client-specific, SenderName exact match on that header
Traffic to a destination range you have no route or licence for	Universal, Series starts with that prefix
Test/junk traffic hitting a known dummy range	Universal, Series starts with the range
A compromised client account pushing lookalike sender IDs	Client-specific, SenderName contains the brand string

Things to know

• SMPP traffic only. These rules act on submit_sm from clients binding to your SMPP server. For HTTP API and panel traffic, use Blocked Sender ID and Blocked Phone Numbers.
• Test every rule before relying on it. Send one matching and one non-matching message from a test SMPP account. Check that the first is refused, and that the client’s system logs the refusal as a submit error rather than a missing DLR.
• Tell the client when you block them. A rejected submit_sm can look like a platform fault to the client. A short email avoids a support escalation.
• Name rules so you know why they exist. Put the client, the reason and the date in the Name field so they can be audited later.

Related articles

• Types of SMPP Connects
• How to Troubleshoot When a Customer Is Unable to Connect to the Server
• Whitelisting Customer Originating IP
• Control Throttling over SMPP Connectivity