What IT teams lost when carrier gateways closed

Why IT teams used carrier gateways

The appeal was practical rather than technical. Understanding it explains why the dependency became so widespread.

It required no procurement

Sending an alert as a text needed no account, no contract, and no budget line. An engineer typed an address into a monitoring configuration, and it worked. Nothing went through approval, because nothing needed approval.

For a team trying to make on-call rotation work with the tools it already had, this was the shortest available path.

It reached engineers who were not at a desk

Email works during working hours. At two in the morning, an email into a laptop inbox reaches nobody. A text reaches the handset on the bedside table.

That difference is the whole reason SMS entered the alerting stack. It was never about the message format. It was about the device.

Paging tools existed, but they carried per-seat costs that were difficult to justify for a small team with occasional overnight incidents. A free channel that reached a phone was good enough, and good enough tends to become permanent.

What closed and when?

The gateways were open relays with no sender verification, which made them a spam vector. Carriers closed them rather than attempt to police them.

The sequence

• T-Mobile: The @tmomail.net gateway started failing in December 2024 and was never restored.
• AT&T: Closed @txt.att.net and @mms.att.net on 17 June 2025.
• Verizon: Phase-out began in late 2024 with full closure due March 2027.

Why nobody was notified

A decommissioned API usually returns a deprecation warning, then an error. These gateways returned neither. Messages were accepted and discarded, and the sending system logged success.

For a monitoring stack, this is close to a worst case. The alerting path reported healthy while delivering nothing.

What broke in practice

The consequences appeared in incident reviews rather than dashboards.

Escalations that never arrived

On-call rotations built on gateway addresses stopped functioning. Nobody notices an alert that does not arrive, so the gap only becomes visible when an outage runs longer than the response target.

Teams often attributed those delays to slow acknowledgement rather than non-delivery, which meant the real cause went uninvestigated.

Alerts buried in configuration

Gateway addresses were rarely stored in one place. They sat in Nagios contacts, Zabbix media types, PRTG notification templates, cron jobs, and helpdesk escalation rules. Auditing them requires searching each system individually.

Many teams that fixed their primary monitoring tool later discovered secondary systems still pointing at closed addresses. Backup jobs, certificate expiry warnings, and disk threshold alerts are common stragglers because they fire rarely enough that nobody notices their absence.

What a replacement needs

The market has three broad options, and the right one depends on volume and integration appetite.

The three tiers

• SMS APIs: Full programmatic control, requires development work and ongoing maintenance.
• Incident platforms: Rotation management, retry logic, and acknowledgement tracking built in.
• Email-to-text services: Preserve the original workflow, with the email routed through a registered business number instead of an open relay.

Demand across all three has grown since the closures. Grand View Research tracks application-to-person messaging as an expanding market, with alerting and notification among the primary drivers.

Non-negotiable requirements

• 10DLC registration: Required for US business messaging. Unregistered traffic is filtered, which reproduces the original failure.
• Delivery confirmation: The service must report delivered or failed per message. Silent failure was the actual damage in 2025.
• Carrier independence: Alerts must reach engineers regardless of which network they use.
• Shared access: No alerting path should depend on one person's device or login.

Cost is usually secondary here. The expense of an extended outage caused by an undelivered page dwarfs the monthly cost of any option in the list.

How to audit your own alerting

The check is quick and produces a definitive answer.

Find the addresses

Search monitoring configurations, on-call rosters, helpdesk escalation rules, and scripts for txt.att.net, vtext.com, and tmomail.net. Anything found is a broken path.

Test end to end

Trigger a real alert rather than using a built-in test function. Vendor tests usually confirm account state, not the route production traffic actually takes. Confirm receipt on a real handset, at a realistic hour.

Put it on a schedule

An alerting path verified once was working once. Quarterly verification, recorded against each channel, is what prevents the same discovery happening again.

Treat any channel without a result from the current quarter as unverified rather than working. That framing is uncomfortable and accurate, and it is the only version that survives an incident review.

The takeaway for on-call teams

The gateways served IT operations well and their closure was justified by how they were being abused. The difficulty was the absence of any signal that the change had occurred.

Teams that migrated deliberately lost nothing. Teams that never knew they were using the channel are the ones still exposed, and the only way to tell which group you are in is to look.

An hour spent auditing notification paths is cheaper than one extended outage caused by an alert that was never delivered.

Author Bio:

Ashmi Desai is a senior content editor with extensive experience in reviewing, refining, and optimizing high-impact digital content. She specializes in transforming complex technical topics into clear, engaging, and SEO-driven narratives. With a strong eye for structure, tone, and accuracy, Ashmi ensures every piece of content aligns with brand voice, search intent, and business goals.