# SMS pumping by country: which destinations to allow, gate or block

> No public list ranks SMS pumping countries. How to sort destinations into allow, gate and block from published sources and your data, and which ranges to block.

Canonical: https://mobilevalidate.com/blog/sms-pumping-by-country · Last updated: 2026-11-03

![A table of country rows with verification-rate bars, one row low and marked as risk, sorting into three bins: allow with a check mark, gate with HLR and line-type checks, and block with a cross.](https://mobilevalidate.com/images/blog/sms-pumping-by-country.svg)

*Give every destination one tier, and check numbers before sending to gated ones.*


By MobileValidate team (https://mobilevalidate.com/about) · Published: 2026-11-03 · Category: Fraud prevention · Tags: SMS pumping, Irsf, OTP, Fraud prevention, Geo permissions, HLR lookup

No public, neutral list ranks countries by SMS pumping, and any list that claims to goes stale fast, because attackers move to wherever the payout is best this month. What you can do is sort every destination into three tiers: **allow** the countries where your customers are, **gate** the ones with some real users behind a line-type and live network check, and **block** the rest until you have a business reason. Build the tiers from your own verification rate and SMS cost per country, and use published provider lists as a cross-check.

This post is about choosing destinations. For how pumping works and the full layered checklist, read [SMS pumping: how it works and how to stop it](/blog/sms-pumping-how-it-works-and-how-to-stop-it).

## Which countries are most targeted by SMS pumping?

The honest answer, as of November 2026: nobody publishes a public, current, per-country ranking you could cite. Fraud volumes by destination are held by operators, messaging providers and fraud-control associations, and they share them with members, not the public. The Communications Fraud Control Association (CFCA), for example, says full results of its Fraud Loss Survey are available only to its members and the associations that took part, with a public summary for the media ([CFCA](https://cfca.org/fraud-loss-survey-2021/)).

What *is* public falls into three groups:

| Source | What it publishes | Country-level? |
|---|---|---|
| Microsoft Entra External ID documentation (page dated 17 April 2026) | 114 country codes on which SMS verification is switched off by default; an admin opts in per code | Yes: a default-off list |
| Microsoft Entra ID telephony fraud page (dated 28 July 2025) | A longer opt-in list for SMS and voice in workforce tenants, which also includes EU members such as Belgium, the Netherlands and Sweden | Yes: a default-off list |
| Google Identity Platform, "SMS regions" | Recommends allowing only the regions you plan to send to, and a verification rate check per region | No list; a method |
| Enea and Mobilesquared (February 2024) | An estimated 19.8 to 35.7 billion fraudulent A2P messages in 2023, 4.8% of traffic, $1.16 billion cost to brands | No: global |
| UK National Cyber Security Centre (November 2023) | Guidance on artificially inflated traffic (AIT) for anyone buying SMS | No |
| OWASP OAT-003 | Classifies SMS pumping and AIT as cost-inflation fraud | No |

Sources: [Microsoft External ID](https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-region-code-opt-in), [Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-regional-opt-in), [Google](https://docs.cloud.google.com/identity-platform/docs/admin/sms-regions), [Enea](https://enea.com/news/press-releases/a2p-messaging-under-threat-joint-report-by-enea-and-mobilesquared-reveals-20-billion-fraudulent-messages-sent-in-2023), [NCSC](https://www.ncsc.gov.uk/blog-post/ait-fraud-what-you-need-to-know), [OWASP](https://github.com/OWASP/www-project-automated-threats-to-web-applications/blob/master/assets/oats/EN/OAT-003_Cost-Inflation_Fraud.md).

Microsoft's External ID list is the most concrete public example. It spans every region: much of West and Central Africa (Nigeria, Ghana, Cameroon, Côte d'Ivoire, Senegal), South and Southeast Asia (Bangladesh, Pakistan, Sri Lanka, Indonesia, the Philippines, Vietnam), parts of the Middle East (Iraq, Jordan, Lebanon, Saudi Arabia, the UAE), Central Asia and the Caucasus, and many small Caribbean and Pacific states. Microsoft says it disallows these codes "to safeguard against telephony fraud", naming international revenue share fraud and traffic pumping that "often targets multifactor authentication systems".

Read such a list for what it is. It's one provider's default for its own traffic mix, not a fraud ranking, and it says nothing about how often a country is abused. A bank in Lagos would be wrong to switch off Nigeria. A US-only app would be wrong to leave on a country that isn't on anyone's list. The useful lesson is the method: off by default, on by decision.

## Why do fraudsters prefer some destinations?

Pumping pays when the attacker can collect part of the termination fee on each message (our [IRSF explainer](/blog/irsf-international-revenue-share-fraud) traces the money). Four things make a destination more attractive:

1. **A high price to terminate an A2P message there.** The more you pay per text, the more there is to share. Your own invoice by destination is the best source for this, because rates differ by provider and route.
2. **Number blocks that are easy to control in bulk.** Ranges assigned to international networks or to IoT and machine-to-machine services, and national ranges that aren't in use, can be pumped without real subscribers behind them.
3. **Long or opaque routes.** Each extra intermediary is another place where traffic can be inflated or diverted, and the [NCSC's guidance](https://www.ncsc.gov.uk/blog-post/ait-fraud-what-you-need-to-know) puts security first in how you buy SMS for that reason.
4. **Low normal traffic from your own users.** A destination where you send 20 codes a day hides nothing: 2,000 in an hour stands out. The danger is the destination you never look at, because the form accepts it and no one has an alert on it.

Microsoft's own description adds the attacker's playbook: register premium-rate numbers, drive automated requests to them, and "rotate across region codes to evade detection and maximize profits" ([Microsoft](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-regional-opt-in)). That rotation is why a fixed blocklist fails and a tiered allow-list holds.

## Should you block a whole country or gate it?

Use three tiers and give every country exactly one. The tiers come from your data, not from a list on the internet.

| Tier | Which countries | What happens on a code request |
|---|---|---|
| **Allow** | Your main markets: real customers, verification rate at your normal level | Send, with the standard limits per number, prefix, IP and session |
| **Gate** | Some real users, but a high SMS price, a weak verification rate, a past incident, or a code on your provider's default-off list | Check line type and live network status first; tighter per-prefix limits; a low hourly ceiling per country; offer another factor |
| **Block** | No customers and no business plan there; non-geographic codes; anything your own sanctions policy excludes | Send nothing; show "SMS isn't available for this country" and offer another method; manual exception only |

A simple way to place each country:

1. Export 90 days of codes sent, codes verified and SMS cost per country.
2. Countries with steady volume and a normal verification rate go to **allow**.
3. Countries with real but small volume, or a price well above your average, go to **gate**.
4. Everything with no meaningful legitimate volume goes to **block**. For most businesses that's the majority of the world's country codes, and that's fine.
5. Cross-check against your messaging or identity provider's geographic permissions. Where its default is off, don't switch it on without moving that country to **gate** at least.

Blocking a whole country you do serve is the expensive mistake. It turns away real users, and the attacker simply moves to the next destination. Gating keeps the door open for people while making each pumped message cost the attacker a failed check or a hit on a rate limit.

## Which number ranges are never valid for OTP?

Some ranges don't need a country decision at all, because a real user signing up with them is rare or the line can't receive a text. Block them by line type, in every tier:

| Range or line type | Why it doesn't get an SMS code |
|---|---|
| Premium rate (`premium_rate`) | Built to earn the number holder money; the classic revenue-share target |
| Shared cost (`shared_cost`) and universal access (`uan`) | Business service numbers, not personal phones |
| Personal numbers (`personal`) | "Follow-me" numbers that forward to another line and can carry a revenue share |
| Toll-free (`toll_free`), pager (`pager`), voicemail (`voicemail`) | Usually can't receive SMS; no reason to send one |
| Fixed lines (`fixed_line`) | Can't receive most SMS; offer a voice call or another method instead |
| +881 (global mobile satellite), +882 (international networks), +883 (IoT/M2M and other uses) | ITU shared codes that belong to no country ([ITU](https://www.itu.int/net/ITU-T/inrdb/e164_intlsharedcc.aspx)) |
| +979 (universal international premium rate) | Defined for premium-rate services across borders ([ITU-T E.169.2](https://www.itu.int/rec/T-REC-E.169.2/en)) |

Each country defines its own premium-rate and special ranges in its national numbering plan. The ITU collects them on its [national numbering plans](https://www.itu.int/oth/T0202.aspx?parent=T0202) page, but the plans change and the formats differ. A line-type lookup saves you from maintaining that table yourself. It isn't perfect: where no data exists, the answer is `unknown`, which should send the request back to your country-tier rules, not block it.

Satellite and IoT codes aren't always fraud. A shipping or offshore business might have real users on +881. That's what a documented exception is for.

## How does an HLR check stop pumping without blocking real users?

An [HLR lookup](/services/hlr-lookup) asks the home network whether a mobile number is in service and reachable right now. In a gated country it adds a check a bot can't fake by solving a challenge: the number has to be a live mobile line. Our guide to [HLR results](/blog/hlr-lookup-results-explained) explains each answer in depth.

| HLR answer | What it means | Suggested action in a gated country |
|---|---|---|
| `reachable` | Number in service and attached to the network | Send, under the gated limits |
| `unreachable` | Number in service, phone off or out of coverage now | Don't send now; offer "resend later" or another method |
| `invalid` | The network reports the number as not assigned | Don't send; ask the user to check the number |
| `unknown` | No answer from the network | Fall back to your default rules; never block on missing data |

Run the HLR and line-type checks only in the **gate** tier and only on the path that would send an SMS. Allowed countries don't need them for every code, and blocked countries never reach them. That keeps the cost to the traffic that carries the risk.

Here is a complete gate in Node.js (18 or later, no dependencies). It sends one lookup with the carrier and HLR checks, then applies the tiers. We ran it on 3 November 2026 with the public sandbox key `mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym`. The sandbox accepts only the documented [test numbers](/docs/test-mode), which are UK drama numbers, so the example puts GB in the gate tier.

```js title="otp-gate.mjs"
// otp-gate.mjs: decide per number whether to send an OTP by SMS (Node 18+, no dependencies)
const KEY = process.env.MOBILEVALIDATE_API_KEY;

// Your own tiers, built from your traffic and your provider's settings (ISO country codes).
const ALLOW = new Set(["US", "CA", "DE"]);   // where your customers are and codes get verified
const GATE = new Set(["GB"]);                // some real users, but check first (GB here so the test numbers hit it)
const NEVER_SMS = new Set(["premium_rate", "shared_cost", "uan", "personal", "pager", "toll_free", "voicemail"]);

async function lookup(numbers) {
  const r = await fetch("https://api.mobilevalidate.com/v1/lookup", {
    method: "POST",
    headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify({ numbers, checks: ["carrier", "hlr"], wait: 5 }),
  });
  if (!r.ok) throw new Error(`lookup failed: ${r.status}`);
  return (await r.json()).results;
}

function decide(res) {
  if (res.number_status !== "valid") return "reject: ask the user to fix the number";
  if (ALLOW.has(res.country)) return "send";
  if (!GATE.has(res.country)) return "block: country not enabled (manual exception only)";
  const lineType = res.checks["network.carrier"]?.attributes?.line_type ?? null;
  const hlr = res.checks["number.hlr"]?.attributes?.status ?? null;
  if (lineType && NEVER_SMS.has(lineType)) return `block: line type ${lineType}`;
  if (lineType === "fixed_line") return "no SMS: offer a voice call or another method";
  if (hlr === "invalid") return "block: network says the number is not in service";
  if (hlr === "unreachable") return "delay: offer resend later or another method";
  if (hlr === "reachable") return "send (gated country, strict per-prefix limit)";
  return "send with default limits (no data is not a reason to block)";
}

const results = await lookup(["+447700900001", "+447700900002", "+447700900003"]);
for (const res of results) console.log(res.e164, "→", decide(res));
```

Output:

```text
+447700900001 → send (gated country, strict per-prefix limit)
+447700900002 → delay: offer resend later or another method
+447700900003 → send with default limits (no data is not a reason to block)
```

The first test number is a reachable mobile. The second is in service but unreachable. The third returns `unknown` for both checks, and the gate falls through to the default rules instead of locking the user out. In production, a block-tier country never calls the API at all, so the cost is limited to the gate tier.

An HLR check has limits. A pumping operation that controls real SIMs in a gated country will pass it. That's why the gate also carries a per-prefix limit and an hourly country ceiling, and why the next section matters.

## How do you monitor for a pumping wave by destination?

Tiers are a snapshot. Attacks shift, so watch each destination continuously:

- **Verification rate per country, per hour.** Codes verified divided by codes sent. Google's documentation says rates above 75% are typically considered acceptable ([Google](https://docs.cloud.google.com/identity-platform/docs/admin/sms-regions)). Compare each country with its own normal level, not with a global average.
- **Send volume against its baseline.** A gated country that sends ten times its usual hourly volume is an alert, whatever its verification rate says so far.
- **Prefix concentration.** Many requests sharing the first digits of the national number point to one block of numbers.
- **Check results by country.** In the gate tier, a sudden share of `invalid`, `unreachable` or blocked line types is a signal on its own.
- **Spend by destination.** Read the SMS invoice by country every week. A cost spike in a country you thought was quiet is the last line of detection.

Then act per destination:

| Signal | Action |
|---|---|
| Allowed country drops well below its normal verification rate | Move it to **gate** for 24–72 hours; review |
| Gated country spikes in volume or falls in verification rate | Lower its hourly ceiling, or move it to **block** with the kill switch |
| Blocked country sees many code requests | Nothing to change; the block is working. Log it for your next review |
| Many failures from one prefix | Block the prefix, not the country |

Microsoft gives the same advice for its own tenants: when an application detects "a high volume of nonverification SMS messages" from a country code, disable telephony for that code ([Microsoft](https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-region-code-opt-in)). Review the tiers every month, and after every incident.

## Which MobileValidate checks fit a pre-OTP gate?

Three checks do the work in the gate tier. Prices are from our live catalog ([`GET /v1/services`](https://api.mobilevalidate.com/v1/services)) on 3 November 2026:

| Check | What it adds to the gate | Real time | Bulk |
|---|---|---|---|
| [HLR lookup](/services/hlr-lookup) (`number.hlr`) | In service and reachable now, ported or roaming, current network | $0.006 | $0.005 |
| [Carrier and line-type lookup](/services/carrier-lookup) (`network.carrier`, beta) | Line type (mobile, VoIP, premium rate, shared cost and more) and carrier, where data exists | $0.003 | $0.0015 |
| [Spam reputation](/services/spam-reputation) (`number.spam`, limited access) | Whether the number has been reported for abuse | Access on request | Access on request |

Format validation comes with every lookup at no charge, and every non-conclusive answer (`unknown`, unsupported country, timeout, invalid format, duplicate) is free. For the HLR check, `reachable`, `unreachable` and `invalid` are billed answers. Current prices are always on the [pricing page](/pricing), and top-ups of $100 or more get a bonus: +5% from $100, +8% from $500 and +10% from $2,000.

How to start:

1. **Build the gate for free.** Get a [free test key](/get-test-key). It returns fixed answers for the documented [test numbers](/docs/test-mode), so every branch of your rules can be tested without a charge.
2. **Try real numbers.** [Request access](/request-access) for a live account. Every live account gets 5 real phone checks and 5 real e-mail checks on the dashboard's **Try it** page.
3. **Clean the numbers you already hold.** If you store phone numbers from earlier sign-ups in gated countries, check them in a bulk job. Upload the list, get a free estimate of the maximum cost before anything runs, then download the results. The [bulk jobs guide](/docs/bulk-jobs) has the details.

The checks return network and line facts only. They never return a subscriber's name or address, and they're meant for numbers your users gave you, with a lawful basis, not for scanning number ranges. Requests that walk through consecutive numbers are refused. The [OTP and sign-up fraud use case](/use-cases/otp-and-signup-fraud) shows the same gate from the product side, and [SMS cost reduction](/use-cases/sms-cost-reduction) covers the savings view.

## What are the key takeaways?

- There is no public, citable ranking of SMS pumping countries. Published provider lists, such as Microsoft's 114 default-off codes for External ID, are gating defaults, not fraud rankings.
- Sort every destination into **allow**, **gate** or **block** from your own verification rate, volume and SMS cost per country.
- Block premium-rate, shared-cost, personal and similar line types, and the ITU's non-geographic codes, in every tier unless you have a documented need.
- In gated countries, check line type and live network status before you send, and treat `unknown` as "use the default rules", never as a block.
- Watch the verification rate and volume per country every hour, act per destination or prefix, and review the tiers monthly. For voice codes, read [toll fraud in voice OTP](/blog/toll-fraud-in-voice-otp), and for the send-code endpoint itself, [OTP bombing protection](/blog/otp-bombing-protection).

## Sources

1. [Regional opt-in for MFA telephony verification with external tenants (preview)](https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-region-code-opt-in) — Microsoft Learn (Microsoft Entra External ID), 2026
2. [Telephony fraud protections and throttles (Microsoft Entra ID)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-regional-opt-in) — Microsoft Learn, 2025
3. [Use SMS regions to protect your app from SMS abuse](https://docs.cloud.google.com/identity-platform/docs/admin/sms-regions) — Google Cloud (Identity Platform)
4. [A2P messaging under threat: joint report by Enea and Mobilesquared reveals 20 billion fraudulent messages sent in 2023](https://enea.com/news/press-releases/a2p-messaging-under-threat-joint-report-by-enea-and-mobilesquared-reveals-20-billion-fraudulent-messages-sent-in-2023) — Enea, 2024
5. [AIT fraud: what you need to know](https://www.ncsc.gov.uk/blog-post/ait-fraud-what-you-need-to-know) — National Cyber Security Centre (UK), 2023
6. [OAT-003 Cost-Inflation Fraud (OWASP Automated Threats to Web Applications)](https://github.com/OWASP/www-project-automated-threats-to-web-applications/blob/master/assets/oats/EN/OAT-003_Cost-Inflation_Fraud.md) — OWASP
7. [E.164 shared country codes and their assignments](https://www.itu.int/net/ITU-T/inrdb/e164_intlsharedcc.aspx) — ITU
8. [Recommendation ITU-T E.169.2: universal international premium rate numbers](https://www.itu.int/rec/T-REC-E.169.2/en) — ITU, 2000
9. [National numbering plans](https://www.itu.int/oth/T0202.aspx?parent=T0202) — ITU
10. [Fraud Loss Survey 2021](https://cfca.org/fraud-loss-survey-2021/) — Communications Fraud Control Association (CFCA), 2021

## Frequently asked questions

### Which countries are the highest risk for SMS pumping?

No regulator or industry body publishes a public, current ranking of countries by SMS pumping. The closest public data are the default-off lists some identity providers publish. Microsoft's External ID documentation, for example, switches off SMS verification for 114 country codes by default (page dated 17 April 2026). Treat such lists as a starting point and rank destinations with your own verification rate and SMS cost per country.

### Should I block every country where I have no customers?

For OTP, yes, as a default. A country you don't serve gives you little to lose and an attacker a lot to gain. Keep a documented exception process so that a real expansion or a travelling customer can be enabled on purpose, not by accident.

### What does it mean to gate a country instead of blocking it?

Gating means you still send codes there, but only after extra checks: a line-type check, a live network check (HLR), tighter per-number and per-prefix limits, and a lower hourly ceiling for that country. Real users still get their code. Pumped numbers that fail a check, or arrive too fast, don't.

### Which number ranges should never receive an OTP by SMS?

Premium-rate, shared-cost, universal access, personal, pager, toll-free and voicemail numbers, and the ITU's non-geographic codes such as +881, +882, +883 and +979, unless you have a documented business need. Real users rarely sign up with these, and some of them can't receive texts at all.

### Does an HLR lookup stop SMS pumping on its own?

No. It tells you whether a mobile number is in service and reachable right now. That removes numbers that aren't in service and flags phones that aren't on the network, but a pumping operation can use real, reachable SIMs. Combine it with country tiers, line types, rate limits and verification-rate monitoring.

### What verification rate signals a pumping attack in one country?

Compare each country with your own normal rate, hour by hour. Google's Identity Platform documentation says verification success rates above 75% are typically considered acceptable. A destination that falls far below its usual rate while its send volume rises is the classic pattern.

### How much does a pre-OTP number check cost with MobileValidate?

As of 3 November 2026 the live catalog lists the HLR check at $0.006 per number in real time and the carrier and line-type check (beta) at $0.003. Unknown and other non-conclusive answers are free. Current prices are on the pricing page.

### Can I test the gate before I pay for anything?

Yes. A free test key returns fixed answers for documented test numbers, so you can build every branch of the gate. Every live account can also run 5 real phone checks and 5 real e-mail checks for free on the dashboard's Try it page.