What do PTR and HELO records mean in relation to AT&T email blocking, and whose responsibility are they?
Published 26 Apr 2025
Updated 16 Oct 2026
14 min read
Summarize with
Updated on 16 Oct 2026: We clarified PTR ownership and EHLO checks, and added steps for escalating persistent AT&T blocks.
PTR and HELO are two pieces of mail server identity that AT&T can use when deciding whether to accept mail from a sending IP. A PTR record, also called reverse DNS or rDNS, maps an IP address back to a hostname. HELO and its extended form, EHLO, are SMTP greeting commands. The hostname after the command identifies the sending mail server at the start of the SMTP conversation.
The reported AT&T case illustrates the distinction: if the IP is on a shared mail server used by many customers, an ESP-owned PTR hostname can be normal. For the dedicated MTA in that case, AT&T asked for the PTR hostname and HELO hostname to match. A missing PTR, failed forward lookup, or unrelated server name can weaken sender identity and contribute to blocking, rate limits, or additional review.
For most brands sending through an ESP, the PTR and HELO setup is the ESP's responsibility because the ESP operates the mail transfer agent (MTA) and outbound IP pool, and can set the PTR or request it from the IP owner. The sender still owns the escalation: ask the ESP to confirm the exact sending IPs, the PTR values, the HELO value each server uses, whether the IPs are shared or dedicated, and whether AT&T has an active DNSBL or policy block against them.
Who is responsible for PTR and HELO?
What the reported AT&T reply means
The reported case describes AT&T accepting ESP-owned naming on shared MTAs, while asking for matching PTR and HELO names on the dedicated MTA. Treat that reply as guidance for the affected infrastructure, rather than a published rule for every AT&T sender.
- PTR: The reverse DNS name for a sending IP, such as mail1.esp-example.net.
- HELO: The SMTP greeting command; its hostname argument identifies the sending MTA. Modern servers normally use EHLO.
- AT&T concern: A missing, unresolvable, or unrelated identity can make the infrastructure look poorly configured. AT&T requested an exact match for the dedicated MTA in the reported case.
- Owner of the fix: Usually the ESP or whoever operates the outbound mail servers and IP space.
The sender's visible From domain does not have to appear in the PTR. A shared IP usually has an ESP-owned PTR that identifies the infrastructure for all its customers. On a dedicated IP, there is more room to make the server identity specific and consistent.
The practical issue is not DMARC domain matching. PTR and HELO are infrastructure checks. DMARC evaluates whether the SPF or DKIM authentication domain has the required relationship to the visible From domain. AT&T can still reject a message for server identity or reputation reasons when DMARC passes.
How PTR and HELO work
AT&T sender checks showing the connecting IP, PTR reverse DNS, HELO name, and reputation.
A PTR record lives under the reverse DNS tree controlled by the IP address owner, not under the sender's normal domain zone. IPv4 PTR records use in-addr.arpa, while IPv6 PTR records use ip6.arpa. If the ESP owns or leases the IP block, the ESP normally has to set or request the PTR. Adding an A or TXT record in the sender's normal domain zone does not change the PTR. If the IP owner delegates reverse DNS, the delegate must publish the PTR in that reverse zone. The domain DNS owner separately publishes the hostname's forward A or AAAA record.
The HELO or EHLO hostname is configured in the outbound MTA software, rather than published as a HELO DNS record. The receiving server sees it during the SMTP session. Use a stable, fully qualified domain name (FQDN) with working forward DNS for an outbound mail server.
Illustrative SMTP greeting, with server and client linestext
S: 220 inbound.example.net ESMTP ready C: EHLO mta-01.mail.example.net S: 250-inbound.example.net Hello mta-01.mail.example.net S: 250 SIZE 10485760 C: MAIL FROM:<bounce@example.com> S: 250 2.1.0 Sender accepted C: RCPT TO:<subscriber@example.net> S: 250 2.1.5 Recipient accepted
In that example, the EHLO hostname is mta-01.mail.example.net. AT&T can compare it with the PTR for the connecting IP. Different names can occur on shared infrastructure, but missing DNS or an unrelated name deserves investigation. RFC 5321 permits verification of the EHLO name against the client IP, but prohibits rejecting a message solely because that verification fails. Separate policy and abuse controls still apply; an exact PTR and EHLO match is not a universal SMTP requirement.
What a clean dedicated setup looks like
A dedicated sending IP should have a stable identity that works in both DNS directions and during the SMTP greeting. Exact PTR and EHLO matching is the clearest setup when the ESP supports it, especially after AT&T has requested that change. Forward-confirmed reverse DNS (FCrDNS) verifies that the PTR hostname resolves back to the sending IP. These are separate checks.
- Prefer one PTR per sending IP: Use one stable fully qualified hostname as an operational best practice. DNS itself permits multiple PTR records.
- Confirm FCrDNS: The PTR hostname's A or AAAA lookup should include the same sending IP used for the reverse lookup.
- Configure EHLO deliberately: Use a stable primary hostname with a direct A or AAAA record for the connecting address. Avoid a PTR target that is a CNAME or a website hostname that resolves to another IP.
- Check each address family: An IPv4 pass does not validate IPv6. Mail sent over IPv6 needs its own ip6.arpa PTR and forward AAAA confirmation.
Forward-confirmed reverse DNS exampletext
203.0.113.25 -> mta-01.mail.example.net mta-01.mail.example.net -> 203.0.113.25 EHLO mta-01.mail.example.net
If the IP owner changes the PTR, repeat both lookups after the previous PTR TTL has expired. Resolver caches can show the old answer until that TTL runs out, so capture the lookup time and resolver used when sending proof to the ESP or AT&T.
Shared and dedicated sending IPs
The shared versus dedicated part of the reported AT&T response matters because it changes what a reasonable PTR looks like. Shared infrastructure identifies the ESP's platform. Dedicated infrastructure can identify the customer's assigned mail stream more specifically, although many ESPs keep hostnames under their own operational domain.
A dedicated sending IP does not necessarily mean a dedicated MTA. An ESP can run several customer IPs through the same server software, so confirm whether its EHLO name is configured per server or per outbound route before requesting a change.
Shared sending IP
- PTR: Usually points to an ESP-owned hostname.
- HELO: Often uses a shared platform hostname.
- Expectation: Generic naming can be normal if it is stable and resolves cleanly.
- Risk: Other senders share reputation on the same pool.
Dedicated sending IP
- PTR: Should have a stable, forward-confirmed hostname.
- HELO: Should be a stable fully qualified hostname.
- Expectation: Use an exact PTR and HELO match when AT&T requests it and the ESP supports it.
- Risk: An unexplained mismatch can slow unblocking or trigger more review.
|
|
|
|
|---|---|---|---|
PTR | IP to hostname | IP owner or reverse DNS delegate | Reverse identity |
HELO | SMTP server name | MTA operator | Greeting identity |
SPF | Allowed IPs | Domain DNS owner, with ESP input | Auth check |
DKIM | Signed mail | MTA operator signs; DNS owner publishes key | Auth check |
DMARC | Domain policy | Domain DNS owner | Policy signal |
Common ownership boundaries for PTR, HELO, and visible email identity.
The useful ownership split is clear. The sender owns domain authentication and DMARC reporting. The ESP owns the MTA identity when it operates the sending service. If the ESP says reverse DNS exists, ask for the actual values instead of a yes or no answer.
What to ask your ESP
The fastest way to move this forward is to ask precise operational questions. Avoid asking whether rDNS is set up correctly in the abstract. Ask the ESP to show the values AT&T saw for the same IPs that generated the bounces.
ESP escalation templatetext
Please confirm the public outbound IPs AT&T sees, including any relay or NAT. For each IPv4 or IPv6 address, please provide: 1. PTR hostname returned by reverse DNS 2. HELO or EHLO hostname used by the sending MTA 3. Whether the IP is shared or dedicated 4. Whether the PTR hostname's A or AAAA result includes the same IP 5. Whether AT&T reports a current DNSBL, policy, or reputation block 6. The complete SMTP reply and whether it is a 4xx deferral or 5xx rejection 7. Any recent complaint, bounce, or deferral spike for AT&T domains 8. Timestamp with timezone, receiving AT&T MX hostname, and SMTP stage of failure
If the IP is dedicated, also ask whether the ESP can make the PTR and HELO identical. Some ESPs have fixed naming standards and will not customize PTR hostnames. If the ESP cannot change them, ask it to explain the architecture to AT&T and resolve the case-specific request. A similar naming pattern alone does not satisfy an exact-match request.
Do not try to fix PTR in normal DNS
Adding a record under your sending domain will not change reverse DNS for an ESP-owned IP. PTR is controlled through the reverse zone for the IP address. In most hosted sending setups, only the ESP, IP owner, or upstream provider can change it.
If you manage your own MTA, your infrastructure team configures HELO or EHLO. Your hosting provider or reverse DNS delegate sets the PTR. Your domain DNS team publishes the forward hostname records and domain authentication records, so coordinate both sides of a DNS change.
PTR and HELO responsibilities split between the sender, ESP mail server, IP owner, and AT&T.
How to verify the values yourself
You can verify PTR with DNS queries, but the outbound HELO or EHLO name must be observed during an SMTP session. Ask the ESP for logs for the affected route and compare them with receiver-added Received headers on a delivered test. A message rejected before DATA has no delivered message headers to inspect. Connecting to your server on port 25 shows its inbound 220 banner, which does not prove which EHLO name it sends outbound.
- Collect the bounce: Save the full AT&T reply, including the sending IP, SMTP code, timestamp with timezone, receiving MX, and SMTP stage.
- Identify the IP: Confirm the public outbound IPv4 or IPv6 address AT&T saw, after any NAT or relay. Your website or inbound MX IP can be different.
- Check reverse DNS: Run a PTR lookup for the outbound IP and record the hostname returned.
- Compare HELO: Ask the ESP for the HELO or EHLO hostname used by that same MTA and check its forward DNS.
- Check reputation: Review public blocklist (blacklist) results alongside AT&T's replies. A clean public check does not rule out an AT&T block.
Reverse and forward DNS lookup examplesbash
dig -x 203.0.113.25 +short host 203.0.113.25 nslookup -type=PTR 25.113.0.203.in-addr.arpa dig A mta-01.mail.example.net +short dig AAAA mta-01.mail.example.net +short dig -x 2001:db8::25 +short
These are documentation IPs and hostnames; replace them with the values for your sending route. The forward answer must include the same IP used for the reverse lookup. If +short returns nothing, rerun without +short to inspect the DNS status. NXDOMAIN means the queried name is absent; SERVFAIL means resolution failed and does not by itself prove the PTR is missing.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A real message test helps because it inspects the headers and authentication results of an actual email rather than DNS in isolation. Suped's email tester gives the sender a quick view of SPF, DKIM, DMARC, and message-level delivery signals before an ESP escalation. A successful test does not prove that the same IP and EHLO were used for AT&T.
If the AT&T bounce references a DNSBL, investigate the block and verify DNS separately. Suped's blocklist monitoring tracks supported public listings for comparison with AT&T's SMTP replies; it does not confirm removal from AT&T's own blocklist.
What to do if AT&T still blocks the IP
A correct PTR does not automatically remove an active AT&T block. Read the complete SMTP reply and use its leading status code, rather than a number embedded later in the diagnostic, to distinguish a temporary deferral from a permanent rejection.
|
|
|---|---|
4xx temporary failure | Let the MTA queue and retry with normal backoff. Investigate persistent deferrals instead of forcing repeated sends. |
5xx permanent rejection | Resolve the stated cause before a controlled resend. A policy block does not by itself mean the recipient address is invalid. |
Missing PTR or reverse DNS failure | Verify the exact public IP, PTR, and forward DNS. If public checks pass, send timed DNS evidence to the ESP for AT&T review. |
DNSBL/RBL or blocked-IP wording | Ask the ESP to investigate the affected IP and request AT&T review. Clean public blacklist results do not exclude an AT&T block. |
Use the status code and diagnostic wording together to choose the next action.
For persistent blocks, ask the ESP to own the escalation. AT&T's postmaster help lists abuse_rbl@abuse-att.net as its blocklist contact. Include the complete SMTP reply, affected public IPs, timestamps with timezone, receiving MX, and verified PTR and EHLO values. Describe the fixes already completed, then confirm acceptance with a small test through the same route.
Why AT&T mentions PTR after removing a block
A postmaster response can be partly diagnostic and partly procedural. When AT&T says the block was removed but reverse DNS should be corrected, it does not prove PTR was the only cause. It means the mail stream has an infrastructure detail AT&T wants corrected or explained.
AT&T's public postmaster help provides a blocklist contact, and its published email best practices do not state a blanket exact-match rule for PTR and HELO. Treat the reported exact-match request as case-specific guidance, and keep the complete SMTP error and case response as evidence for the affected IP.
Do not stop once the PTR question is answered. If the sending IP was on a DNSBL, also check complaint trends, unknown-user rates, spamtrap risk, list sources, sending cadence, and authentication pass rates. AT&T does not disclose every filtering signal in a postmaster reply, so fix the named issue and audit the surrounding sending behavior.
For more context on AT&T-specific reverse DNS failures, the related guide on AT&T rDNS failures covers the bounce patterns and resolution path in more detail.
Use Suped for authentication and escalation evidence
PTR and HELO often come up during an authentication investigation. Suped's DMARC reporting and email authentication platform helps review authentication results and configuration issues alongside supported public blocklist listings, so the team can prepare an ESP escalation.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped to identify authentication problems that need attention alongside the AT&T block. DMARC aggregate reports do not log every SMTP rejection, so keep ESP delivery logs for the affected AT&T attempts. PTR changes belong to the reverse DNS operator, and HELO changes belong to the MTA operator; authentication results and public blacklist evidence support that investigation.
- Authentication checks: Review available SPF, DKIM, and DMARC results alongside the AT&T SMTP failure logs.
- Issue detection: Record configuration problems and the steps needed to fix them.
- Blocklist visibility: Monitor supported public IP and domain listings, then compare them with AT&T's own replies.
- Escalation evidence: Keep authentication status and reputation findings with the affected domain.
Views from the trenches
Best practices
Ask for exact PTR and HELO values for the same IP before debating ownership with the ESP.
Distinguish dedicated IPs from dedicated MTAs before asking the ESP to change naming.
Keep full AT&T replies, sending IPs, timestamps, and DNS evidence together for escalation.
Common pitfalls
Do not assume the visible From domain must appear in a shared IP's PTR hostname during setup.
Do not try to fix ESP reverse DNS by adding records to your ordinary sending domain.
Do not stop at PTR if AT&T still reports a block or sending behavior remains suspect.
Expert tips
If the ESP controls the MTA and IP pool, ask for the actual PTR and EHLO values in writing.
If AT&T removes a block, still clean up the named risk before the next send window.
For a dedicated IP, request an exact PTR and EHLO match when AT&T explicitly asks for it.
Marketer view
Marketer from Email Geeks says a PTR record tells receivers which hostname belongs to the connecting IP, while HELO is the name the server announces during the SMTP session.
2024-01-30 - Email Geeks
Marketer view
Marketer from Email Geeks says AT&T's note likely means the PTR hostname and the SMTP greeting did not match, which points first to the ESP's mail server setup.
2024-01-30 - Email Geeks
Frequently asked questions
No. PTR identifies the sending IP's server identity, not necessarily the visible From domain. On shared ESP infrastructure, the PTR usually belongs to the ESP.
No universal SMTP rule requires an exact match. Matching names simplify a dedicated setup when the hostname resolves back to the sending IP. If AT&T explicitly requests a match, ask the ESP to implement it or explain its shared architecture to AT&T.
Usually no. PTR is controlled through the reverse DNS zone for the IP address. For ESP sending, the ESP or IP owner normally has to change it. You can manage it yourself only if the IP provider gives you a reverse DNS control or delegates the reverse zone; editing your normal domain zone is insufficient.
No. Removal addresses the current block, but it does not prove the underlying cause is gone. Confirm the named infrastructure fixes, then verify acceptance with a small test on the affected route. Public blocklist checks alone cannot confirm AT&T removal.
No. DMARC checks whether the SPF or DKIM authentication domain has the required relationship to the visible From domain. PTR and HELO are separate infrastructure signals used during SMTP filtering.
