What causes reverse DNS failures from AT&T and how can they be resolved?
Published 9 May 2025
Updated 11 Oct 2026
11 min read
Summarize with
Updated on 11 Oct 2026: We clarified AT&T reverse DNS troubleshooting with DNS error checks, cache timing, and IPv6 verification.
Reverse DNS failures at AT&T-managed recipient domains, including att.net, sbcglobal.net, bellsouth.net, and swbell.net, usually have one of two causes. The sending IP has missing or mismatched PTR and forward DNS, or the lookup fails because of authoritative DNS or AT&T resolver problems. Prove which side is failing before changing mail infrastructure. Check the public sending IP's PTR, forward-confirmed reverse DNS, HELO or EHLO name, authentication results, and IP reputation first. If those checks pass and unrelated senders see matching AT&T failures in the same period, investigate a receiver-side incident and preserve evidence for escalation.
Start with the exact bounce text and a real message test. Suped's email tester checks authentication at its test inbox; its result does not reproduce AT&T's receiving checks. Use the actual AT&T SMTP response and public DNS lookups to investigate the rejection. A reverse DNS error is separate from a DMARC failure. SPF, DKIM, and DMARC remain useful parallel checks for the same sending stream.
What AT&T is checking
AT&T mail systems can reject or defer mail when the connecting IP does not resolve cleanly to a hostname, or when that hostname does not resolve forward to the same IP. The PTR lookup is reverse DNS (rDNS); checking that the returned hostname resolves back to the connecting IP is forward-confirmed reverse DNS (FCrDNS). It is a sender infrastructure check, separate from SPF, DKIM, and DMARC.
The receiver sees the connecting IP first. It then asks DNS for the PTR record of that IP. A missing PTR or a DNS error prevents a usable reverse lookup. A generic hostname can trigger a separate policy rejection even when the lookup succeeds. If the PTR hostname exists but its A or AAAA record does not include the sending IP, forward confirmation fails. A valid PTR does not need to match the visible From domain. Exact equality between the PTR and HELO name is useful for self-hosted systems, while shared platforms can use different valid infrastructure names.
Reverse DNS flowchart linking a sending IP to its PTR hostname and forward DNS lookup.
An AT&T-side failure is more likely when the same reverse DNS wording appears across unrelated sending systems or several AT&T recipient domains while the named sending IP passes public PTR and forward checks. That pattern supports investigating the receiving path. Public lookups show DNS at the test time; compare authoritative DNS availability and the receiving host at the original failure time before assigning responsibility.
Do not assume the bounce text names the root cause
A bounce that mentions reverse DNS can result from a missing PTR record, the wrong IP being tested, an AT&T lookup failure, a DNS timeout, or a filtering decision reported with DNS-style wording. Verify the public egress IP before changing working DNS.
Common causes
A missing PTR on the public sending IP is a common sender-side cause. PTR records are controlled by the IP range owner or a reverse DNS operator with delegated authority. Normal DNS access for your domain does not grant control of the IP's reverse zone. If you send through an email platform, that provider controls reverse DNS. If you run your own MTA, the owner of your public IP range controls the reverse zone.
- Wrong IP tested: The team checks its inbound MX, private server address, or website IP instead of the public egress IP that connected to AT&T.
- Missing PTR: The sending IP has no reverse DNS record, so AT&T cannot map the IP to a hostname.
- Forward mismatch: The PTR hostname exists, but its A or AAAA answers do not include the same sending IP.
- PTR naming policy: A dynamic or residential hostname can trigger a policy rejection even when DNS resolves. Multiple PTR answers need individual forward checks; their presence alone is not a lookup failure.
- HELO problem: The SMTP HELO or EHLO uses an unqualified name or a hostname that does not resolve publicly.
- Receiver incident: An AT&T resolver or receiving host fails during the connection even though the sender's DNS is valid.
- Reputation pressure: Complaint, volume, or blocklist (blacklist) signals can cause a separate reputation rejection alongside a DNS error.
Use Suped's domain health checker to review domain authentication alongside the IP-level PTR checks. A clean domain result does not confirm reverse DNS for every outbound IP.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
How to identify which side is failing
First identify the public source IP AT&T saw. NAT, outbound gateways, and provider pools can make it different from the mail server's local address or the domain's inbound MX. If the rejection names an IP, test that exact IP. If failures follow one source IP across receivers, check its PTR and forward DNS first. If unrelated sources fail only at AT&T while their DNS checks pass, investigate a receiver-side incident. Record whether the failing connection used IPv4 or IPv6; a correct IPv4 PTR does not cover an IPv6 sender.
Likely sender-side
- Scope: Failures follow one sending IP, provider, pool, or MTA.
- DNS: PTR is missing or fails forward confirmation; DNS errors need separate investigation.
- Action: Ask the public IP owner or sending provider to correct reverse DNS.
Likely AT&T-side
- Scope: Unrelated senders report matching failures at the same AT&T receiving host in the same period.
- DNS: The named IP passes public PTR and forward checks; compare the actual outbound HELO separately.
- Action: Keep 4xx messages queued, gather evidence, and use AT&T's postmaster escalation path.
For a deeper walkthrough of lookup mechanics, compare your results with a reverse DNS lookup guide. Test through a public resolver so an internal DNS view or stale local cache does not hide a public DNS problem.
Reverse DNS and forward-confirmation checksbash
# Replace this documentation address with the IP AT&T rejected. SENDING_IP="203.0.113.25" dig -x "$SENDING_IP" +noall +comments +answer +authority # Replace this example hostname with a PTR hostname returned above. PTR_HOST="mail1.example.com." dig "$PTR_HOST" A +noall +comments +answer +authority dig "$PTR_HOST" AAAA +noall +comments +answer +authority # These commands use your configured resolver. # To select another resolver, add @RESOLVER_IP after dig. # Check every PTR hostname. Its A (IPv4) or AAAA (IPv6) # answers must include the public sending IP.
Check DNS errors and cached PTR answers
An empty dig +short result does not distinguish a missing PTR from a lookup failure. Read the DNS status and answer section, then compare two independent recursive resolvers. Ask the IP owner to check the authoritative reverse zone and the forward DNS administrator to check the PTR hostname's zone.
|
|
|
|---|---|---|
NXDOMAIN | The queried name does not exist. | Ask the reverse-zone owner to provision or correct the PTR. |
NOERROR with no PTR (NODATA) | The name exists but has no PTR data. | Check any CNAME target and ask the reverse-zone owner to publish the PTR. |
SERVFAIL | The resolver could not complete the lookup. | Check delegation, DNSSEC validation, and authoritative server availability. |
Timeout | No DNS response arrived. | Check resolver and authoritative reachability over UDP and TCP port 53. |
DNS responses that need different reverse DNS fixes.
After a correction, compare authoritative and recursive answers. Cached old records remain until their time to live (TTL) expires; a previously missing PTR can also be cached under the reverse zone's negative caching TTL. Lowering a TTL after the change does not shorten entries already cached by AT&T. Changing your router's DNS or flushing a laptop cache does not change AT&T's receiving resolver.
Read the SMTP response before changing DNS
An AT&T rejection such as "550 5.7.1 Connections not accepted from servers without a valid sender domain" or "Fix reverse DNS for [IP]" points to a connection identity check. The bracketed IP is the address to test. The wording does not mean the visible From domain needs a PTR record, and it does not tell you to change the domain's MX record. A non-delivery report (NDR) can wrap the receiver's reply in another code. Read the actual downstream AT&T SMTP response before deciding retry behavior.
- 4xx response: Treat it as a temporary deferral. Keep the message queued within the MTA's normal retry lifetime, slow retries, and check whether the failure clears without a DNS change.
- 5xx response: Treat it as a permanent delivery failure. Validate the named IP and correct sender-side DNS if needed. Send a new attempt after the cause is corrected or AT&T confirms recovery.
- Mixed results: Compare the same source IP, AT&T receiving hostname, recipient domain, response text, and timestamp. A successful retry supports an incident investigation but does not establish why the original lookup failed.
If the public sending IP has valid forward-confirmed rDNS and the rejection continues, collect the full SMTP transcript and use AT&T postmaster help for the current support route; it lists abuse_rbl@abuse-att.net for email blocklist requests. Include the exact response, UTC timestamps, source IP, AT&T receiving hostname, affected recipient domain, PTR output, and forward lookup output. Explain any cause already corrected. Request PTR changes from the public IP owner, rather than the mail blocklist contact.
Use retries without hiding the evidence
For temporary AT&T deferrals, leave messages in the normal queue and preserve every response. Avoid emergency DNS changes when the named IP already passes forward-confirmed reverse DNS.
Checks and fixes by failure type
Use the bounce text as a starting point, then map it to a concrete check. The table keeps the fixes compact. Provider means the party that controls the public sending IP range or mail platform.
|
|
|
|
|---|---|---|---|
Wrong IP | Egress IP | MTA admin | Test named IP |
No PTR | PTR | IP provider | Add rDNS |
Mismatch | A or AAAA | DNS admin | Include IP |
Bad greeting | HELO | MTA admin | Use FQDN |
Authentication issue (separate) | DMARC | Domain admin | Fix separately |
Reputation issue (separate) | Blacklist | Sender | Repair cause |
AT&T-only spike | SMTP pattern | Sender and AT&T | Queue 4xx; escalate |
Compact triage matrix for AT&T reverse DNS failures.
For sender-owned fixes, create the forward A or AAAA record first, then ask the IP owner to point the PTR at that stable mail hostname. Prefer one clear PTR answer per sending IP. A provider hostname can resolve to several sending IPs, but its forward answers must include the IP AT&T saw. The hostname identifies sending infrastructure; it does not have to match every customer's visible From domain.
Clean sender identity exampledns
25.113.0.203.in-addr.arpa. 3600 IN PTR mail1.example.com. mail1.example.com. 3600 IN A 203.0.113.25 # Outbound SMTP client command: # EHLO mail1.example.com
How Suped fits into the workflow
DMARC aggregate reports do not contain PTR results or SMTP transcripts. They describe messages that reporting receivers evaluated for DMARC, so a connection rejected before message transfer need not appear. Use reported source IPs and SPF or DKIM results as supporting context, then confirm the AT&T failure in MTA or sending-provider logs.
In Suped's DMARC and email authentication platform, inspect the affected sending source, compare SPF and DKIM results, and match the failure period against issue alerts before changing DNS. Suped's DMARC monitoring keeps source and authentication data visible, while Suped's blocklist monitoring helps identify reputation issues that need a separate fix.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Use Suped's source-level history to compare client sending sources and authentication results during the rejection period. For an MSP, compare those findings with each client's bounce logs to establish whether different senders failed at the same AT&T host. The multi-tenant view does not establish AT&T delivery outcomes by itself.
Best practical workflow
Validate the public sending IP and preserve the SMTP response first. Then use Suped alerts and source-level reporting to determine whether authentication or reputation problems accompany the AT&T failure.
Resolution playbook
The right fix depends on the evidence. Changing a valid PTR record during a receiver incident can introduce new DNS inconsistencies. Waiting during a real sender-side PTR failure keeps mail bouncing. Use the following sequence to avoid both mistakes.
- Capture evidence: Save the full bounce, UTC timestamp, public sending IP, AT&T receiving hostname, recipient domain, and downstream SMTP response code.
- Validate rDNS: Confirm the named IP has a PTR and that its hostname resolves forward to the same IPv4 or IPv6 address.
- Check the greeting: Make sure HELO or EHLO uses a stable, publicly resolvable fully qualified domain name.
- Verify authentication: Confirm SPF, DKIM, and DMARC results for the same sending stream, while treating them as checks separate from rDNS.
- Review reputation: Look for a complaint spike, unexpected volume, and blacklist listings.
- Handle the status code: Queue and slow 4xx deferrals within the normal retry lifetime; make a new 5xx attempt after correction or confirmed recovery.
- Escalate with evidence: Contact the public IP owner or AT&T postmaster path with the transcript, DNS results, and affected times.
After the reverse-zone owner publishes a correction, allow existing positive or negative cache entries to expire before judging delivery. If a sending provider owns the IP, open a support case with the exact IP and rejection sample. For a dynamic address or a provider that cannot provision suitable PTR records, route outbound mail through an authenticated SMTP relay. A static IP still needs correct rDNS and acceptable IP reputation.
Reverse DNS also interacts with broader sender identity. The rDNS and FCrDNS explanation separates the two lookup directions and shows why both matter.
Who should resolve the failure?
Ask the public IP owner or sending provider to fix a missing PTR, and the forward DNS owner to fix a hostname mismatch. For persistent AT&T-only failures after those checks pass, preserve the SMTP transcript and escalate through AT&T postmaster support. Keep temporary failures in the normal queue; resend permanent failures after the cause is corrected or AT&T confirms recovery.
Frequently asked questions
No. It often means the PTR is missing or mismatched, but it can also result from testing the wrong IP, an AT&T resolver or MX problem, a DNS timeout, or filtering reported with DNS-style wording.
The public IP range owner or a delegated reverse DNS operator controls PTR records. Ask your hosting provider, ISP, or sending platform which party manages that reverse zone. Access to the normal DNS zone for your domain is not enough.
No. DMARC does not control reverse DNS. Fix the PTR, forward DNS, or HELO problem separately. Use DMARC reporting to identify the affected source and any authentication gap occurring at the same time.
Test the public egress IP that connected to AT&T, preferably the IP printed in the rejection. Do not substitute the mail server's private address, the website IP, or the inbound MX address. If the connection used IPv6, test that IPv6 address and its own PTR and AAAA records.
Collect the downstream SMTP response, UTC timestamp, public sending IP, AT&T receiving hostname, recipient domain, PTR and forward DNS output with DNS status and TTLs, HELO name, available message authentication results, and examples showing whether the pattern is limited to AT&T.
