What is rDNS and why is it important for email deliverability?

rDNS (reverse DNS) is a DNS record that maps an IP address back to a hostname. It's important for email deliverability because receiving mail servers use it as a preliminary check to verify that the sending IP is legitimate and not from a spam source or a compromised machine. While not the sole factor, it contributes to overall sender trustworthiness.

Can shared rDNS negatively affect my email reputation?

Generally, shared rDNS is not a major issue for email deliverability if other authentication records like SPF, DKIM, and DMARC are properly configured and aligned. However, if clients sharing the rDNS IP engage in poor sending practices, it can negatively impact the overall reputation of the shared IP and the SaaS domain it points to, potentially leading to blocklists or spam folder delivery.

How can SaaS platforms ensure good deliverability when sending for clients?

SaaS platforms should prioritize robust SPF, DKIM, and DMARC authentication for all client emails. They should also implement strict compliance monitoring, segment IP pools for different sender behaviors, and proactively monitor their sending reputation and IP addresses for any blocklist listings. Encouraging clients to adopt DMARC is also beneficial.

What role do SPF and DKIM play with shared rDNS?

SPF and DKIM are crucial for email authentication, even with shared rDNS. SPF verifies that the sending IP is authorized by the client's domain, and DKIM cryptographically signs the email to prove its integrity and origin. When these align with the client's domain, they provide strong signals of legitimacy that often outweigh the rDNS mismatch.

Should SaaS clients set up their own rDNS?

While not strictly necessary in most cases, some high-volume or enterprise clients may prefer to have dedicated IPs with rDNS that resolves directly to their domain. This offers the strongest signal of authenticity and provides maximum control over their specific sending reputation, completely decoupling it from the SaaS provider's shared rDNS.

Is shared rDNS an issue for SaaS platforms sending emails on behalf of clients? - Technical - Email deliverability - Knowledge base

Many SaaS platforms send emails on behalf of their clients, a common practice to facilitate customer communication. Often, these emails are correctly authenticated with Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records, which are set up on the client's domain. However, a question frequently arises: what if the IP address used for sending these emails has a reverse DNS (rDNS) record that resolves to the SaaS provider's main domain, rather than the client's domain? Does this shared rDNS pose a deliverability issue, especially when the originating IP is a dedicated one?

This is a nuanced topic in email deliverability. While proper SPF and DKIM alignment are paramount for authentication, rDNS plays a supporting role in establishing trust. We'll explore whether shared rDNS configurations truly hinder deliverability for SaaS platforms and what steps can be taken to ensure emails reach the inbox reliably.

Understanding rDNS in email sending

Reverse DNS, or PTR record, is essentially the opposite of a standard DNS A record. Instead of translating a domain name into an IP address, rDNS translates an IP address back into a domain name. Mail servers use rDNS as part of their initial checks to verify the legitimacy of the sending server. It acts as a rudimentary form of validation, ensuring that the IP address sending the email is associated with a legitimate hostname.

Many email servers and anti-spam filters perform rDNS lookups. If an IP address does not have a properly configured rDNS record, or if it resolves to a generic or suspicious hostname, the receiving server might flag the email as spam or even reject it. This is particularly true for servers that are strict about email authentication and source verification. For more details on its importance, see our guide on why reverse DNS is important.

When a SaaS platform uses dedicated IPs for sending, the rDNS for those IPs typically points back to the SaaS provider's domain. This is a common setup, even when individual clients are using their own domains in the From header and authenticating with their own SPF and DKIM. The question then becomes whether this mismatch (SaaS rDNS vs. client's From domain) causes deliverability issues.

Example rDNS lookupBASH

dig -x 203.0.113.45 PTR

When shared rDNS works

For the most part, shared rDNS is not a significant issue for SaaS platforms. Modern email authentication relies heavily on SPF, DKIM, and DMARC. As long as these records are correctly configured for the client's sending domain, and they align with the actual sending infrastructure, the rDNS of the sending IP often takes a secondary role in the overall deliverability assessment.

Mailbox providers have become increasingly sophisticated in how they evaluate incoming mail. They are adept at recognizing legitimate sending patterns from large SaaS providers, even when the underlying rDNS points to the SaaS platform rather than individual client domains. The key is that the primary authentication mechanisms (SPF and DKIM) confirm that the SaaS platform is authorized to send on behalf of the client's domain. We have a detailed guide on a simple guide to DMARC, SPF, and DKIM that clarifies these standards.

Therefore, if a SaaS platform ensures strong SPF alignment, DKIM signing, and preferably encourages their clients to adopt DMARC with proper alignment, the rDNS pointing to the SaaS domain is unlikely to cause widespread deliverability problems. Filters are now better at separating the reputation of individual customers using a shared infrastructure, as long as the authentication framework is robust.

Best practices for SaaS email

DMARC adoption: Encourage clients to implement DMARC, even at a p=none policy initially, to gain visibility and enforce authentication.
SPF alignment: Ensure the client's SPF record includes the SaaS sending IPs or mechanisms.
DKIM signing: Sign all emails with DKIM using a selector for the client's domain.
Reputation management: Implement robust monitoring and manage IP reputation for different clients, isolating high-risk senders.

Potential deliverability challenges

While shared rDNS is generally acceptable, there are edge cases where it can become a deliverability challenge. Some stricter mail servers or those with highly conservative spam filters might give a slightly lower score to emails where the rDNS does not perfectly align with the From domain, even with SPF and DKIM passing. Notably, some large mailbox providers, such as

