What domain should I use for a PTR record for shared IPs?
Updated on 7 Oct 2026: We clarified shared IP PTR naming, IPv6 checks and troubleshooting for cached DNS changes.
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 identifies the operator while keeping customer domains separate from the shared server's identity.
The hostname still has to be technically correct. The IP block operator or its reverse DNS delegate publishes the PTR in the reverse DNS zone. The PTR should return a hostname, that hostname should resolve forward to the same IP, and the SMTP HELO or EHLO should use a resolvable name controlled by the same operator. After changing rDNS, send a real message through Suped's 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 and deliverability reviews, including abuse escalations.
Use the operator's domain for shared IPs
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. Do 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 and forward DNS recordsdns
; Reverse DNS zone, managed by the IP operator 10.113.0.203.in-addr.arpa. IN PTR mta-a.pool.esp.example. ; Forward DNS zone, managed by the domain operator mta-a.pool.esp.example. IN A 203.0.113.10
203.0.113.10 and .example hostnames are reserved for documentation. Use the actual sending IP and an operator-controlled hostname when configuring DNS.
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 confirming ownership and stable, forward-confirmed DNS.
- Clear owner: The parent domain belongs to the ESP, hosting provider, or mail infrastructure operator.
- Clear role: The hostname makes the mail server role clear to support teams and receiver operators.
- Clear pattern: The same convention applies across the shared pool, so changes are easy to explain later.
Who can set the PTR record
The domain owner normally cannot add this PTR in the domain's ordinary DNS zone. Reverse DNS lives under in-addr.arpa for IPv4 or ip6.arpa for IPv6, and the organization controlling the IP block manages that zone. For hosted infrastructure, use the provider's reverse DNS control or ask its support team to publish the PTR.
IPv4 reverse-zone recorddns
10.113.0.203.in-addr.arpa. PTR mta-a.pool.esp.example.
A customer on a provider-managed shared mail IP usually cannot choose a customer-specific PTR, because a change affects the operational identity of the entire IP. If the provider will not establish valid forward and reverse DNS for an outbound mail server, do not send directly from that IP. Use a supported sending path or IP whose reverse DNS the operator can manage. A provider-owned PTR that differs from the customer's domain is expected on a shared IP and does not by itself require a dedicated IP.
- Forward DNS access: The domain owner can publish the A or AAAA record for the selected hostname.
- Reverse DNS authority: The IP block operator publishes the PTR, either directly or through a delegated reverse zone.
- Shared-pool control: The operator selects one stable infrastructure identity for the IP rather than one identity per customer.
Why the PTR should identify the ESP
A PTR (pointer) record maps an IP address to a hostname through 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 and receiver operations teams 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.
Shared-pool PTR problems
- Customer-owned: One client's domain appears responsible for traffic sent by other customers.
- An opaque hostname makes the operator harder to identify during a review.
- A missing PTR or a hostname without a matching forward record fails the reverse DNS check.
How to name shared IP pool hostnames
Use names that are clear and stable over time. 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 joke words or labels that obscure the operator. Keep customer brands out of the name unless the IP is dedicated to that customer.
Flowchart for choosing an operator-domain PTR hostname and checking FCrDNS on a shared IP.
Numeric labels and embedded IP octets are valid in hostnames. A provider default is also acceptable when it identifies the operator and passes forward-confirmed reverse DNS. Mail labels are an operational naming preference, not a universal receiver requirement, and changing the label alone does not repair a poor IP reputation.
|
|
|
|---|---|---|
ESP mail domain | Best default | Identifies operator |
Neutral infra domain | Good option | Keeps pools separate |
Customer domain | Dedicated only | Avoids misattribution |
Opaque name | Harder to review | Owner or role unclear |
Numeric host label | Valid | Keep the operator domain clear |
Shared IP PTR naming choices
Forward-confirmed reverse DNS and HELO/EHLO
Use forward-confirmed reverse DNS (FCrDNS): the IP resolves to the hostname, and the hostname resolves back to the same IP through an A record for IPv4 or AAAA record for IPv6. Google's email sender guidelines require valid forward and reverse DNS for sending IPs, including shared IPs. Publish direct A or AAAA records for the PTR target rather than a CNAME alias.
Use a resolvable fully qualified domain name (FQDN) for EHLO. RFC 5321 permits an address literal when the host has no meaningful domain name; using the PTR hostname is a practical default, but exact PTR/EHLO equality is not an SMTP requirement.
Forward and reverse DNS checksbash
# IPv4 sending address dig -x 203.0.113.10 +short dig mta-a.pool.esp.example A +short # IPv6 sending address, if used dig -x 2001:db8::10 +short dig mta-a.pool.esp.example AAAA +short
Run the forward lookup against the hostname returned by each reverse lookup. If it has several address records, the actual connecting IP must be among them. An IPv4-only sender does not need an AAAA record; every IPv6 address used to send mail needs its own PTR and matching AAAA record.
If a live test shows an outbound HELO of localhost, or another unresolvable name, correct the MTA configuration. A valid provider-owned hostname is acceptable. A DNS query cannot reveal the EHLO identity used in an outbound SMTP session, so send a real message and inspect SMTP logs or the receiving server's Received header. 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.
Use Suped's DMARC monitoring to review sending sources and SPF or DKIM domain alignment for customer traffic after the operator corrects PTR and HELO. DMARC aggregate reports do not verify PTR or provide a complete SMTP-session record; validate PTR and EHLO separately with DNS queries and SMTP logs.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Before adding customers to a new shared pool, check their authentication DNS with Suped's domain health checker to catch basic DNS mistakes. DMARC reports can then 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, resolvable mail hostname for the sending infrastructure.
- 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 domain that matches the customer's From domain under the configured DMARC alignment mode.
- DMARC: Confirm messages sent with the customer's From domain pass DMARC at receiving servers.
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.
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 tracks shared-pool IP listings on a blocklist (blacklist). Investigate affected customer traffic using authentication results and delivery logs; renaming the PTR does not remove a listing.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Send a real message through the shared pool and inspect the receiving server's connecting IP and EHLO, then check that IP's PTR and forward DNS. Review SPF, DKIM, DMARC and TLS separately. Repeat across the pool because one test covers only the IP used for that delivery.
If the test shows a mismatch, fix any broken PTR or forward record first, then correct an unresolvable EHLO name. Once the server identity is valid, 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.
Troubleshooting shared IP PTR records
Start with the public IP recorded by the receiving server. With an SMTP relay or NAT gateway, the relevant PTR belongs to the outbound IP that connects to the recipient. A website IP or inbound MX address needs this check only if it also sends mail.
|
|
|
|---|---|---|
Reverse DNS error or missing PTR | PTR for the actual connecting IP | Ask the IP operator to publish one stable mail hostname. |
PTR exists but FCrDNS fails | PTR hostname's A or AAAA records | Correct forward DNS so it includes the connecting IP. |
Old hostname still appears | Authoritative reverse DNS and cached answers | Confirm the operator published the change, then allow the previous TTL to expire. |
IPv4 works but IPv6 delivery fails | PTR and matching AAAA for the outbound IPv6 address | Have the operator fix IPv6 reverse DNS before using that address for mail. |
Valid reverse DNS but continued rejection | Exact SMTP error, shared IP reputation and authentication | Investigate the stated rejection reason; a new PTR name does not reset IP reputation. |
Shared IP reverse DNS symptoms and fixes
PTR changes and forward DNS changes have separate cache lifetimes. Previously missing records can also remain cached as negative answers. Recheck public DNS after the applicable TTL expires, then send another message and include its connecting IP and exact SMTP error when escalating to the operator.
Implementation checklist
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 and later IP expansion, including receiver questions.
- 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 direct A or AAAA records for each hostname that include its public outbound IP.
- Request rDNS: Ask the IP operator or reverse DNS delegate to set a PTR for every outbound IP, including IPv6 when used.
- Check HELO: Make the MTA announce a resolvable FQDN, preferably the PTR hostname.
- Test live mail: After the relevant DNS TTLs expire, test each outbound IP for FCrDNS, EHLO and authentication; inspect delivery errors 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 passes DMARC through aligned DKIM or SPF.
Views from the trenches
Hostname preferences reported in Email Geeks are operational observations, not universal DNS requirements. Numeric labels are valid, and a hostname's appearance alone does not establish abuse or a blocklist (blacklist) listing.
Best practices
Use an ESP-owned mail hostname so reviewers can identify who runs the shared IP pool.
Keep PTR, matching A or AAAA records and EHLO names stable so support teams can verify them.
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 treat digits or provider default names as failures without checking forward DNS.
Do not assume a valid PTR replaces SPF or DKIM domain alignment with the message's From domain.
Expert tips
Use operator-controlled names; numeric labels are valid when forward and reverse DNS match.
Reserve customer-branded PTR records for dedicated IPs or pools carrying only their traffic.
Test every outbound IPv4 and IPv6 address before moving customers onto a new shared pool.
Marketer view
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 view
Marketer from Email Geeks says random two-word hostnames can look like snowshoe patterns during abuse review.
2024-07-04 - Email Geeks
