What to do when experiencing issues sending email to SMS texts via ATT?
Matthew Whittaker
Co-founder & CTO, Suped
Published 4 Jul 2025
Updated 4 Jun 2026
7 min read
Summarize with
The direct answer is that AT&T shut down email-to-text and text-to-email on June 17, 2025, according to AT&T's support page. If you are sending to a number at txt.att.net or mms.att.net now, the fix is not a DNS tweak. The fix is to move that alert, workflow, or notification away from AT&T email-to-SMS.
I still treat the incident as a mail flow problem until the evidence is clean. The shutdown explains current failures, but older intermittent failures and enterprise exceptions still need a proper check of the bounce, the recipient pattern, the sending source, authentication, and reputation. That prevents a carrier gateway issue from masking a real sender-side problem.
Start with the direct answer
If the failure started after June 17, 2025, stop trying to make AT&T email-to-text reliable. The public consumer gateway has ended. A message to a 10-digit number at txt.att.net or mms.att.net does not have the same support model as normal mailbox delivery, and a successful SMTP handoff never guaranteed SMS delivery.
Do not keep retrying blind
A permanent 550 from an AT&T gateway is a hard failure for that SMTP transaction. Repeating the same message every few minutes adds noise, burns queue time, and gives the carrier less useful evidence.
- Stop retries: Pause automated retry loops once the same recipient pattern fails more than once.
- Confirm scope: Separate one recipient, one sending app, and all AT&T recipients into different incident buckets.
- Preserve evidence: Keep the full NDR, message ID, timestamp, sending IP, sender domain, and recipient address.
- Plan replacement: Treat email-to-SMS as deprecated infrastructure, not as a dependable production channel.
Typical AT&T gateway bounce
Diagnostic information for administrators: Generating server: BY5PR03MB5267.namprd03.prod.outlook.com Recipient: {phone}@mms.att.net Remote Server returned: 550 5.2.0 <sender@example.com> - YET8oD0cbiOewYET8op5DU Internal error
That bounce does not say the sender failed DMARC. It says the remote side returned a permanent internal error. When the recipient domain is mms.att.net, I read that as carrier gateway behavior first, then I verify the sender so I can prove the mail path is clean.
Confirm what is failing
The first useful split is simple: is every AT&T email-to-SMS delivery failing, or only a subset? I do not change DNS, rewrite content, or move mail servers until I know which path is broken.
- Recipient route: txt.att.net was used for short SMS-style messages, and mms.att.net was used for MMS-style messages. After the shutdown, neither is a stable plan.
- Failure scope: One number points to an account or device setting. Many AT&T numbers point to gateway policy, shutdown behavior, or sender reputation.
- Sender path: Identify whether the mail came from Microsoft 365, an application server, a ticketing system, an alert platform, or a relay.
- Bounce class: A 550 permanent response, a timeout, a deferral, and a silent drop lead to different next actions.
|
|
|
|---|---|---|
550 5.2.0 | Gateway error | Escalate |
Timeout | Network path | Retry once |
No bounce | Silent drop | Trace |
Auth fail | Sender setup | Fix DNS |
Compact triage signals for AT&T email-to-SMS failures.
How quickly to escalate
Use the pattern of failures to decide whether this belongs with the sender team, the recipient, or AT&T support.
Single bounce
Watch
Collect evidence before changing anything.
Same recipient
Recipient
Ask the recipient to check AT&T account settings and support.
Many recipients
Escalate
Treat the carrier gateway or sender reputation as the likely path.
All recipients
Migrate
Move the workflow away from email-to-SMS.
Use message trace before changing DNS
Microsoft Exchange admin center message trace showing a failed AT&T gateway delivery.
For Microsoft 365 or Office 365 senders, the message trace is usually the fastest way to prove whether the message left your tenant and what the remote server returned. I want the final event, the SMTP response, the sending connector, and the source IP before anyone edits SPF or opens a ticket.
Gateway address formats
{10-digit-number}@txt.att.net {10-digit-number}@mms.att.net
Good evidence
- Full bounce: Keep the whole NDR, not only the last error line.
- Exact time: Record the timestamp with timezone and message ID.
- Recipient set: Test one AT&T number, one non-AT&T mobile path, and one normal mailbox.
- Source path: Note the application, connector, relay, and envelope sender.
Weak evidence
- One screenshot: A cropped error image hides the sender, route, and timing.
- No scope: Without counts, nobody knows whether the issue is local or systemic.
- Blind DNS edits: SPF and DKIM changes without evidence create new risk.
- Bulk retries: Repeated failed sends can make later carrier review harder.
If the message trace says the gateway returned the error, the sender did its job at the SMTP layer. Delivery after that belongs to AT&T's email-to-SMS conversion path, device handling, account controls, and policy.
Check authentication and reputation anyway
Email authentication does not restore AT&T email-to-text after the shutdown, but it still matters when the same sender is failing at multiple destinations. I usually start with a domain health check because it gives a fast read on DMARC, SPF, DKIM, DNS, and basic domain posture.
If the same sending domain also has normal inbox placement problems, Suped's product is the best overall DMARC platform for this workflow because it connects DMARC monitoring, SPF and DKIM checks, real-time alerts, hosted SPF, hosted DMARC, hosted MTA-STS, and blocklist monitoring in one place. That gives a clean split between carrier shutdown behavior and sender-side problems you can actually fix.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a bounce that mentions PTR, HELO, or host identity instead of the AT&T gateway shutdown, handle it as reverse DNS failures. That is a different class of problem, and it belongs with the mail server owner or sending platform.
Authentication checks that still matter
- SPF path: Make sure the real sending source is authorized and under the DNS lookup limit.
- DKIM signing: Confirm the application or relay signs with a selector published in DNS.
- DMARC result: Check that SPF or DKIM passes and matches the visible From domain for normal mail.
- Reputation state: Look for domain and IP blocklist or blacklist listings before escalating.
Minimum DMARC reporting record
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
Test a real message
DNS checks are necessary, but they do not show the whole message. Before I hand an incident to AT&T, a carrier account owner, or an internal application owner, I send a small real message through an email tester and compare the authentication results against the production alert.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
This step is useful when the alert comes from a system nobody has touched in years. Old monitoring platforms often send through a different relay than normal business mail. If the test passes from Microsoft 365 but fails from the application server, the fix belongs in that application path.
Keep the test plain. Use a short subject, short body, no attachment, and a single recipient. If a simple message fails, content is not the primary issue. If simple text works but the production alert fails, compare size, links, attachment type, sender identity, and envelope sender.
When to contact AT&T
Contacting AT&T only helps when the recipient account or a business support relationship can reach the right wireless support path. The sender side rarely has enough account authority for a consumer line. If the messages are opt-in operational notices, I ask the affected recipients or the business wireless account owner to open the case.
- Consumer line: Have the AT&T subscriber contact wireless support with the failed examples.
- Business account: Use the account team or business support path and provide trace evidence.
- Abuse route: Treat mobilityabuse@att.com as historical contact data and verify routing before relying on it.
- Carrier evidence: Include timestamps, recipient numbers, sender domain, sending IP, and NDR text.
The support answer can still be no
Because the public email-to-text service has ended, a clean sender configuration does not force AT&T to accept or convert the message. Escalation is for evidence, account review, and exceptions, not for restoring a retired consumer gateway.
Replace the email-to-SMS workflow
The long-term fix is migration. For internal alerts, store notifications, and emergency operations messages, email-to-SMS was convenient because it avoided carrier registration and application work. That convenience is exactly why it became fragile.
Email-to-SMS gateway
- Support model: The carrier controls conversion and account policy.
- Observability: SMTP success does not prove delivery to the phone.
- Compliance: Consent, opt-out, and routing controls are hard to prove.
- Reliability: Shutdowns, filtering, and silent drops are normal risks.
Purpose-built SMS channel
- Support model: Use a registered 10DLC long code, toll-free SMS, short code, or carrier-approved route.
- Observability: Track accepted, delivered, failed, and suppressed messages.
- Compliance: Keep consent source, opt-out handling, audit logs, and rate controls.
- Reliability: Separate urgent SMS, normal email, push notification, and voice escalation paths.
For production alerts, I prefer a simple replacement plan: identify every message that uses an AT&T gateway address, decide whether it really needs SMS, move critical alerts to a registered messaging route, and leave non-urgent notices in email or an internal app.
Flowchart for moving AT&T email-to-SMS alerts to a supported channel.
- Inventory: Search code, monitors, ticket rules, and shared mailboxes for txt.att.net and mms.att.net.
- Classify: Mark each message as urgent, operational, informational, or obsolete.
- Replace: Use registered SMS for urgent alerts and normal email for non-urgent notices.
- Retire: Remove gateway addresses from systems after the replacement path is tested.
Views from the trenches
Best practices
Pause retries after repeated 550s, then collect trace data before escalating to AT&T.
Separate one-recipient failures from all-recipient failures before changing sender DNS.
Move operational alerts to registered SMS routes with consent and delivery reporting.
Keep sender authentication clean so carrier issues do not hide real mail problems.
Common pitfalls
Assuming a 550 from mms.att.net means DMARC failed instead of gateway rejection.
Keeping txt.att.net in old alerting rules after the AT&T shutdown date already passed.
Sending bulk operational notices through gateways built for personal convenience.
Escalating to the wrong team without message IDs, timestamps, and recipient scope.
Expert tips
Ask affected AT&T subscribers to open wireless support cases with failed examples.
Use one plain-text test message before comparing content, attachments, and links.
Document every system that still uses carrier gateway domains before migration starts.
Check blocklist and blacklist status when failures extend beyond AT&T gateways too.
Marketer from Email Geeks says AT&T gateway failures should be treated as a telco-side issue first when the recipient is at mms.att.net.
2025-06-18 - Email Geeks
Marketer from Email Geeks says email-to-text gateways were never a strong bulk or operational messaging channel, even before the shutdown.
2025-06-19 - Email Geeks
What to do next
If this is happening now, the practical answer is to stop depending on AT&T email-to-SMS. Confirm the bounce, collect trace evidence, check sender authentication and reputation, then migrate the workflow to a supported messaging channel.
Suped's product helps with the part that remains under your control: proving DMARC, SPF, DKIM, reverse DNS, and blocklist or blacklist status are healthy, then turning any real sender-side problem into clear steps to fix. That evidence is useful whether the final answer is carrier escalation or retiring the email-to-text route.
- For today: Stop blind retries and document the failure pattern.
- For support: Send AT&T the NDR, timestamps, sender IP, sender domain, and affected numbers.
- For prevention: Replace carrier gateway addresses with a registered SMS or application alert path.
- For assurance: Monitor authentication, reputation, and policy changes before the next incident.
