What do PTR and HELO records mean in relation to AT&T email blocking, and whose responsibility are they?
Published 26 Apr 2025
Updated 28 May 2026
12 min read
Summarize with
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, or more commonly EHLO, is the hostname the sending mail server announces at the start of the SMTP conversation.
The direct translation of AT&T's message is simple: if the IP is on a shared mail server used by many customers, the generic ESP-owned PTR hostname can be acceptable. If the IP is dedicated to one sender or one brand, AT&T expects the PTR hostname and HELO hostname to match, or at least make sense together. When they do not, AT&T can treat that as a weak sender identity signal and block, rate limit, or keep watching the traffic closely.
For most brands sending through an ESP, the PTR and HELO setup is the ESP's responsibility because the ESP controls the mail transfer agent, the IP pool, and usually the reverse DNS zone delegated by 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.
The short answer
Plain-English translation
AT&T was saying that the sending IP has reverse DNS, but the name in reverse DNS might not match the name the mail server uses in its SMTP greeting. For shared MTAs, AT&T accepted the ESP's generic PTR. For dedicated MTAs, AT&T wanted the PTR hostname updated to match the HELO hostname.
- PTR: The reverse DNS name for a sending IP, such as mail1.esp-example.net.
- HELO: The hostname a sending MTA announces when it opens an SMTP session.
- AT&T concern: A mismatch can make the sending infrastructure look less clean, especially on dedicated IPs.
- Owner of the fix: Usually the ESP or whoever operates the outbound mail servers and IP space.
This does not mean the sender's visible From domain has to appear in the PTR. In many ESP setups it should not. A shared IP used by thousands of senders usually has an ESP-owned PTR, because one IP cannot have a unique reverse DNS identity for every customer using it. 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 SPF or DKIM matches the visible From domain. AT&T can still reject a message for server identity or reputation reasons even when DMARC passes.
How PTR and HELO work
Flowchart showing how a mailbox provider compares IP, PTR, HELO, 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. If the ESP owns or leases the IP block, the ESP normally has to set or request the PTR. A brand cannot fix reverse DNS by adding a TXT, CNAME, or A record in its own domain unless the IP owner has delegated that reverse zone to the brand, which is rare for managed ESP sending.
HELO is different. It is not a DNS record. It is a value configured in the outbound MTA software. The receiving server sees it during the SMTP session. A well-run setup uses a stable, fully qualified hostname, and that hostname resolves sensibly in DNS.
Simplified SMTP greetingtext
220 inbound.att.net ESMTP ready EHLO mta-01.mail.example.net 250-inbound.att.net Hello mta-01.mail.example.net MAIL FROM:<bounce@example.com> RCPT TO:<subscriber@att.net>
In that example, the HELO value is mta-01.mail.example.net. AT&T can compare that with the PTR returned for the connecting IP. If the connecting IP reverses to shared-123.esp.net but the server introduces itself as mta-01.mail.example.net, AT&T has to decide whether that difference is normal shared infrastructure or a suspicious inconsistency.
Shared vs dedicated MTAs
The shared versus dedicated part of AT&T's response matters because it changes what a reasonable PTR looks like. Shared infrastructure is meant to identify the ESP's platform. Dedicated infrastructure can identify the customer's assigned mail stream more specifically, although many ESPs still keep hostnames under their own operational domain.
Shared MTA
- PTR: Usually points to an ESP-owned hostname.
- HELO: Often uses a shared platform hostname.
- Expectation: Generic naming is normal if it resolves cleanly.
- Risk: Other senders share reputation on the same pool.
Dedicated MTA
- PTR: Should match or clearly relate to the HELO.
- HELO: Should be a stable fully qualified hostname.
- Expectation: The identity should look deliberate and consistent.
- Risk: Mismatch can slow unblocking or trigger more review.
|
|
|
|
|---|---|---|---|
PTR | IP to hostname | IP owner | Reverse identity |
HELO | SMTP server name | MTA operator | Greeting identity |
SPF | Allowed IPs | Domain owner | Auth check |
DKIM | Signed mail | Sender or ESP | Auth check |
DMARC | Domain policy | Domain owner | Policy signal |
Common ownership boundaries for PTR, HELO, and visible email identity.
This is why I separate the problem into two tracks. The sender should own domain authentication and reporting. The ESP should own the MTA identity. 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 will see for the same IPs that generated the bounces.
ESP escalation templatetext
Please confirm the outbound IPs used for AT&T traffic. For each IP, 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 forward-resolves to the same IP 5. Whether AT&T has a current DNSBL or policy block 6. Any recent complaint, bounce, or deferral spikes for AT&T domains
If the IP is dedicated, I would also ask whether the ESP can make the PTR and HELO identical, or at least use a matched naming pattern. Some ESPs have fixed naming standards and will not customize PTR hostnames. That is not automatically wrong, but it makes the explanation to AT&T harder if AT&T specifically asks for a PTR and HELO match.
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, the ownership changes. Then your infrastructure team or hosting provider owns the PTR, and your mail server configuration owns HELO. You still need your domain team for SPF, DKIM, and DMARC, but the AT&T comment points first at mail server configuration and reverse DNS.
Infographic showing sender domain, ESP MTA, IP owner, and mailbox provider responsibilities.
How to verify the values yourself
You can verify PTR with DNS tools, but HELO is harder because it is observed during an SMTP transaction. The most reliable path is still to ask the ESP for the value, then compare it with message headers, bounce evidence, and an independent send test.
- Collect the bounce: Save the full AT&T rejection text, including IP, SMTP code, and any DNSBL wording.
- Identify the IP: Confirm the exact outbound IP used for the blocked attempt.
- 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.
- Check reputation: Review blocklist and blacklist status, then compare that with bounce trends.
PTR lookup examplesbash
dig -x 203.0.113.25 +short host 203.0.113.25 nslookup -type=PTR 25.113.0.203.in-addr.arpa
A clean PTR result should return one hostname that looks intentional. The next useful check is forward-confirmed reverse DNS: the PTR hostname should resolve forward to the sending IP, or at least to the expected sending infrastructure. Some receivers care about this more than others, but mismatched or missing forward resolution gives postmaster teams a reason to push back.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
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 is useful here when you need a quick view of SPF, DKIM, DMARC, and message-level delivery signals before you go back to the ESP.
If the AT&T bounce references a DNSBL, treat it as both a configuration and blocklist problem. Suped's blocklist monitoring keeps that evidence in one place for escalation.
Why AT&T might mention this after removing the block
A postmaster response can be partly diagnostic and partly procedural. When AT&T says the block was removed but the reverse DNS should be corrected, it does not always mean PTR was the only cause of the block. It means the mail stream has an infrastructure detail AT&T wants cleaned up, or at least explained.
Common causes behind AT&T blocking investigations
Illustrative weighting of issues I usually separate during troubleshooting. Actual causes depend on the bounce data and traffic history.
Config
Reputation
Authentication
Volume
That is why I do not stop once the PTR question is answered. If the sending IP was on a DNSBL, I also check the complaint trend, unknown-user rate, spamtrap risk, list source, sending cadence, and authentication pass rates. AT&T does not disclose every signal in a postmaster reply, so the safest response is to 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.
The same distinction applies beyond AT&T. Gmail, Yahoo-family domains, Microsoft consumer mail, and other mailbox providers all use infrastructure identity as one part of filtering. The exact wording changes, but missing or inconsistent reverse DNS is still a basic deliverability risk.
Where Suped fits
PTR and HELO do not live inside DMARC, but they often show up during the same investigation. A sender sees AT&T bounces, checks authentication, checks blocklist or blacklist status, asks the ESP about infrastructure, and then has to turn all of that into a clear fix list. That is where Suped's product is strongest: it keeps authentication, domain health, blocklist monitoring, and issue detection in one workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A practical Suped workflow starts by confirming that SPF, DKIM, and DMARC are not adding noise to the AT&T issue, then uses blocklist and deliverability signals to decide whether the escalation is mainly about infrastructure or reputation. Suped cannot change an ESP's PTR record, but it can make the evidence clear enough that the right team owns the next action.
- Authentication checks: Confirm SPF, DKIM, and DMARC pass rates before blaming AT&T filtering.
- Issue detection: Surface configuration problems and practical steps to fix them.
- Blocklist visibility: Track domain and IP reputation signals across major blocklists and blacklists.
- Hosted controls: Use hosted SPF, hosted DMARC, and hosted MTA-STS when DNS management is slowing fixes.
- Multi-domain work: Manage client or brand domains from one MSP-ready dashboard.
Views from the trenches
Best practices
Ask for exact PTR and HELO values for the same IP before debating ownership with the ESP.
Treat shared and dedicated MTAs differently when reviewing reverse DNS naming in every review.
Keep bounce text, IPs, timestamps, and DNS evidence together during escalations.
Common pitfalls
Do not assume a visible From domain must appear in the PTR hostname during review.
Do not try to fix ESP reverse DNS by editing ordinary sender-domain DNS records.
Do not stop at PTR if a DNSBL, complaint spike, or traffic change is also present.
Expert tips
If the ESP controls the MTA and IP pool, make the ESP prove the values in writing.
If AT&T removes a block, still clean up the named risk before the next send window.
If the IP is dedicated, ask whether PTR and HELO can use one naming pattern first.
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 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
The practical answer
PTR means the reverse DNS identity of the sending IP. HELO means the hostname the sending mail server announces when it connects. AT&T was saying those names were acceptable for shared MTAs, but should match for dedicated MTAs. The fix usually belongs to the ESP because the ESP controls the sending servers, HELO configuration, and reverse DNS process for its IPs.
The sender's job is to ask for proof, keep SPF, DKIM, and DMARC clean, and monitor whether the AT&T issue is really gone after the DNSBL removal. If the ESP cannot explain the PTR and HELO values for the affected IPs, escalate inside the ESP. If the values are clean and the block returns, shift the investigation toward reputation, complaint rate, list quality, and traffic patterns.
