Main Hero

rDNS

Reverse DNS, commonly referred to as rDNS, is the process of resolving an IP address back to a domain name. Unlike standard DNS queries that map a domain to an IP address, rDNS performs the inverse lookup using PTR records. This mechanism is widely used in email infrastructure, security systems, and network validation to confirm the identity of a server.

In email delivery, rDNS is a critical trust signal. When a receiving mail server accepts a connection, it performs a reverse lookup on the sending IP. If the IP resolves to a valid hostname and that hostname aligns with the sending server identity, the message is more likely to be accepted. If rDNS is missing or inconsistent, the email may be flagged as suspicious or rejected entirely.

rDNS does not authenticate the sender on its own but works as part of a broader validation framework alongside SPF, DKIM, and DMARC. Proper configuration ensures that the sending infrastructure appears legitimate and consistent across DNS layers.

Advanced

rDNS operates within reverse DNS zones such as in-addr.arpa for IPv4 and ip6.arpa for IPv6. The process relies on PTR records, which map an IP address to a fully qualified domain name. A best practice is forward confirmed reverse DNS, where the PTR record resolves to a hostname that also resolves back to the same IP via an A or AAAA record.

Alignment between rDNS, SMTP HELO or EHLO identifiers, and the sending domain is critical for deliverability. Many mail servers enforce strict checks, requiring consistent naming across all layers. For example, a sending IP should resolve to a hostname like mail.example.com, and that hostname should be used in the mail server’s HELO configuration.

In enterprise and hosting environments, rDNS is often controlled by the IP address owner. This introduces operational considerations when managing multiple outbound IPs, dedicated pools, or third party relays. Any inconsistency can degrade sender reputation and trigger filtering mechanisms.

Relevance

  • Validates server identity in email delivery workflows
  • Improves trust and reduces spam filtering risk
  • Supports compliance with email authentication standards
  • Required by many receiving mail systems for acceptance

Applications

  • Configuring reverse DNS for outbound mail servers
  • Aligning HELO or EHLO hostnames with DNS records
  • Managing dedicated IP pools for transactional email
  • Supporting secure communication across infrastructure

Metrics

  • rDNS resolution success rate in mail logs
  • Email deliverability and inbox placement rates
  • Rejection rates due to missing or invalid reverse DNS
  • Alignment checks across PTR, A records, and HELO

Issues

  • Missing rDNS causing immediate email rejection
  • Mismatch between hostname and IP reducing trust
  • Lack of forward confirmed reverse DNS validation
  • Limited control when IP ownership is external

Example

A company sends emails from a dedicated IP address. The IP has an rDNS entry pointing to mail.example.com. The domain mail.example.com resolves back to the same IP, and the mail server uses this hostname in its HELO configuration. This alignment ensures receiving servers recognise the sender as legitimate, improving deliverability and reducing spam classification.