How to Fix “Reverse DNS is Not a Valid Hostname” Error for Mail Servers

When running a mail server, proper DNS configuration is crucial for email deliverability. One common issue reported by tools like MXToolbox is the "Reverse DNS is not a valid hostname" error. This occurs when your PTR record (reverse DNS) doesn't match the hostname your mail server presents during SMTP communication.

In your case, the reverse DNS points to domain.com, while your mail server identifies itself as hostname.domain.com in the SMTP banner. This mismatch can cause:

Email delivery issues with strict receivers
Spam filtering problems
Failed authentication checks

The ideal setup should have:

PTR record: hostname.domain.com
A record: hostname.domain.com → server IP
SMTP banner: hostname.domain.com

Here's how a proper SMTP conversation should look:

220 hostname.domain.com ESMTP Postfix (Ubuntu)
EHLO PWS3.mxtoolbox.com
250-hostname.domain.com
250-PIPELINING
250-SIZE 10240000
...

For Postfix configuration (typically in /etc/postfix/main.cf):

# Set the mail server's hostname
myhostname = hostname.domain.com

# Set the domain name
mydomain = domain.com

# What name to show in SMTP greeting
smtpd_banner = $myhostname ESMTP $mail_name

For DNS configuration (example BIND zone file):

; Forward zone
hostname IN A 192.0.2.1

; Reverse zone
1.2.0.192.in-addr.arpa. IN PTR hostname.domain.com.

You can verify your setup with these commands:

# Check reverse DNS
dig -x your.server.ip +short

# Check SMTP banner
telnet your.server.ip 25

# Comprehensive check
nslookup your.server.ip

Using a CNAME for your mail server's A record (always use A record)
Having multiple PTR records for the same IP
Forgetting to update both forward and reverse DNS zones
Not allowing enough time for DNS propagation

Many email providers (especially Gmail, Yahoo, Outlook) perform strict checks on:

Forward-confirmed reverse DNS (FCrDNS)
SPF alignment
DKIM signatures

A proper reverse DNS setup is the foundation for these authentication mechanisms.

When MXToolbox reports "Reverse DNS is not a valid hostname," it typically means your PTR record doesn't match the expected convention for mail server configuration. The proper format should be a fully qualified domain name (FQDN) that matches your mail server's identity.

The RFC standards recommend that:

Reverse DNS (PTR) should resolve to the mail server's FQDN
The forward DNS (A/AAAA record) should resolve back to the IP
Both HELO/EHLO and PTR should preferably match

Example of correct configuration:

# Sample DNS zone file entries
mail.example.com.    IN A      192.0.2.1
1.2.0.192.in-addr.arpa. IN PTR mail.example.com.

Many administrators make these errors:

# Incorrect - pointing to base domain
1.2.0.192.in-addr.arpa. IN PTR example.com.

# Incorrect - missing FQDN
1.2.0.192.in-addr.arpa. IN PTR mailserver

To check your configuration:

# Linux/macOS
dig -x YOUR_IP_ADDRESS +short
host YOUR_IP_ADDRESS
nslookup YOUR_IP_ADDRESS

# Windows
nslookup -type=PTR YOUR_IP_ADDRESS

Ensure your /etc/postfix/main.cf contains:

myhostname = mail.example.com
mydomain = example.com
smtpd_banner = $myhostname ESMTP $mail_name

Your mail server should respond like this:

220 mail.example.com ESMTP Postfix
EHLO checking.domain
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
...

Not like this (which would indicate misconfiguration):

220 example.com ESMTP Postfix

You can create a simple bash script to validate your setup:

#!/bin/bash
IP="your.server.ip"
FQDN="mail.example.com"

# Check PTR
ptr=$(dig +short -x $IP)
if [ "$ptr" != "$FQDN." ]; then
  echo "ERROR: PTR record $ptr doesn't match $FQDN"
fi

# Check forward
forward=$(dig +short $FQDN A)
if [ "$forward" != "$IP" ]; then
  echo "ERROR: A record $forward doesn't match IP $IP"
fi

For AWS, GCP, or Azure:

AWS: Use Route53 for both forward and reverse zones
GCP: Configure Cloud DNS with both record types
Azure: Set up proper DNS zones in Azure DNS