Every alerting stack has a step nobody tests. The monitor fires correctly, the rule evaluates correctly, and the integration reports success. What happens between that success message and a phone on a bedside table is usually assumed rather than verified.
For SMS alerts sent to US numbers, that assumption stopped being safe in 2025. Carriers now sort business messages into three outcomes, and only one of them involves the alert arriving.
This article covers what those outcomes are, why the middle one is the dangerous case, and how to establish which applies to your own escalation paths.
How business SMS reaches a US number now
The routing changed for reasons that had nothing to do with alerting, but the consequences landed on it anyway.
Why carriers introduced sender registration
Business messaging in the US now runs on registered sender identity. The standard is 10DLC, administered through the Campaign Registry, and it requires an organization to register itself and its use case before sending.
The driver was spam. Open, anonymous routes were being used at scale for phishing, and carriers had no sender identity to filter on. Registration solved that by making every business sender traceable.
Where alerting sat in that change
Alerting was collateral. Most teams never registered anything because most teams never bought an SMS product. They pointed a monitoring tool at a free carrier gateway address years ago, and it worked.
Those gateways were the anonymous route the changes were designed to close. AT&T shut theirs in June 2025, T-Mobile stopped functioning in December 2024, and Verizon’s is being retired ahead of a March 2027 deadline.
The three outcomes
Every business SMS to a US number now resolves one of three ways, and the operational difference between them matters more than the technical one. Which outcome you get depends almost entirely on registration, which is why teams comparing top A2P messaging providers are usually looking for a service that handles it on their behalf.
Registered and delivered
The sender is registered under 10DLC, the message routes through a known business identity, and it arrives. This is the only outcome where the alert reaches the engineer, and it requires the registration step to have happened at some point.
Filtered without notice
This is the case worth understanding properly. Unregistered traffic is not usually rejected. It is accepted, then dropped somewhere downstream, and no error returns to the sender.
The sending system logs success. The integration reports healthy. Nothing in any dashboard indicates a problem. From the alerting stack’s perspective, a delivered page and a discarded one are indistinguishable.
Blocked outright
Closed gateways behave slightly differently. Messages to a decommissioned carrier address fail at the destination rather than the filter, but the sender-side result is the same. No bounce, no error, no signal.
The distinction matters only for diagnosis. Operationally, filtered and blocked produce identical symptoms, which is nothing at all.
Why this breaks alerting specifically
Most systems that depend on delivery have a feedback loop. Alerting frequently does not.
Nobody notices an alert that never arrives.
A failed deployment gets noticed because the deployment fails. A page that never lands produces silence, and silence is what a working night looks like.
The failure surfaces during an incident review, when someone traces a slow response back and finds the on-call engineer was never contacted. By then the channel has usually been broken for months.
Configuration and delivery are different claims.
Teams treat a configured integration as a working one. It is not the same statement. The configuration says the rule exists. Delivery says a human received the message, and only one of those is testable from a dashboard.
The gap between them is where this problem lives, and it is invisible until somebody deliberately looks. Runbooks reinforce it, since they document what should happen rather than what was last confirmed to happen.
Establishing which outcome applies to you
The audit is short and gives a definitive answer rather than an inference.
Search your configurations.
Look for three domains across every system that can page a human: txt.att.net, vtext.com, and tmomail.net.
- Monitoring tool contact definitions and notification channels.
- On-call rosters and escalation policies.
- Cron jobs, scripts, and CI pipeline notification steps.
- Helpdesk escalation rules and ticketing integrations.
Anything found is a broken path. Fixing the primary monitoring tool alone is not sufficient, because backup jobs and certificate expiry warnings fire rarely enough that nobody notices their absence.
Test the whole route
Trigger a real alert rather than using a built-in test function. Vendor tests usually confirm account state rather than the route production traffic takes. Confirm receipt on a real device, at a realistic hour, from the sender identity production actually uses.
Check the registration status.
If your organization migrated to a paid service, confirm it registered you. The Federal Communications Commission has tightened requirements around business messaging and consumer consent, and a replacement that skips registration reproduces the original failure with a monthly invoice attached.
What a durable setup requires
Three properties separate a replacement that keeps working from one that fails the same way.
Registration handled for you
10DLC registration typically completes in one to two business days and requires details the organisation already holds. A service that handles it removes the most common reason alerts get filtered.
Per-message delivery reporting
The service must report delivered or failed for each message. Silent failure was the actual damage in 2025, not the shutdown itself. A replacement without delivery reporting leaves you in the same position.
No dependency on one device
Alerting runs in rotation, so no path should terminate on a single person’s phone. Replies and acknowledgements need to reach somewhere the next shift can access; otherwise, the handover carries a gap nobody can see.
Verify, do not assume.
The carrier changes were reasonable given how the open routes were being abused. The difficulty for engineering teams was that the change arrived without an error message in a system where absence of error is the normal state.
Teams that migrated deliberately lost nothing. Teams that inherited a gateway address in a config file written years ago are the ones still exposed, and the only way to know which group you are in is to check.
Treat any notification path without a verified result from this quarter as unverified rather than working. That framing is uncomfortable and accurate, and it is the version that survives a post-incident review.
The check itself takes an afternoon. Search the configs, fire one real alert, and confirm it landed. Either it validates what you already believed, or it surfaces something that has been quietly broken since 2025.
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.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals