What is the ideal reverse DNS configuration for dedicated versus shared IPs?

For dedicated IPs, the rDNS (PTR record) should resolve to a hostname associated with your sending domain, such as mail.yourdomain.com . For shared IPs, it should typically resolve to a domain clearly identifying the ESP, like mta.esp-name.com . The key is clear identification of the responsible sender.

How can I identify a spammy ESP reverse DNS?

A spammy ESP reverse DNS often contains an IP address directly in the hostname (e.g., 1-2-3-4.generic-host.com ) or resolves to a domain completely unrelated to the ESP or your brand. You can identify it by performing a reverse DNS lookup and then visiting the resulting domain in a web browser, expecting it to lead to the ESP's or your organization's official website.

Is reverse DNS really that important for email deliverability?

Yes, a properly configured rDNS is crucial. Many mail servers and anti-spam filters perform rDNS lookups as a fundamental part of their verification process. A missing or misconfigured rDNS can lead to emails being flagged as suspicious, increasing the likelihood of them landing in the spam folder or being outright rejected. It directly impacts why your emails are going to spam .

Who is responsible for configuring reverse DNS records?

For dedicated IPs, you typically request your ISP or ESP (if they manage the IP) to create the PTR record. You provide the IP and the desired hostname. For shared IPs, the ESP manages the rDNS, and you usually don't need to do anything, beyond verifying their configuration.

Can a bad reverse DNS configuration lead to my IP being blocklisted?

While a generic or spammy rDNS alone might not immediately put you on a major blocklist (or blacklist), it significantly contributes to a lower sender reputation. This poor reputation can make it easier for your IP to be listed on blocklists when combined with other negative sending behaviors, like high bounce rates or spam complaints. It increases the risk of your IP getting blocklisted .

How should reverse DNS be configured for shared and dedicated IPs, and how to identify spammy ESP reverse DNS? - Sender reputation - Email deliverability - Knowledge base

Reverse DNS (rDNS) configuration is a critical, yet often overlooked, aspect of ensuring successful email deliverability. It acts as a verification step, helping receiving mail servers determine if the sending IP address is legitimate and associated with the domain claiming to send the email. This process is the opposite of a standard DNS lookup, which resolves a domain name to an IP address. Properly configured rDNS builds trust and can significantly impact whether your emails land in the inbox or the spam folder.

Understanding reverse DNS and its role in email deliverability

Every time an email is sent, the receiving mail server performs a series of checks to verify its authenticity. One of the first steps is often a reverse DNS lookup (also known as a PTR record lookup). This query seeks to confirm that the IP address from which the email originated has a corresponding domain name.

Mail servers and anti-spam filters use rDNS to build a picture of the sender's legitimacy. If the rDNS record is missing, incorrectly configured, or points to a generic or suspicious hostname, it raises a red flag. This can lead to your emails being flagged as spam, rejected outright, or routed to the junk folder. This is why reverse DNS is crucial for avoiding spam filters.

Many ISPs, including major mailbox providers, use rDNS as a foundational check for incoming mail. A well-configured rDNS record is a signal of a properly set up mail server and a responsible sender. It complements other email authentication protocols like SPF, DKIM, and DMARC by providing an additional layer of trust and verification for your email's origin. Without it, even perfectly authenticated emails can struggle with deliverability. In fact, Yahoo's best practices explicitly mention the importance of a valid PTR record.

The importance of rDNS

Spam filtering: Many spam filters reject emails from IPs without valid rDNS or with generic entries.
IP reputation: A correct rDNS record is a sign of a properly configured and legitimate sender, positively impacting your IP reputation.
Deliverability: Ensures your emails reach the inbox and are not mistakenly blocked by receiving servers.
Compliance: Many ISPs and blocklists (or blacklists) use rDNS as a basic check for compliance with email sending best practices.

Configuring reverse DNS for dedicated IPs

When you have a dedicated IP address for email sending, you have more control over its reverse DNS configuration. The ideal setup for a dedicated IP is to have its PTR record point back to your sending domain or a subdomain clearly associated with your email operations. For instance, if you send emails from yourdomain.com, the PTR record for your dedicated IP might be configured as mail.yourdomain.com or mta.yourdomain.com. This creates a clear and verifiable link between your IP, your sending domain, and your brand, enhancing trust with recipients and helping rDNS impact email deliverability with dedicated IPs.

