What to do when experiencing issues sending email to SMS texts via ATT?
Published 4 Jul 2025
Updated 20 Oct 2026
10 min read
Summarize with
Updated on 20 Oct 2026: We added practical email-to-text replacement options and clarified how to trace retired AT&T gateway routes separately from email authentication failures.
AT&T shut down email-to-text and text-to-email on June 17, 2025, according to AT&T's support page. Messages sent to a 10-digit number at txt.att.net or mms.att.net no longer become texts. Replace the retired AT&T SMS gateway in each alert or notification workflow. The shutdown does not stop ordinary phone-to-phone SMS or MMS, or email delivered to a normal mailbox.
A bounce or message trace can still identify which application uses the old address. Check the wider mail path only when the same sender also fails at normal mailbox destinations. That distinction prevents a retired carrier gateway from masking a separate sender-side problem.
Why the AT&T SMS gateway no longer works
The public AT&T email gateway has ended. Messages to txt.att.net or mms.att.net can return a permanent SMTP error or fail without a useful bounce. Changing SPF, DKIM, or DMARC cannot reopen this route. A successful upstream SMTP handoff does not prove that a text reached the phone.
Stop retries and use a working fallback
A 5xx response is a permanent SMTP rejection for that attempt; it does not identify the cause on its own. AT&T's shutdown notice establishes that the public gateway must be replaced. Repeating the old send adds queue noise while urgent alerts still need a working route.
- Stop automated retries to the retired gateway and send urgent alerts through a working fallback.
- Separate the retired gateway incident from any normal email delivery incident.
- Keep the full NDR, message ID, timestamp, sending IP, sender domain, and recipient address.
- Treat AT&T's public email-to-SMS gateway as retired infrastructure.
Example 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
This example records a permanent SMTP rejection. The 550 5.2.0 code is not specific to either the shutdown or a DMARC failure. A different error, or no useful bounce, does not make the retired gateway usable.
Confirm the failure scope
The useful question is whether only AT&T gateway addresses fail or whether normal mailbox delivery fails too. Do not change DNS, rewrite content, or move mail servers until that scope is clear.
- Record whether the recipient uses txt.att.net or mms.att.net. Both AT&T email-to-text routes are retired.
- Test a normal mailbox with the same sending source. Success there supports investigating the gateway failure separately; one successful test does not establish that all normal email is healthy.
- Identify the application, connector, relay, and envelope sender that generated the message.
- Classify the result as a permanent bounce, temporary deferral, timeout, or silent non-delivery.
|
|
|
|---|---|---|
550 from gateway | Permanent rejection | Retire route |
Timeout or deferral | No dependable delivery | Retire route |
No bounce | No proof of phone delivery | Trace and migrate |
Normal email also fails | Separate sender issue | Inspect trace and sender configuration |
Triage signals for current AT&T email-to-SMS failures.
Use message trace to find stale routes
Microsoft Exchange admin center message trace with a 550 5.2.0 rejection for mms.att.net.
For Microsoft 365 senders, message trace shows mail-flow events for messages that passed through Exchange Online. Open Mail flow > Message trace in the Microsoft Exchange admin center, filter by recipient and time range, and capture the response, connector, source IP, timestamp, and message ID. Use the results with application or relay logs to locate the system that still uses the old address.
Retired AT&T gateway formats
{10-digit-number}@txt.att.net {10-digit-number}@mms.att.net
Good evidence
- Keep the complete NDR, including the reporting and remote servers.
- Record the exact timestamp with its timezone and message ID.
- Compare the gateway result with a message to a normal mailbox.
- Note the application, connector, relay, and envelope sender.
Weak evidence
- A cropped error image hides the sender, route, and timing.
- A report without counts does not show which systems are affected.
- SPF or DKIM edits without evidence can create a second problem.
- Repeated sends can hide whether the replacement route works.
A trace showing an AT&T gateway response identifies where that SMTP attempt ended. Even a "Delivered" status records the email handoff rather than confirming SMS delivery. If no result appears, search using the envelope sender, which can differ from the visible From address.
Check authentication only for broader failures
Email authentication does not restore AT&T email-to-text. Check sender configuration when the same domain also has normal inbox placement problems. A domain health check can identify separate authentication and DNS configuration problems.
Suped's DMARC reporting and email authentication platform combines DMARC monitoring with authentication checks and blocklist monitoring. Use these results to investigate broader email failures; DMARC reports do not prove inbox placement or SMS delivery.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a bounce that explicitly cites a PTR or reverse DNS error, investigate reverse DNS failures with the owner of the sending IP. Investigate HELO/EHLO hostname errors with the mail server owner or sending platform.
Checks for a separate sender problem
- Confirm that SPF authorizes the real sending source and stays within the DNS lookup limit.
- Confirm that the application or relay signs with DKIM and that the signature verifies using the selector's published DNS key.
- Check that SPF or DKIM passes. Its authenticated domain must match the visible From domain exactly in strict mode, or share its organizational domain in relaxed mode.
- Check domain and IP blocklist or blacklist status when other destinations fail too.
Test the application path when normal email also fails
When normal mailbox delivery also fails, send a small message through the same application path and inspect it with an email tester. Compare its authentication results with a test from the main business mail system. Do not use the retired AT&T gateway as the test destination.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
This check matters when an old monitoring system uses a relay that differs from normal business mail. If the main mail system passes but the application server fails, repair that application path as a separate issue.
Keep the test plain, with a short subject and body, no attachment, and one recipient. If the plain message fails at a normal mailbox, inspect authentication and host identity. If it succeeds, compare the production message's size, links, attachments, sender identity, and envelope sender.
Why AT&T support cannot restore the gateway
AT&T support cannot reactivate the retired public email-to-text service for a consumer line. Contact support only for questions about how the shutdown affects an account or a contracted business messaging arrangement. Delivery troubleshooting for txt.att.net and mms.att.net does not produce a supported replacement route.
- A consumer subscriber can ask support to confirm that the public gateway has ended for the line.
- A business account owner can ask the account team about contracted messaging options already attached to the account.
- Provide timestamps, recipient numbers, sender domain, sending IP, and NDR text only if support requests evidence.
- Do not delay migration while waiting for an exception to the public gateway shutdown.
A clean sender does not restore the route
A valid DMARC result and good sender reputation do not require AT&T to accept or convert a message through a service it has ended. Preserve evidence for the incident record, then replace the route.
Choose an AT&T email-to-text alternative
Choose the replacement around what the sending system supports. A managed SMTP-to-SMS bridge can accept an existing alert email and send SMS through a supported messaging route. An SMS API requires an application integration; app notifications or normal email fit workflows that do not need a text.
|
|
|
|---|---|---|
Managed SMTP-to-SMS bridge | Older monitoring systems or devices that send only email. | Confirm approved SMS delivery, authenticated email submission, accepted senders, failure reporting, and reply support. |
SMS API | Applications that can call an HTTP API. | Implement delivery-status callbacks, bounded retries, duplicate prevention, and an escalation path. |
App push notifications | Personal email alerts or internal notifications when recipients have mobile data or Wi-Fi. | Test notification permissions and background delivery on each recipient's phone. |
Normal email | Non-urgent notices and transferring photos or files to a smartphone. | Send to a regular mailbox and open it in the phone's email app. |
Replacement options for retired AT&T email-to-text workflows.
For U.S. application-to-person (A2P) SMS, confirm sender approval with the messaging operator before switching. A 10-digit long code (10DLC) route uses brand and campaign registration; toll-free numbers and short codes have different approval processes. Allow time for approval and check setup and ongoing costs before committing to a replacement.
Replace the email-to-SMS workflow
The long-term fix is migration. Email-to-SMS required little application work, but SMTP acceptance did not prove phone delivery or recipient acknowledgment.
Retired email gateway
- The carrier controlled conversion and could end the service.
- SMTP acceptance did not prove delivery to the phone.
- The public gateway did not manage the sender's consent records or alert escalation process.
- Filtering, silent drops, and shutdowns created operational risk.
Supported messaging route
- Use a registered 10DLC number, verified toll-free number, short code, or another approved route suited to the traffic.
- Track accepted, delivered, failed, and suppressed messages. For urgent alerts, require recipient acknowledgment and escalate if nobody responds.
- Keep consent source, opt-out handling, audit logs, and rate controls.
- Separate urgent texts, normal email, app notifications, and voice escalation paths.
Start by finding every use of an AT&T gateway address, including monitoring rules, mailbox forwarding, application code, and contact records. Decide whether each message needs a text, move critical notifications to a supported route, and keep non-urgent notices in email or an internal app. Replace any inbound text-to-email reply workflow too, because AT&T ended both directions of the service.
AT&T email-to-SMS migration flowchart covering gateway discovery, urgency, consent, channel choice, and retirement.
- Search code, device configurations, monitors, ticket rules, forwarding rules, shared mailboxes, contacts, and distribution lists for txt.att.net and mms.att.net.
- Mark each message as urgent, operational, informational, or obsolete.
- Choose a supported route that matches the use case, consent record, and reply requirement.
- Test actual phone receipt, replies, failure reporting, and fallback escalation before switching production alerts.
- Remove both outbound gateway addresses and inbound text-to-email dependencies.
Immediate response checklist
For a current failure, stop depending on AT&T email-to-SMS. Confirm which system used the retired address, preserve trace evidence, test a normal mailbox if broader delivery trouble is suspected, and move the workflow to a supported messaging route.
Use Suped's DMARC reports and authentication checks when the same sender also fails at normal mailbox destinations. Keep SMTP trace evidence alongside those results; authentication checks alone cannot establish why every message failed.
- Stop automated retries to txt.att.net and mms.att.net, and activate a working fallback for urgent alerts.
- Document the sending application, affected workflow, timestamps, and trace result.
- Replace the gateway address with a supported route suited to the message and consent record.
- Monitor authentication and reputation separately when normal email also fails.
