What domain should I use for a PTR record for shared IPs?

Key findings

• PTR ownership: PTR records must be set by the owner of the IP address, typically the ISP or the ESP themselves, not the individual clients using the shared IP.
• Hostname clarity: The hostname specified in the PTR record should clearly identify the ESP and indicate it's a mail server (e.g., mail.esp.com, mta.yourcompany.com). It should avoid generic or dynamic-looking names.
• Consistency: A consistent naming scheme for all shared IP PTR records within a sending pool is recommended for better recognition by recipient servers and human reviewers.
• Reverse DNS matching: The PTR record should ideally match the hostname of the sending mail server, which in turn should have a corresponding A record pointing back to the IP. This is crucial for reverse DNS resolution.
• Deliverability impact: A properly configured PTR record that resolves back to a valid A record is a strong indicator of a legitimate sender, positively influencing email deliverability and helping to avoid email blocklists. Understanding PTR records is key for this.

Key considerations

• Provider-level naming: For shared IPs, the PTR record should point to a hostname owned by the ESP, identifying the sending infrastructure, not individual client domains. This distinguishes shared IP usage from dedicated IP setups.
• Avoid random patterns: Do not use automatically generated or random hostnames (e.g., banana-hotdog.esp.com), as these can be misidentified as snowshoe spam or dynamic DNS, leading to delivery issues.
• IP octet usage: While using parts of the IP address (e.g., mta-xx-yy.domain.com) in the hostname can be acceptable if done consistently, some receiving mail servers (like T-Online) may be sensitive to numeric patterns, preferring clear organizational identifiers.
• Organizational responsibility: The PTR record hostname should clearly identify the organization responsible for the email, which helps recipient mail servers and human investigators understand the source of the traffic.
• Monitoring and testing: Regularly check your PTR records and reverse DNS resolution to ensure they are correctly configured and recognized by major mailbox providers. This includes understanding how reverse DNS impacts deliverability.

Key opinions

• ESP domain preference: Many marketers agree that for shared IPs, the PTR record should point to a domain owned by the ESP itself, reflecting the mail server's identity rather than a specific client's domain. This helps standardize the setup for all users on the shared IP.
• Maintain ESP brand: The hostname in the PTR record should clearly indicate that it belongs to the ESP, reinforcing the legitimate source of the emails. This builds trust with recipient mail servers.
• Avoid dynamic appearance: There's a shared concern about hostnames that appear auto-generated or dynamic (like those with random words or patterns that resemble dynamic DNS), as these are often associated with spam and can trigger warnings from various tools or mailbox providers.
• Consistency is key: Implementing a consistent naming convention across shared IP pools is seen as a best practice to ensure uniformity and avoid confusion or suspicion from receiving systems.
• Mail server identification: Marketers emphasize that the PTR hostname should explicitly state its purpose, for example, by including mta- or mail to clearly signify it's a mail transfer agent.

Key considerations

• Reputation management: The chosen PTR domain affects the reputation of the shared IP. A domain with a good reputation (like the ESP's main domain) is preferred over a generic or potentially suspicious one. For more information on how reverse DNS impacts sender reputation, consult our guide.
• Shared IP context: Marketers need to remember that shared IPs mean shared responsibility. The PTR should reflect the collective identity of the sending service, not just one client's brand. Consider when to use a shared IP versus a dedicated one.
• Forward DNS match: It is essential that the chosen PTR hostname has a corresponding A record pointing back to the shared IP. This bidirectional resolution is a standard requirement for legitimate email sending.
• Potential for false positives: Even with seemingly correct configurations, some automated tools or mailbox providers may occasionally flag certain hostname patterns as suspicious. Marketers should monitor such warnings and understand their implications, as discussed on community forums like Spiceworks Community.

Key opinions

• ESP-owned hostname: Experts recommend that the PTR record for shared IPs points to a hostname that clearly belongs to the ESP and signifies its function as a mail server. For instance, mail13.esp.com or mail13.pool.esp.com are reasonable choices.
• Avoid random names: Hostnames composed of two random words, like banana-hotdog.esp.com, should be avoided as they can appear to be snowshoe spam to human reviewers and automated systems.
• Purpose over generation method: The key is whether the machine is intended to be a mail server, not whether its hostname was mechanically generated. It's important to differentiate between legitimate automated naming and compromised or throwaway instances.
• Human and automated checks: PTR hostname patterns are relevant for human investigation, dynamically assigned IP blacklists (or blocklists), and for some specific, less flexible mailbox providers.
• Provider-specific sensitivities: Some mailbox providers, like T-Online, are known to dislike PTR records with numeric patterns (e.g., parts of the IP) and require the PTR record to identify the organization responsible for the message.

Key considerations

• Identify your entity: The PTR record should unambiguously identify the ESP or the entity operating the shared IP pool, making it clear who is sending the mail. This aligns with best practices for reverse DNS.
• Consistency in naming: Use a consistent naming scheme for all mail servers in a shared pool to present a uniform and trustworthy image to receiving mail servers, as discussed in configuring reverse DNS for multiple IPs.
• Compliance with blocklists: Ensure your PTR hostname patterns are not mistaken for dynamically assigned IPs, which can lead to being listed on specific blocklists. A legitimate mta- prefix can help distinguish it from generic cloud instances.
• Human review: Consider how a human looking at your PTR record would interpret it, especially during an investigation or support request. Clarity helps build trust.
• Specialized requirements: Be aware of specific mailbox provider requirements. Some providers have stricter rules on PTR record content, which may necessitate careful consideration of your chosen hostname pattern to ensure optimal deliverability.

Key findings

• Core function: PTR records, also known as Pointer records, link an IP address back to its corresponding hostname or domain name, enabling reverse DNS lookups.
• Spam prevention: A crucial step for verifying the origin of emails and protecting against spam, PTR records ensure that a sending IP is legitimate and associated with a known hostname.
• Symmetry: For proper configuration, the PTR record should have a valid corresponding A record (forward DNS) for the hostname it points to. This matching is recommended to avoid SMTP Reverse DNS Mismatch.
• Format: PTR records are uniquely formatted, with IP addresses written backward followed by the .in-addr.arpa domain.
• Host ID: PTR records assign IP addresses to a hostname, facilitating the identification of the sending host.

Key considerations

• Authority: PTR records can only be created or modified by the entity that owns the IP address space, typically the Internet Service Provider or the data center.
• Matching hostname: For shared IPs, the PTR should match the sending server's hostname, which itself should be generic enough for multiple domains but specific to the ESP's mail infrastructure. This is critical for reverse DNS, as detailed in Leaseweb's knowledge base.
• Mail server relevance: PTR records are specifically important for mail servers, as many anti-spam systems perform reverse DNS lookups on incoming connections.
• Deliverability bottleneck: A misconfigured or missing PTR record is a common reason for emails being rejected, sent to spam, or otherwise failing to deliver, even with strong SPF and DKIM authentication.