What is the best practice for reverse DNS resolution when sending email via an ESP?
Matthew Whittaker
Co-founder & CTO, Suped
Published 17 Apr 2025
Updated 19 Aug 2025
7 min read
Reverse DNS (rDNS) resolution is a crucial, yet often overlooked, aspect of email deliverability, especially when you're sending emails through an Email Service Provider (ESP). It's essentially the opposite of a regular DNS lookup. While DNS translates domain names into IP addresses, rDNS translates IP addresses back into domain names. This process helps receiving mail servers verify the legitimacy of incoming email, acting as a significant trust signal.
When an email server receives a message, one of its first checks often involves performing an rDNS lookup on the sending IP address. If the IP address doesn't resolve to a valid hostname, or if the hostname doesn't align with other sender information, it can raise a red flag. This can lead to your emails being flagged as spam or even rejected outright.
Understanding the best practices for rDNS resolution, particularly when leveraging an ESP, is vital for maintaining a strong sender reputation and ensuring your messages consistently reach the inbox.
How rDNS works with ESPs
At its core, rDNS relies on PTR records, which are set up by the owner of the IP address. For email sending, these records link the sending IP address back to a hostname. When you use an ESP, they own and manage the IP addresses from which your emails are sent. This means they are typically responsible for setting and maintaining the PTR records for those IPs.
Most ESPs will configure their shared IP addresses to resolve to their own domains. For example, an email sent from a SparkPost IP address will likely have an rDNS entry pointing to something like mta.sparkpostmail.com, not your specific sending domain. This is standard practice and generally does not cause deliverability issues because mail receivers expect ESPs to manage their own IP space.
A properly configured PTR record looks like this in a DNS lookup:
Example PTR recorddns
35.166.226.36.in-addr.arpa. IN PTR mta536b.sparkpostmail.com.
Some ESPs offer rDNS white labeling for clients with dedicated IP addresses, allowing the PTR record to resolve to a subdomain of the client's own domain. This can further enhance brand recognition and perceived trustworthiness, aligning the sending IP more closely with your brand. However, it's not strictly necessary for good deliverability if the ESP's default configuration is sound.
The importance of rDNS for deliverability
The primary reason rDNS is so important is its role in email authentication and anti-spam measures. Receiving mail servers use rDNS to verify that the IP address sending the email is associated with a legitimate hostname. If an IP address lacks an rDNS record or resolves to a generic hostname, it can be seen as suspicious. For a deeper dive into why this matters, consider reading about why reverse DNS is important for email sending.
Many major inbox providers (like Google and Yahoo) consider valid rDNS a prerequisite for accepting email, particularly from new or low-reputation senders. While it's not the only factor, a missing or misconfigured PTR record can trigger spam filters, leading to emails landing in the junk folder or being blocked entirely. This is why it's a fundamental part of proper email deliverability best practices.
The general recommendation is that the PTR record for a sending IP address should resolve to a hostname, and that hostname should also have a corresponding A record that resolves back to the original IP address. This forward-confirmed reverse DNS (FCRDNS) setup adds another layer of trust.
Scenario
rDNS Configuration
Deliverability Impact
ESP-managed rDNS (shared IP)
PTR record points to ESP's domain (e.g., mta.espname.com).
Typically high deliverability, as expected and trusted by inbox providers.
Client-managed rDNS (dedicated IP)
PTR record points to client's subdomain (e.g., mail.yourdomain.com).
Can further boost brand trust and deliverability, provided it's configured correctly with FCRDNS.
Missing rDNS
No PTR record found for the sending IP.
High risk of emails being rejected or sent to spam, as it's a strong indicator of suspicious activity.
Mismatched rDNS
PTR record resolves to a hostname that doesn't resolve back to the IP (no FCRDNS).
The way rDNS is configured depends largely on whether you're using shared or dedicated IP addresses with your ESP. This choice has significant implications for your control over rDNS and, consequently, your email deliverability strategy.
Shared IPs
Control: The ESP manages rDNS for all shared IPs. You have no direct control over the PTR record or the hostname it resolves to.
Configuration: rDNS typically resolves to the ESP's domain (e.g., sendgrid.net, mailgun.org). This is perfectly acceptable and expected by receiving mail servers.
Pros: Lower cost, immediate sending capabilities, ESP handles reputation management of the shared IP pool.
Cons: Your sender reputation is tied to other users on the same IP. This can be a concern if other users engage in spammy practices, leading to the IP being put on a blocklist (or blacklist).
Configuration: You can request that the PTR record resolves to a subdomain of your sending domain (e.g., mail.yourcompany.com). Remember to also have an A record for this hostname pointing back to the dedicated IP.
Cons: Higher cost, requires an IP warm-up period, your sending practices solely dictate your reputation.
For most senders using an ESP, the default rDNS configuration provided by the ESP for shared IPs is perfectly adequate. The reputation of the ESP's sending infrastructure usually ensures that mail is accepted without issue. However, for high-volume senders or those requiring maximum brand control, dedicated IPs with custom rDNS can be a beneficial investment.
Aligning rDNS with other authentication
While rDNS is important, it's just one piece of the email authentication puzzle. For optimal deliverability, your rDNS setup should work in harmony with other key authentication protocols, including SPF, DKIM, and DMARC. These protocols collectively tell receiving mail servers that your emails are legitimate and haven't been tampered with.
Many email servers also check that the HELO/EHLO hostname presented by the sending server matches the rDNS record. This adds another layer of verification. For a comprehensive overview of how these protocols work together, explore how SPF, DKIM, DMARC, and dedicated IPs affect deliverability.
The best practice for rDNS resolution when using an ESP is to ensure that your ESP has correctly configured PTR records for their sending IPs (whether shared or dedicated) and that these records maintain FCRDNS. If you opt for dedicated IPs, work closely with your ESP to set up rDNS white labeling to a subdomain of your choice, ensuring it's properly configured and aligns with your overall email authentication strategy.
Key takeaways for rDNS and ESPs
ESP responsibility: ESPs manage rDNS for their IPs, especially shared ones. Their rDNS typically resolves to their own domain.
Dedicated IP control: If you have a dedicated IP, you may be able to white-label your rDNS to a subdomain of your domain.
FCRDNS: Ensure the rDNS hostname resolves back to the IP address (Forward-Confirmed Reverse DNS).
Ultimately, the best practice is to confirm with your ESP that their rDNS is correctly configured for the IPs you're using. A properly set up rDNS record is a fundamental building block for email deliverability, supporting the overall legitimacy of your email sending infrastructure.
Views from the trenches
Best practices
Confirm that your ESP has properly configured PTR records for their sending IPs, ensuring FCRDNS.
If using dedicated IPs, work with your ESP to set a custom PTR record to a subdomain of your sending domain.
Always align your HELO/EHLO hostname with your rDNS record for consistent authentication signals.
Regularly monitor your domain's sending reputation and rDNS status as part of your deliverability routine.
Common pitfalls
Assuming rDNS is automatically handled correctly without verification with your ESP.
Trying to set rDNS for shared IPs, which is typically controlled by the ESP and can lead to issues if attempted.
Neglecting the forward lookup (A record) when custom configuring rDNS for dedicated IPs, breaking FCRDNS.
Not checking if your sending IP is on any public blocklist (blacklist) services due to rDNS or other issues.
Expert tips
Even if your ESP manages rDNS for shared IPs, ensure their configuration supports FCRDNS for optimal deliverability.
For dedicated IPs, a branded rDNS can enhance trust, but ensure consistent alignment with other DNS records.
If your rDNS is not matching your sender domain, this is normal behavior for ESP shared IPs, and generally not an issue.
Understanding the technical interplay between rDNS, HELO, SPF, DKIM, and DMARC is key to advanced deliverability troubleshooting.
Expert view
Expert from Email Geeks says that the rDNS for shared IP addresses is managed by the ESP. Attempting to set it to your own domain if it's a shared IP would be unusual and potentially problematic for other customers.
2019-04-24 - Email Geeks
Marketer view
Marketer from Email Geeks says that sending from an IP with rDNS that resolves to the ESP's domain does not typically generate outstanding issues.
2019-04-23 - Email Geeks
Ensuring optimal email delivery
For email senders using an ESP, the best practice for reverse DNS resolution is to ensure that the ESP maintains proper PTR records for their sending IP addresses. This typically means the rDNS will resolve to the ESP's domain, which is a widely accepted and trusted configuration by major mail servers. If you opt for dedicated IPs, you might have the opportunity to white-label your rDNS to your own subdomain, providing an additional layer of brand alignment and control.
Regardless of shared or dedicated IPs, the key is to ensure Forward-Confirmed Reverse DNS (FCRDNS) is in place, where the rDNS hostname also resolves back to the IP address via an A record. Coupled with strong SPF, DKIM, and DMARC authentication, a robust rDNS setup forms the backbone of reliable email deliverability.
SparkPost IP address will likely have an rDNS entry pointing to something like mta.sparkpostmail.com, not your specific sending domain. This is standard practice and generally does not cause deliverability issues because mail receivers expect ESPs to manage their own IP space.
Google and 
Yahoo) consider valid rDNS a prerequisite for accepting email, particularly from new or low-reputation senders. While it's not the only factor, a missing or misconfigured PTR record can trigger spam filters, leading to emails landing in the junk folder or being blocked entirely. This is why it's a fundamental part of proper email deliverability best practices.