Configuring rDNS for a dedicated IP usually involves making a request to your internet service provider (ISP) or email service provider (ESP) if they manage your IP space. You provide them with the desired hostname, and they create the PTR record on their DNS servers. It's crucial that the domain name specified in the PTR record (e.g., mail.yourdomain.com) also has a forward DNS (A record) that resolves back to your dedicated IP address. This bidirectional lookup is key for validation. I recommend reviewing ARIN's guidance on reverse DNS for more technical details.

Additionally, the HELO/EHLO hostname your sending mail server uses should match the rDNS entry. This consistency across all identifiers strengthens your sender reputation. For multiple IP addresses, each dedicated IP should ideally have its own unique PTR record that resolves to a relevant hostname.

Example PTR and A Record Configuration for a Dedicated IPDNS

PTR 192.0.2.10 mail.yourdomain.com.
A mail.yourdomain.com. 192.0.2.10

Reverse DNS for shared IPs

When sending emails through a shared IP pool, the reverse DNS setup is typically managed by your email service provider. In this scenario, the PTR record for the shared IP will usually point to a domain name owned by the ESP, such as

mta.mailgun.com or

somesubdomain.sendgrid.net. This is generally considered acceptable and doesn't inherently harm deliverability, provided the ESP maintains good sending practices and their rDNS clearly identifies them.

The key here is transparency and clarity. Receiving servers want to know who is responsible for the email. If the rDNS points directly to the ESP's domain, it establishes a clear chain of custody. While you won't have the same level of white-labeling or branding control as with a dedicated IP, a clear ESP-identifying rDNS is sufficient for most mailbox providers. This is often the reality for smaller senders or those with inconsistent volumes, where dedicated IPs may not be cost-effective. You can learn more about how shared rDNS affects deliverability.

The main challenge with shared IPs lies in the collective reputation of all senders using that IP. If other senders on the same shared IP engage in spammy behavior, it can negatively impact your deliverability, regardless of your perfect rDNS setup. Therefore, choosing a reputable ESP that actively monitors and manages its shared IP pools is paramount. The reverse DNS serves as an initial indicator of the ESP's overall diligence in managing its network and upholding good sending practices.

Identifying spammy ESP reverse DNS

Identifying a spammy ESP reverse DNS is crucial for protecting your sender reputation and deliverability. A red flag is any rDNS entry that is generic, contains an IP address, or points to a domain completely unrelated to the ESP or the sender. For example, an rDNS like 10-11-12-13.shittyvps.ovh.com or

ec2.aws.amazon.com for a non-AWS SES customer indicates a lack of proper configuration.

To check for spammy rDNS, you can perform a simple reverse DNS lookup on your sending IP address. Many online tools are available for this. Once you have the hostname, try visiting that domain in a web browser. A legitimate rDNS should resolve to the ESP's official website or a page clearly identifying them as the service provider. If it leads to a generic hosting page, an error, or, worse, an unsubscribe form (which can be a sign of a compromised or abusive sender), that's a significant warning sign.

A responsible ESP ensures that its rDNS (and therefore, the PTR record for its IPs) clearly identifies them as the sender or email service provider. This transparency is key for mail servers to establish trust. Any obfuscation or unrelated domain in the rDNS can lead to your emails being flagged by blocklists (or blacklists) and significantly hinder your email domain reputation.

Good rDNS example

For a dedicated IP 192.0.2.10:10.2.0.192.in-addr.arpa. PTR mail.yourdomain.com.

For a shared IP 203.0.113.5 from an ESP:5.113.0.203.in-addr.arpa. PTR shared-pool.esp-provider.com.

Verification: Resolves to your actual sending domain or a clear ESP domain.
Trust: Instills confidence in receiving servers about the sender's identity.
Branding (dedicated): Reinforces your brand's presence in email headers.

Spammy/bad rDNS example

For an IP 192.0.2.10:10.2.0.192.in-addr.arpa. PTR 192-0-2-10.generic-host.com.

For an IP 203.0.113.5 from a suspicious sender:5.113.0.203.in-addr.arpa. PTR random-ad-domain.xyz.

