Reverse DNS (rDNS) for Email Deliverability

What is reverse DNS?

Reverse DNS (rDNS) is the opposite of a normal DNS lookup. A regular DNS lookup takes a domain name and returns an IP address (A record). A reverse DNS lookup takes an IP address and returns a domain name (PTR record). This is used by receiving mail servers to verify that the IP address sending an email actually belongs to the domain it claims to be from.

For example: your email is sent from IP 203.0.113.50 claiming to be from yourdomain.com. The receiving server performs a reverse DNS lookup on 203.0.113.50. If that returns 'mail.yourdomain.com' — match, trust increases. If it returns nothing, or returns an unrelated hostname — red flag.

• rDNS (PTR records) are most important when sending from dedicated IPs.
• Cloud providers like Google Workspace and Microsoft 365 handle rDNS automatically — you don't need to configure it.
• Self-managed SMTP servers on dedicated IPs need PTR records configured by your hosting provider.

Why rDNS matters for deliverability

Many receiving mail servers (especially those running Postfix, Exim, or similar) perform a reverse DNS check as one of their earliest spam filters. A sending IP with no PTR record, or one that doesn't resolve back to a plausible mail server hostname, will fail this check and may be rejected outright or scored very low.

For senders on managed email providers (Google Workspace, Zoho, Microsoft 365), rDNS is not your problem — these providers maintain correct PTR records for their sending IPs. rDNS becomes your concern only if you're running your own mail server on a dedicated or VPS-hosted IP.

Checking your reverse DNS

To check your sending IP's PTR record: first, find your sending IP address (look in the email headers of a sent message — the 'Received: from' line). Then run a reverse DNS lookup using MXToolbox (mxtoolbox.com/ReverseLookup.aspx) or nslookup.

A healthy PTR record will return a hostname that matches or is related to your sending domain. A missing PTR record is a problem. A mismatched PTR (pointing to a completely different domain or a generic ISP hostname like '50.113.0.203.in-addr.arpa') suggests the IP wasn't configured for mail sending.

Command line reverse DNS lookup: # On Mac or Linux: nslookup 203.0.113.50 # Or using dig: dig -x 203.0.113.50 # Expected good output: 50.113.0.203.in-addr.arpa IN PTR mail.yourdomain.com # Problem output (no PTR record): ;; NXDOMAIN

What a healthy PTR record looks like: Your sending IP: 203.0.113.50 PTR record returns: mail.yourdomain.com Forward lookup of mail.yourdomain.com: 203.0.113.50 ← must match This is called a 'forward-confirmed rDNS' — the PTR and A record point to each other.

Configuring PTR records

PTR records are not configured through your domain registrar's DNS. They're configured by the owner of the IP address — which is your hosting provider (AWS, DigitalOcean, Hetzner, etc.). To set up a PTR record: log into your hosting provider's control panel, find the 'Reverse DNS' or 'PTR record' setting for your IP, and enter the hostname you want it to resolve to (e.g., mail.yourdomain.com). Verify the forward A record (mail.yourdomain.com → your IP) is also set at your domain registrar.

For most cloud providers, PTR record setup is straightforward: AWS EC2 allows PTR records through the 'Elastic IP' settings. DigitalOcean allows PTR records in the droplet settings (by setting the droplet name to your hostname). Hetzner has a reverse DNS section in the server control panel.

• Only applies to dedicated/VPS servers — managed providers handle this for you.
• The PTR hostname must match the forward A record exactly — this is 'forward-confirmed rDNS'.
• Some hosting providers charge extra for PTR record configuration — check before provisioning.