Guardivia

SMS Firewall

How does an SMS firewall work?

Reviewed 2026-09-12 by the Guardivia QoS Engineering Team

In short

An SMS firewall inspects messaging traffic using network, protocol, sender, destination, content, routing and behavioural information. Based on operator-defined policies and traffic intelligence, messages can be allowed, blocked, rerouted, quarantined, modified where authorised, or flagged for investigation. Each decision is logged with a reason code for audit and revenue reconciliation.

The inspection dimensions

A single dimension is rarely conclusive. Detection quality comes from correlating several at once, because legitimate traffic and bypass traffic often differ on only one or two axes:

  • Message content, including multilingual text and embedded URLs
  • Sender ID, source address and destination address
  • Prefix, country and destination operator
  • Global Title and the routing path the message took
  • Client account and ESME system ID for application traffic
  • Submission velocity, volume and destination spread over time
  • Geographic pattern and the historical behaviour of that source
  • Delivery receipts, HLR and SRI-SM results, and number-portability data
  • An AI risk score, plus any explicit rule or profile matches

Classification before decision

Before policy can apply, the message has to be classified. Traffic is separated into A2P, P2P, P2A and M2P; then into purpose — OTP, transactional, service, promotional, advertising, political or personal; then into a risk category such as legitimate, suspicious, spam, smishing, fraudulent or prohibited.

Classification matters commercially as much as it does for security. An operator's rate card usually distinguishes OTP from promotional traffic, and its regulator may distinguish political content from commercial content. The classifier is what makes those distinctions enforceable.

The decision and its outcomes

Operator policy determines what happens next. The range of outcomes is deliberately wider than allow or block, because most real policy questions are not binary:

  • Allow — forward to the SMSC for normal delivery
  • Tag — deliver but mark for analytics, useful during monitoring mode
  • Rate-limit — throttle a source to a policy-compliant throughput
  • Quarantine — hold for analyst review rather than discarding evidence
  • Block or drop — reject, with a reason code recorded
  • Redirect or reroute — send commercial traffic over the authorised, billable route
  • Force Sender ID — normalise the sender to a registered value where policy permits

Monitoring mode comes first

No responsible deployment starts by blocking. The platform runs in monitoring and learning mode, establishes baselines per route, sender, account and time of day, and proposes classifications and thresholds with supporting evidence.

An authorised engineer reviews those proposals before enforcement changes. That sequence protects both the subscriber experience and the operator's aggregator relationships — and it produces the traffic baseline that later proves what the deployment actually changed.

Discuss this with the engineers who build the platform

Questions about how this applies to your network go straight to the QoS Engineering Team.