Is shared rDNS an issue for SaaS platforms sending emails on behalf of clients?

Key findings

• General acceptance: Many email experts and marketers indicate that shared rDNS is not inherently a major issue for deliverability, especially when email authentication protocols like SPF and DKIM are correctly configured for the client's sending domain. These authentication methods often carry more weight in determining an email's legitimacy.
• Reputation is key: The primary concern isn't the shared rDNS itself, but the overall sending reputation of the IP address and the SaaS platform's domain. If the SaaS provider has robust compliance practices and actively prevents abuse, the shared rDNS is less likely to be problematic.
• ISP variations: Some internet service providers (ISPs), particularly those handling consumer mail, may place a higher emphasis on rDNS consistency or use it as one of many signals for filtering. Specific issues, like those observed with Microsoft, can sometimes be linked to how particular ISPs interpret rDNS and IP reputation.
• Importance of proper rDNS naming: A generic or poorly configured rDNS record can raise red flags. It should be descriptive and clearly associate the IP with the sending entity (the SaaS provider) to maintain trust.

Key considerations

• Compliance and abuse prevention: SaaS platforms must have stringent policies and systems in place to prevent their clients from sending spam or engaging in other abusive behaviors. This is critical for maintaining a clean IP reputation, which indirectly benefits all senders using the shared rDNS. For more on managing IP reputation, see our guide on how sharing IP ranges affects deliverability.
• Dedicated vs. shared IP pools: When using multiple IP pools (e.g., separating clients by bounce rate or engagement), the shared rDNS will still resolve to the main SaaS domain for all pools. This means the overall reputation of that rDNS name is tied to the collective sending practices across all clients, even those on 'bad' pools.
• Monitoring deliverability: SaaS providers should diligently monitor their deliverability, especially at major ISPs, to identify any patterns related to rDNS or shared IP usage. Tools like Google Postmaster Tools can provide insights, and specific issues with Microsoft (Outlook) might require reviewing how email server security best practices including rDNS are applied by their filters.
• SPF and DKIM alignment: Ensuring strict SPF and DKIM alignment for client domains is paramount. This robust authentication helps legitimate emails bypass filters even if the rDNS is shared. For more on this, check out our best practices for email service providers regarding HELO, rDNS, and SPF.

Key opinions

• Focus on authentication: Marketers frequently emphasize that as long as SPF and DKIM are properly configured and aligned with their client's domain, the rDNS of the sending IP (even if shared by the SaaS provider) is generally not their primary concern for deliverability. They rely on the SaaS platform to handle the underlying infrastructure correctly.
• Reliance on SaaS reputation: There's an understanding that the SaaS platform's overall reputation and compliance efforts heavily influence their deliverability. If the SaaS provider effectively manages their IP pools and prevents abuse, marketers generally trust that the shared rDNS won't be a critical bottleneck.
• Awareness of ISP nuances: Some marketers acknowledge that certain ISPs, particularly those with stricter filtering like Microsoft, might still consider rDNS as part of their evaluation, leading to occasional deliverability challenges even with otherwise good sending practices.

Key considerations

• Segmented IP pools: Marketers recognize the benefit of SaaS providers using separate IP pools based on client sending behavior (e.g., bounce rates). While the rDNS may still resolve to the SaaS domain, this segmentation helps isolate potentially problematic sending, mitigating broader impact on their campaigns. This is aligned with best practices for isolating high-spam campaigns on shared IPs.
• Client domain authentication: Marketers are diligent about ensuring their client's domains are correctly set up with SPF and DKIM within the SaaS platform. This direct authentication of the 'From' domain is seen as crucial for sender identity. This aligns with advice on sending emails on behalf of someone else in SaaS.
• Monitoring blocklist status: While shared rDNS might not be a direct blocklist trigger, marketers are vigilant about monitoring their IP and domain reputation. Any blocklist listing, even on shared infrastructure, can impact their campaigns, reinforcing the need for SaaS platforms to manage their shared IP reputation carefully.

Key opinions

• Minimal impact if managed well: Experts generally agree that shared rDNS is not a significant problem for SaaS platforms if the service maintains good compliance practices and actively monitors for and prevents abuse. The focus shifts from the rDNS itself to the overall reputation of the sending IP.
• Evolving filter sophistication: Modern email filters are increasingly sophisticated at distinguishing between different senders using a shared platform. They can often separate the reputation of individual clients (based on their authenticated domains) from the underlying shared infrastructure, reducing the impact of a single bad actor on others.
• Generic rDNS is problematic: While shared rDNS is generally acceptable, experts caution against generic rDNS names that resemble consumer devices (e.g., 'cable box' rDNS). A professional, descriptive rDNS name is always preferred for better credibility.
• Consumer vs. business recipients: The type of recipient (consumer vs. business) can influence how strictly rDNS is evaluated. Consumer mailboxes, particularly at major ISPs like Microsoft, sometimes have different filtering policies where rDNS might play a slightly more significant role.

Key considerations

• Shared IP blocklist risks: Even with shared rDNS being acceptable, the underlying shared IP can still be blocklisted if a client's sending behavior is poor. While filters aim to separate, shared IPs carry inherent risks. SaaS platforms need robust blocklist monitoring for shared infrastructure.
• Importance of DMARC: Implementing a strong DMARC policy with alignment for client domains significantly strengthens sender identity and helps mitigate any perceived weaknesses from shared rDNS. DMARC validation is critical for modern email deliverability.
• Microsoft's filtering: Specific issues with Microsoft's filters often prompt discussions about rDNS. While not always the sole cause, MSFT's filters are known to be stringent, and ensuring all technical configurations, including rDNS, are optimal can help. It's important to understand the significance of rDNS and PTR records in this context.

Key findings

• Validation of sender identity: rDNS (PTR record) serves to map an IP address back to a domain name, acting as a crucial component in verifying the legitimacy of email senders. This check helps receiving mail servers confirm that the sending IP is associated with a real, identifiable domain.
• Anti-spam measure: Many email servers are configured to perform rDNS lookups as a primary spam filtering mechanism, rejecting messages from IP addresses that lack a valid rDNS record or have generic, suspicious entries. This is mentioned as a way to bypass spam filtering.
• Deliverability impact: Misconfigured or inconsistent rDNS records can lead to significant email deliverability problems, contributing to rejection or increased spam scoring. While not always the sole factor, it is a recognized part of email infrastructure validation.

Key considerations

• Alignment with other records: While rDNS maps IP to domain, other DNS records like A records (mapping domain to IP), MX records (mail servers), SPF, and DKIM are also critical for comprehensive sender authentication. All these records work in concert to establish trust.
• Importance for reputation: rDNS is a fundamental infrastructure configuration that email services use to validate that you are sending email on behalf of your domain. It contributes to the overall IP reputation and sender trustworthiness. For more context, see our page on reverse DNS resolution best practices.
• Shared responsibility model: In SaaS, while the client manages their domain's SPF/DKIM, the SaaS provider is responsible for the IP and its rDNS. This falls under a shared responsibility model where both parties contribute to deliverability, meaning the SaaS provider must ensure their shared rDNS is configured optimally.