Microsoft (Outlook, Hotmail), have historically shown a preference for stronger alignment indicators, including rDNS matching. One search result highlights how Microsoft Defender for Office 365 looks at reverse DNS in its spoof intelligence.

A more significant risk arises from shared IP pools where some clients (even with their own SPF/DKIM) engage in poor sending practices. If these bad customers generate high complaint rates or hit spam traps, it can negatively impact the shared IP's reputation. Since the rDNS points to the SaaS domain, this could reflect poorly on the SaaS provider's overall sending reputation. Our article on shared IP negative impacts delves deeper into this.

This reputation bleed can lead to increased deferrals, emails landing in the spam folder, or even an IP address (or range) being added to a public or private blacklist (or blocklist). Therefore, while shared rDNS itself isn't inherently a problem, the practices of all senders using that shared rDNS domain become crucial.

Advantages of shared rDNS for SaaS

Ease of setup: Clients don't need to configure rDNS, simplifying onboarding.
Centralized management: The SaaS provider controls the rDNS, ensuring consistency.
Cost-effectiveness: Often part of standard dedicated IP offerings from ESPs.

Disadvantages of shared rDNS for SaaS

Reputation correlation: Poor sending by one client can affect the rDNS domain's reputation.
Strict ISP filters: Some mailbox providers prefer stricter alignment, potentially impacting deliverability.
Limited granularity: Cannot isolate rDNS reputation per client.

Optimizing for improved inbox placement

To ensure optimal email deliverability for SaaS platforms sending on behalf of clients, even with shared rDNS, the focus should remain on a comprehensive deliverability strategy. Robust authentication with SPF, DKIM, and DMARC is the foundation. It's also important to monitor blocklists and your overall sender reputation actively. Our blacklist checker can help identify potential issues.

For clients who demand the highest deliverability or send sensitive transactional emails, considering a dedicated IP with specific rDNS that matches their domain can be an option. This provides the strongest signal of legitimacy. Our guide on rDNS impact and dedicated IP needs offers more insight.

Ultimately, a SaaS platform's reputation is built on the cumulative sending behavior of all its clients. Even with shared rDNS, maintaining strict compliance, proactive monitoring, and segmenting sender pools based on reputation will be far more impactful than focusing solely on rDNS alignment for every individual client domain.

Option	rDNS Configuration	Pros	Cons	Ideal For
Shared rDNS (SaaS Domain)	IP resolves to SaaS provider's domain (e.g., mail.saas.com)	Simple setup for clients, centralized control	Potential for reputation bleed from problematic clients, minor preference for strict receivers	Most general SaaS use cases, transactional and marketing email
Delegated rDNS (Client Domain)	IP resolves to specific client domain/subdomain (e.g., mail.clientdomain.com)	Strongest authentication signal, client's domain reputation fully tied to their sending	Requires client IT involvement, more complex management for SaaS provider	Enterprise clients with strict security, high-volume senders, dedicated IP users
Separate Sending Domains (SaaS Subdomain)	IP resolves to a SaaS subdomain dedicated to sending (e.g., outbound.saas.com)	Reputation isolation from main SaaS domain, still managed by SaaS	Requires additional DNS management, clients still use their domain for From header	SaaS providers wanting to segment internal sending reputation, bulk senders

Views from the trenches

Best practices

Maintain high sending hygiene and promptly remove inactive or problematic addresses.

Utilize DMARC reporting to gain insight into email authentication outcomes and potential issues.

Segment clients into different IP pools based on their sending volume and engagement metrics.

Actively monitor all sending IPs for any listing on major blacklists or blocklists.

Common pitfalls

Failing to enforce DMARC or proper SPF/DKIM alignment for clients’ domains.

Not having a clear policy for handling clients who consistently generate spam complaints.

Ignoring generic rDNS names that resemble consumer internet connections.

Overlooking reputation metrics specifically for Microsoft properties if issues arise there.

Expert tips

Focus on strong SPF, DKIM, and DMARC alignment as the primary trust signals.

Implement a system to separate "good" senders from "bad" senders within your IP infrastructure.

Recognize that mailbox providers are getting better at evaluating sender reputation at a more granular level.

Understand that rDNS is a foundational check, but not the sole determinant of deliverability for SaaS.

Expert view

Expert from Email Geeks says that shared rDNS is not a significant issue as long as the SaaS company has robust compliance practices and isn't allowing spammers to damage their domain reputation. They should also avoid generic rDNS names.

2022-04-13 - Email Geeks

Expert view

Expert from Email Geeks says that filters are improving at distinguishing between different customers on a single SaaS platform, which helps mitigate the impact of shared infrastructure on individual client deliverability.

2022-04-13 - Email Geeks

Final thoughts on shared rDNS and SaaS

In conclusion, shared rDNS is typically not a major issue for SaaS platforms sending emails on behalf of their clients, provided that core email authentication protocols—SPF, DKIM, and DMARC—are correctly implemented and aligned with the client's sending domain. Mailbox providers prioritize these authentication signals more heavily than a perfect rDNS match for every client's domain.

The primary concern for SaaS providers should be maintaining a pristine IP and domain reputation by rigorously managing sender quality. This involves having effective compliance practices to prevent abusive sending from any client within a shared IP pool, and continuous monitoring of deliverability metrics. By focusing on these critical aspects, SaaS platforms can ensure that emails sent on behalf of their clients consistently reach their intended recipients.