An SMS firewall should not be treated as another box added to the network.
It sits at a critical point between external messaging traffic and subscribers. Deploy it incorrectly and legitimate A2P messages may be blocked. Deploy it too loosely and grey routes, spoofed traffic and scams continue getting through.
GSMA maintains dedicated SMS Firewall Best Practices and Policies guidance for operators, covering firewall policies and responses to SMS security breaches.
Here is a practical deployment path.
Step 1: Map every route into your SMS network
Before writing firewall rules, identify how SMS traffic currently enters and leaves the network.
Map:
- international SS7/SIGTRAN connections
- SMPP connections
- SMS aggregators
- enterprise messaging connections
- roaming partners
- domestic interconnects
- other SMSCs
- internal applications
Do not assume all A2P traffic is already coming through the routes your commercial team expects.
GSMA notes that billable A2P SMS can become difficult to see when traffic travels through unconventional routes or unmonitored SS7 connections, including cases where A2P traffic is disguised as P2P.
You need the baseline before you can identify the bypass.
Step 2: Decide what the firewall needs to stop
“Block fraudulent SMS” is too broad to be a useful policy.
Define the specific traffic you need to identify.
This can include:
- grey-route A2P traffic
- sender ID spoofing
- spam
- smishing and malicious URLs
- SIM-box traffic
- artificially inflated traffic
- abnormal international traffic
- unauthorized enterprise routes
Different threats need different detection methods. A sender rule that catches spoofing may do very little against an OTP pumping attack.
GSMA’s security library separates SMS bypass, artificial traffic inflation, firewall policy and signalling security into different areas for this reason.
Step 3: Put the firewall where it can see the traffic
The firewall needs visibility at the relevant network boundaries.
That usually means inspecting messaging traffic before it reaches core delivery systems and subscribers.
The exact architecture will depend on whether the operator is filtering SMPP, SS7/SIGTRAN or multiple traffic sources.
Do not deploy first and work out traffic flow later. Document which connections pass through the firewall, which do not and why.
This matters because an attacker only needs one unprotected path.
Step 4: Build rules from real traffic, not assumptions
Start with historical traffic.
Look at normal volumes by source, destination, sender, enterprise account and time period. Then identify what unusual behaviour actually looks like in your network.
Rules can consider signals such as:
- unexpected originating networks
- invalid or suspicious sender identities
- sudden traffic spikes
- repeated destinations
- unusual routing patterns
- known malicious URLs
- mismatches between expected and observed traffic
Do not immediately block every anomaly.
Run new rules in monitoring mode where possible, review false positives and tighten them before full enforcement.
Legitimate banking alerts or an enterprise campaign can also create a sudden spike.
Step 5: Test with the SMSC before going live
Blocking bad traffic is only half the job.
Legitimate traffic still needs to be routed and delivered correctly.
This is where firewall deployment has to be tested against the SMSC environment.
hSenid SMSC, for example, supports configurable routing rules with actions including relay and reanalysis. Its SMPP Gateway can connect to multiple SMSCs, support load balancing and manage traffic from ESMEs and SMPP clients.
Test what happens when traffic is:
- accepted
- rejected
- rerouted
- delayed
- retried
- sent during a traffic spike
Also verify CDRs and charging after the new traffic path is introduced.
hSenid SMSC supports real-time and offline charging and generates detailed CDRs in flexible formats for billing.
Step 6: Test for scale, not just functionality
A firewall that works during a controlled test can still become a bottleneck during an OTP burst or enterprise campaign.
At hSenid Mobile, our systems handle nearly 50 million transactions daily.
At that level of traffic, every new inspection or routing layer needs to be designed with capacity in mind.
hSenid SMSC includes overload protection that buffers excess capacity once traffic exceeds the configured Message Delivery Attempt level.
The current hSenid SMSC architecture also uses clustering, internal load balancing and on-demand scaling to support high traffic availability.
Your firewall architecture needs the same capacity planning discipline.
Step 7: Measure what happens after deployment
Do not judge success only by the number of messages blocked.
Monitor:
- blocked traffic by reason
- false-positive rate
- A2P traffic moving to authorized routes
- changes in enterprise traffic
- scam and spam complaints
- delivery performance
- firewall processing latency
- revenue recovered from previously bypassed traffic
Keep reviewing the rules as traffic changes.
Fraudsters adapt. Enterprise behaviour changes. New aggregators connect. Static rules eventually become outdated.
A real example of why real-time filtering matters
Dialog Axiata handles around 30 million SMS messages on a typical day, including approximately 1.2 million containing URLs. In June 2026, the operator deployed network-level URL screening that checks links as messages move through the network and adds security warnings to messages containing scam links.
That is the level operators should think at: protection inside the messaging flow, not only after subscriber complaints arrive.
One important point before publishing this
The hSenid SMSC material reviewed for this article documents routing, SMPP connectivity, charging, overload protection and scalable SMS processing. It does not explicitly state that hSenid SMSC itself includes an SMS firewall or confirm a specific third-party SMS firewall integration.
So the firewall deployment guidance above should remain vendor-neutral unless that integration is confirmed internally.
An SMS firewall protects the network edge. The SMSC makes sure the legitimate traffic that passes through can still be routed, processed and delivered at scale.
