SMS gateway addresses for Verizon, Xfinity and others: do they still work?

Every IT admin has run some version of this setup. A monitoring tool, a NAS, a building alarm panel or a cron job can send email but not SMS, so you point it at 5551234567@vtext.com and the alert lands on someone's phone as a text. It costs nothing and needs no account. For years it worked well enough.

Today it works much less often. Some carriers have shut their gateways down entirely. The ones still running are best-effort, filtered and undocumented, and they fail silently. You find out an alert didn't arrive when someone asks why nobody responded to the outage. This post covers which gateway addresses still exist, why they break, and what moving those alerts to a registered SMS API involves, including the costs and the cases where SMS is the wrong channel for the job.

How carrier email-to-SMS gateways work

Each carrier ran a mail server that accepted email addressed to phonenumber@carrier-domain and converted it into a text to that subscriber. MMS gateways handled longer messages and attachments on a separate domain. To use one, you had to know which carrier the recipient used, because the domain is carrier-specific.

These gateways were built as a consumer convenience. Carriers never offered them as a business messaging product, never published delivery guarantees, and never committed to keeping them running.

The common gateway addresses and their status

Status changes without much notice, so treat this table as a starting point and test any address before you rely on it.

Two patterns stand out. The largest US carriers are retiring these gateways or tolerating them without supporting them. And MVNOs like Xfinity Mobile never had a clean, documented gateway to begin with.

Why gateway alerts fail even when the address is "live"

Spam filtering hits automated mail first

Carrier gateways receive huge amounts of junk mail, so they filter hard. A monitoring tool sending the same templated subject line every few minutes from a generic SMTP relay looks a lot like spam. Messages get dropped with no bounce.

You get no delivery receipt

When a gateway accepts your email, that only means the mail server took it. It tells you nothing about whether the phone got a text. You get no status, no failure reason and no retry signal.

Number porting breaks the address silently

When an on-call engineer switches from Verizon to T-Mobile and keeps the same number, the @vtext.com address stops reaching them. Nothing errors. Your config file now holds a dead route, and you won't know until it matters.

Formatting gets mangled

Gateways truncate long bodies, put the subject line in odd places and show the sender as an email-derived short code or a random number. Recipients can't reply in any useful way. If a recipient texts STOP, the request has nowhere to go.

Carriers are tightening rules on unregistered business traffic

US carriers now expect business-originated texts (A2P traffic) to travel over registered routes. Our 10DLC explainer covers the registration system. Email-to-text gateways sit outside that system, which is the main reason carriers are shrinking them instead of investing in them.

Is SMS the right channel for your alerts at all?

Before you migrate, decide where each type of alert should go. Moving everything to SMS isn't always the answer.

• 3 AM pages to on-call engineers: a paging app with push notifications and escalation, or a voice call, is usually the better fit. Ready enforces quiet hours. A text sent during the recipient's quiet hours is held and delivered later, which is right for customer messaging and wrong for a server-down page. For middle-of-the-night pages, don't route them through Ready. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.
• Business-hours operational alerts (low stock, a failed backup report, a form submission, a job finished): SMS through an API works well here.
• Customer-facing notifications (order shipped, appointment reminders, service outage notices): an API is clearly the right tool. These need registration, opt-out handling and an audit trail no matter what.

Some setups shouldn't move to anything paid. If you have a homelab and one gateway address still reaches your own phone, keep using it and accept that it might break. Also skip the shortcut of putting a SIM in an old Android phone and calling it a gateway. We cover why in using an Android phone or GSM modem as an SMS gateway.

Moving to an SMS API: what changes

An API send is an HTTPS request instead of an email. Most monitoring tools support webhooks, and a short script can handle any tool that only supports email. On Ready, a single alert looks like this:

curl -X POST https://api.tryready.com/v1/messages \
  -H "X-API-Key: YOUR_KEY" \
  -H "Idempotency-Key: 3f1c2a9e-7b44-4c1e-9d0a-5e8f6b2c1a77" \
  -H "Content-Type: application/json" \
  -d '{"to": "+12125550199", "body": "ALERT: backup job failed on fs-02 at 14:05", "consent_attested": true}'

Here's what you get that a gateway can't give you:

1. Carrier doesn't matter. You send to the phone number. A port from Verizon to T-Mobile changes nothing on your side.
2. Retries are safe. The Idempotency-Key header means a retried request never sends the same alert twice.
3. Fan-out is built in. POST /v1/messages/bulk sends one body to up to 100 numbers per call, which is useful for paging a whole team.
4. Opt-outs are handled for you. If a recipient texts STOP, Ready honors it and refuses future sends to that number up front, without charging for them. You can check the list with GET /v1/opt-outs.
5. You keep a record. GET /v1/messages shows what was sent and when.

The full reference is at docs.tryready.com/api/messages, and the quickstart takes you from a key to a first send. For a broader look at registered sending from your own software, see our A2P SMS API guide.

consent_attested is your statement that the recipient agreed to receive texts. It applies to your own staff too. Get their OK in writing (an onboarding form works) and keep that record yourself. Ready logs the attestation on each send, but it doesn't store each recipient's opt-in. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)

What it costs: a worked example

Gateways were free, and an API is not. Here's an example with assumed numbers.

Assumptions: 20 alerts a day, each sent to 4 people, over 30 days. Each alert is plain text under 160 characters, so it's 1 segment.

• Segments: 20 × 4 × 30 = 2,400 segments a month
• Ready Standard rate: 2,400 × $0.0075 = $18
• Carrier fee: 2,400 × $0.0045
• Registration: $25 at submit (first month), then $25/mo for registration + $2 per number

Those totals exclude the optional compliance surcharge. TCPA/DNC scrubbing and landline validation are each $0.003 extra per segment if you switch them on, and both are off by default.

Watch what you put in the message body. A ⚠️ emoji at the start of an alert switches the message to unicode, and the single-segment limit drops from 160 characters to 70. A 140-character alert with one emoji becomes 3 segments instead of 1, which triples the cost of that alert. Leave the emoji out.

If the lowest per-segment price is your only criterion, raw CPaaS APIs like Twilio (around $0.0083/segment) cost less per text. What Ready adds is registration handled in-app, opt-out handling, quiet hours, an inbox for replies and optional scrubbing, so you aren't building those yourself. Our 10DLC cost breakdown itemizes every fee.

Getting from gateway to API without a gap

1. Audit your configs. Search them for vtext.com, tmomail.net, txt.att.net and vzwpix.com. Teams usually find more of these than they expected.
2. Sort each alert into urgent paging, business-hours alerts or customer-facing notifications, as described above.
3. Sign up and test. The first 20 texts are free one-to-one sends, so use them to test before you register. To send, you add a card and get a number, which is $2 a month with the first month charged when you get it.
4. Register. You can send up to 500 texts a month at the normal rate before registering, which covers testing and light alerting. Above that you need to register, and most approvals take 2 to 7 days.
5. Run both in parallel for a week. Then remove the gateway addresses.

The short version

Carrier email-to-text gateways are disappearing. AT&T's is being retired, and the gateways still running are filtered, unsupported and silent when they fail. For alerts you care about, an API gives you carrier-independent routing, delivery records and opt-out handling. Send urgent overnight pages through a paging app or a voice call instead of SMS.

If you want to try the API route, create an account, send your first alert with the free texts, and register once it does what you need.