Verifying AT&T Mail addresses

• Every RCPT TO returns a positive response, because the answering server is Yahoo's and follows Yahoo's anti-harvesting policy.
• The legacy brands, sbcglobal.net, bellsouth.net, ameritech.net and pacbell.net among them, all route the same way.
• Real bounces arrive asynchronously against the return path, on Yahoo's timing.
• The catch-all probe also returns 250, so these domains classify as accept-all everywhere.

• Yahoo's bulk sender requirements apply to these recipients, since Yahoo is the receiving system.
• Yahoo's feedback loop covers the AT&T domains, which makes it the only practical complaint signal available.
• Any US consumer list with a heavy sbcglobal.net or bellsouth.net share is old data by construction.

Group by MX and AT&T's scattered brands collapse into one. On September 19, 2026, att.net, sbcglobal.net, bellsouth.net, ameritech.net, pacbell.net, prodigy.net, swbell.net, flash.net and snet.net all returned a single host: mx-att.mail.am0.yahoodns.net. The hostname even spells out the arrangement, AT&T's name on Yahoo's DNS.

Say a Texas HVAC company uploads 6,000 customer addresses. A per-domain report shows sbcglobal.net at 480 rows, att.net at 350, swbell.net at 190 and flash.net at 80, each small enough to shrug at. Add them up and 1,100 rows, close to a fifth of the list, sit behind one server that won't give a mailbox verdict. That's the number to plan around, and you only see it if the report groups by who answers the mail instead of what's printed after the @ sign. If your current tool doesn't offer that grouping, request it.

Ask what response the verdict came from. If the server returns a positive reply for every recipient, including a made-up one, then a valid label on these rows has to come from somewhere other than the SMTP conversation. Common sources are an old bounce database, a guess from the shape of the local part, or simply counting every 250 as a pass. Any of those can be right by luck. None is a measurement, and each one inflates the accuracy figure on the sales page, because it moves unverifiable rows into the verified column.

A fair answer sounds like this: that host accepts every recipient, so these rows are catch-all, not valid, and here's how many there were. With us a catch-all row costs a credit like any other result, because the finding is real: it tells you that nobody's valid on att.net is a measurement. Only the rows where the server wouldn't answer at all come back unknown, and those aren't charged. Then plan the send accordingly. Mail the AT&T group separately, keep the volume modest on day one, and clear the late bounces from that group before its second send.