Genericity: Contains the IP address in the hostname or points to a generic hosting service.
Irrelevance: Resolves to a domain completely unrelated to the actual sender or ESP.
Spam indicators: May point to sites with unsubscribe forms, indicating potential abuse.

General best practices and common pitfalls

For dedicated IPs, the goal is always to achieve a strong, identifiable link between your sending IP and your legitimate domain. This best practice for reverse DNS ensures that recipients can easily verify your origin. Even if your ESP doesn't offer custom rDNS as part of their standard package, it's worth requesting it, as it signals a higher level of commitment to deliverability.

When using shared IPs, you have less direct control, but you can still mitigate risks by performing due diligence on your ESP. Regularly checking the rDNS of the IPs you send from, even if they are shared, can provide insights into your ESP's sending hygiene. If you identify a generic or spammy rDNS, it might indicate that the ESP isn't adequately managing their IP reputation, which could impact your emails.

Ultimately, the reverse DNS record should clearly identify a responsible party, whether that's your organization (for dedicated IPs) or your ESP (for shared IPs). This clarity is a fundamental aspect of establishing trust in the email ecosystem, helping to bypass spam filters and ensuring your messages reach their intended recipients. It’s a foundational piece of your email authentication puzzle, working alongside SPF, DKIM, and DMARC to build a robust sender identity.

Views from the trenches

Best practices

Always ensure your IP address has a valid PTR record that resolves to a legitimate domain, preferably one associated with your sending activity.

For dedicated IPs, the rDNS should align with your primary sending domain or a clearly identifiable sub-domain to enhance branding and trust.

For shared IPs, verify that your ESP's rDNS points to their legitimate domain, indicating proper infrastructure management.

The hostname used in your mail server's HELO/EHLO command should consistently match the rDNS entry for optimal deliverability.

Regularly monitor your rDNS configuration and IP reputation to promptly address any discrepancies or issues that arise.

Common pitfalls

Using generic rDNS entries that simply include the IP address itself or broad hosting provider names, which raises spam flags.

Not checking the rDNS of your sending IPs, especially when using a new ESP or a shared IP pool, leading to unexpected deliverability issues.

Having rDNS that resolves to a domain completely unrelated to your sending infrastructure or ESP, signaling suspicious behavior to mail servers.

Failing to ensure the A record of your rDNS hostname points back to your sending IP, breaking the crucial bidirectional lookup.

Choosing an ESP for shared IPs that lacks transparent or properly configured rDNS, indicating poor sender hygiene on their part.

Expert tips

Prioritize ESPs that offer transparent and well-configured rDNS for their sending infrastructure, even on shared pools.

Understand that while a custom rDNS for dedicated IPs is ideal, a clear ESP-identifying rDNS for shared pools is often sufficient for deliverability.

If an ESP doesn't offer custom rDNS for dedicated IPs, it's a point to consider, but not necessarily a sole reason to discard them if other services are excellent.

A well-configured rDNS makes it easy for recipient mail servers to identify a responsible party, which is either the ESP or the sender.

If the organizational domain from the rDNS record doesn't lead to a legitimate ESP or sender webpage, it is a strong indicator of bad behavior.

Expert view

Expert from Email Geeks says: If emails are sent through a shared pool, the reverse DNS should identify the ESP, while for a dedicated IP, it should identify the sender or the ESP.

2024-03-08 - Email Geeks

Expert view

Expert from Email Geeks says: Spammy ESPs often use reverse DNS domain names that do not connect to the ESP in any way, which is almost always a sign of bad behavior.

2024-03-08 - Email Geeks

Summary: Building trust through proper rDNS

Effective reverse DNS configuration is a non-negotiable element of robust email deliverability and maintaining a strong sender reputation. For dedicated IPs, you have the flexibility and responsibility to ensure your PTR records clearly link back to your sending domains, offering the highest level of trust and branding.

With shared IPs, while direct control is limited, the expectation remains that the ESP provides a clear and legitimate rDNS that identifies their infrastructure. The ability to identify spammy ESP rDNS is a powerful tool in your arsenal, allowing you to avoid providers that could inadvertently harm your deliverability. By prioritizing proper rDNS setup, you significantly improve your chances of reaching the inbox and building lasting trust with your recipients.