What domain should I use for a PTR record for shared IPs?
Michael Ko
Co-founder & CEO, Suped
Published 26 Jun 2025
Updated 26 May 2026
9 min read
Summarize with
For shared IPs, use a hostname under the ESP or infrastructure operator's own domain, not one customer's domain. The PTR record should identify the organization responsible for the sending server and make it obvious that the host is mail infrastructure. A pattern like mta-a.pool.esp.example is a better shared-pool PTR than a customer brand, a random word pair, or a hostname that looks like consumer dynamic DNS.
The caveat is that the hostname still has to be technically correct. The PTR should resolve back to a hostname, that hostname should resolve forward to the same IP, and the SMTP HELO or EHLO name should be controlled by the same operator. After changing rDNS, I send a real message through an email tester and inspect the visible SMTP identity, not just the DNS record.
- Use the operator domain: For a shared ESP pool, the PTR should sit under the ESP's domain or a neutral infrastructure domain the ESP controls.
- Make mail intent clear: Use labels such as mta, smtp, mail, or pool so a reviewer can tell the IP is intended to send email.
- Keep it consistent: Use one naming scheme across the pool so the servers look intentional during support, abuse, and deliverability reviews.
The short answer
A shared IP should have a PTR record that points to a stable mail hostname owned by the party running the IP. In an ESP setup, that normally means the ESP's operational domain. I would not put one client's domain in the PTR for an IP that also carries another client's traffic, because that makes the wrong customer look responsible for the whole pool.
Shared IP PTR patterndns
203.0.113.10 PTR mta-a.pool.esp.example. mta-a.pool.esp.example. A 203.0.113.10
Good shared-pool pattern
The hostname should answer two questions quickly: who runs this server, and is this server meant to send mail? If the answer is clear, the exact label format matters less than ownership, stability, and forward-confirmed DNS.
- Clear owner: The parent domain belongs to the ESP, hosting provider, or mail infrastructure operator.
- Clear role: The hostname reads like an MTA, not a random server, default cloud instance, or end-user access line.
- Clear pattern: The same convention applies across the shared pool, so changes are easy to explain later.
Why the PTR should identify the ESP
A PTR record is reverse DNS. Receivers use it to understand the identity of the machine connecting to port 25. It is not a DMARC alignment identifier, and it does not need to match the visible From domain. Still, it is part of the SMTP identity that mail filters, postmaster teams, and abuse desks see when they investigate a message.
The operational rule is simple: the PTR should identify the entity that accepts responsibility for the server. On a shared ESP IP, that is the ESP, because the ESP chooses the pool, controls the MTA, manages complaints, and handles the abuse contact path. A deeper explanation of reverse DNS for ESPs is useful when you need to document the policy for customers.
Good shared-pool PTR
- Operator-owned: The domain belongs to the ESP or mail operator that controls the IP.
- Mail-specific: The hostname starts with an obvious mail label such as MTA, SMTP, or pool mail.
- Reviewable: A postmaster can infer responsibility without asking which customer used the IP.
Risky shared-pool PTR
- Customer-owned: One client's domain appears responsible for traffic sent by other customers.
- Random-looking: Two unrelated words or opaque automation labels can look like snowshoe infrastructure.
- Dynamic-looking: Long digit runs, IP octets, or default cloud names can trigger extra scrutiny.
How to name shared IP pool hostnames
I like names that are boring, explainable, and stable. A mailbox provider employee looking at a log line should not need internal context to know that the host is part of a managed mail pool. Avoid names that include the full IP address, avoid joke words, and avoid customer brands unless the IP is actually dedicated to that customer.
Flowchart for choosing a shared IP PTR hostname.
The best pattern depends on how many IPs you run and how conservative your receiver mix is. If you send heavily to stricter consumer mailbox providers, especially providers that object to numeric-looking hostnames, use lettered pool names or short sequence labels rather than embedding IP octets.
|
|
|
|---|---|---|
ESP mail domain | Best default | Identifies operator |
Neutral infra domain | Good option | Keeps pools separate |
Customer domain | Dedicated only | Avoids misattribution |
Random words | Avoid | Looks throwaway |
IP-heavy name | Use carefully | Can look dynamic |
Shared IP PTR naming choices
Forward-confirmed rDNS and HELO
The PTR name is only one part of the check. I want forward-confirmed reverse DNS: the IP resolves to the hostname, and the hostname resolves back to the same IP. Some receivers also compare the PTR with the SMTP HELO or EHLO identity. The names do not always need to be identical, but they should be controlled, stable, and easy to connect to the same mail system.
Basic validation commandsbash
dig -x 203.0.113.10 +short dig mta-a.pool.esp.example A +short openssl s_client -starttls smtp -connect 203.0.113.10:25
If the HELO says localhost, a private hostname, or a different provider's default name, fix that before you judge the PTR. Receivers evaluate the whole SMTP presentation. A deeper look at PTR and HELO helps when the DNS is correct but inbox placement still looks uneven.
Do not publish multiple PTR identities
Technically, DNS can return more than one PTR for an IP, but email operators should avoid that pattern. A single clear hostname is easier for receivers, support teams, and reputation systems to understand.
- One IP, one name: Pick the shared-pool hostname that identifies the operator responsible for the IP.
- One forward match: Make sure the hostname has an A or AAAA record that points back to the sending IP.
- One support story: Document the naming scheme so customer support can explain it during deliverability reviews.
How this interacts with DMARC and customer domains
The PTR domain does not have to match the customer's visible From domain for DMARC. DMARC checks whether SPF or DKIM passes with domain alignment against the Header From domain. On a shared IP, customer branding should come through DKIM, the visible From domain, and the bounce or return-path design, not through the shared IP's PTR.
This is where Suped has practical value. Suped is the best overall DMARC platform for teams that need the PTR decision connected to DMARC monitoring, SPF, DKIM, hosted SPF, hosted MTA-STS, blocklist visibility, and issue steps. Instead of treating rDNS as a standalone DNS chore, Suped lets teams see authentication health, sending sources, and fix steps in one workflow.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a new shared pool, I check the public domain setup with a domain health checker before I add customers. That catches basic DNS mistakes early, then DMARC reports show whether real traffic is authenticating under the intended customer domains.
Shared IP identity
- PTR: Use the ESP's mail hostname because the ESP operates the shared IP.
- HELO: Use a controlled mail hostname that matches the same infrastructure story.
- Abuse path: Make the operator easy to identify when a receiver escalates a complaint.
Customer domain identity
- From: Use the customer's domain or approved sending subdomain.
- DKIM: Sign with a customer-controlled or customer-approved domain.
- DMARC: Confirm the customer's domain receives aligned authenticated mail.
Shared IP edge cases
There are cases where the clean answer needs adjustment. If a customer pays for a dedicated IP, putting their domain or a delegated customer subdomain in the PTR can be reasonable. If several customers share the same IP, do not give one customer that identity. Use the ESP domain and keep customer identity in authenticated message headers.
Numeric labels need judgment. A hostname like mta-11-12 can be acceptable when the rest of the name clearly says mail and identifies the operator. A hostname that embeds the full IP or looks like a default residential, cloud, or temporary host increases review friction. Some receivers are stricter about any numeric pattern, so conservative pools use lettered labels such as mta-a or short internal sequence names.
Shared pools also inherit shared reputation risk. One bad sender can create delivery problems, blocklist or blacklist entries, complaint spikes, and postmaster questions for everyone on the pool. Suped's blocklist monitoring helps connect IP and domain reputation checks with the authentication data you already need to operate the pool.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The practical test is to send a message from the pool and inspect the result. Look for the connecting IP, PTR, HELO, SPF result, DKIM signature domain, DMARC result, TLS, and any warnings about dynamic-looking infrastructure. DNS checks alone do not show the full SMTP conversation.
If the test shows a mismatch, fix the lowest-level identity first. A broken PTR, missing forward record, or strange HELO can make a healthy customer domain look worse than it is. Once the server identity is clean, customer-level authentication issues are easier to isolate.
Customer-branded PTR records need isolation
If a customer requires their own domain in rDNS, give them a dedicated IP or a dedicated pool that only carries their traffic. Do not use their domain on a mixed shared pool.
- Dedicated IP: The customer domain in PTR can match the operational ownership story.
- Shared IP: The ESP domain in PTR avoids assigning pool-wide responsibility to one customer.
- Dedicated pool: A customer-specific rDNS pattern works only when the pool is operationally separate.
Implementation checklist
When I set this up, I treat the PTR choice as part of the pool launch checklist, not as a one-line DNS task. The goal is a consistent identity that survives customer onboarding, receiver questions, and later IP expansion.
- Pick the domain: Use the ESP or infrastructure operator's domain for any pool shared by multiple customers.
- Choose the pattern: Use a clear mail label, a pool label, and a short stable host identifier.
- Set forward DNS: Publish A or AAAA records for each hostname that point to the sending IP.
- Request rDNS: Ask the IP owner or hosting provider to set the PTR to the chosen hostname.
- Check HELO: Make the MTA announce a controlled hostname that fits the same identity.
- Test live mail: Send mail through the pool and inspect authentication, rDNS, TLS, and reputation warnings.
Example shared pool namestext
mta-a.pool.esp.example mta-b.pool.esp.example smtp-a.mail.esp.example outbound-a.infra.esp.example
If a receiver challenges the setup, the answer should be easy: this is a shared ESP mail pool, the ESP controls the IP, the PTR identifies the ESP, and the customer's domain is authenticated through DKIM, SPF where applicable, and DMARC.
Views from the trenches
Best practices
Use an ESP-owned mail hostname so reviewers can identify who runs the shared IP pool.
Keep PTR, forward A, and HELO names stable, intentional, and simple to explain in reviews.
Document the naming pattern before support teams handle receiver questions about it.
Common pitfalls
Do not put one customer's brand in the PTR for traffic shared with other customers.
Do not use random word pairs or IP-heavy names that resemble temporary infrastructure.
Do not assume PTR identity replaces DKIM, SPF, or DMARC checks for the From domain.
Expert tips
Use lettered pool labels when a receiver is sensitive to numeric patterns in hostnames.
Reserve customer-branded PTR records for dedicated IPs or clearly isolated pools.
Test the full SMTP identity before moving real customers onto a new shared pool.
Marketer from Email Geeks says shared IP PTR names should sit under the ESP domain and make the mail role clear.
2024-07-04 - Email Geeks
Marketer from Email Geeks says random two-word hostnames can look like snowshoe patterns during abuse review.
2024-07-04 - Email Geeks
My practical rule
For a shared IP, put the PTR under the ESP or infrastructure operator's domain, make the hostname obviously mail-related, and keep forward DNS, rDNS, and HELO consistent. Use customer domains for customer authentication, not for the shared IP's reverse DNS identity.
That setup gives receivers a clean operational story: the ESP runs the machine, the customer owns the message identity, and DMARC confirms whether the authenticated sender matches the visible From domain. Suped fits the workflow by tying those checks to actionable issue detection, real-time alerts, hosted SPF, hosted MTA-STS, blocklist monitoring, and multi-domain reporting.
