Reverse DNS (PTR) for Email: Why It Matters and How to Set It

What Is Reverse DNS and Why Do Email Servers Care?

When you send an email, the receiving mail server does more than read the message. One of its first checks is a reverse DNS lookup: it takes your sending IP address and asks the DNS system what hostname maps to it. The answer lives in a PTR record (short for Pointer record), and if that record is missing, malformed, or mismatched, your email is likely to be rejected or sent straight to spam.

Forward DNS resolves a hostname to an IP (A or AAAA record). Reverse DNS does the opposite — it resolves an IP back to a hostname. The two should agree. If your PTR record says mail.yourdomain.com, then a forward lookup of that hostname should return the same IP. When they match, this is called a forward-confirmed reverse DNS (FCrDNS), and it is one of the oldest and most widely respected signals of a legitimate mail server.

Why PTR Records Matter for Deliverability

Mailbox providers like Gmail, Outlook, and Yahoo use PTR records as a basic trust signal. Here is what they are actually checking for:

• Existence: Does a PTR record exist at all? A sending IP with no PTR record is an immediate red flag. Many receiving servers will reject the connection outright at the SMTP level before even accepting your message.
• FCrDNS match: Does the hostname in the PTR record resolve forward back to the sending IP? A mismatch suggests misconfiguration or, in spam filters' eyes, deception.
• Generic vs. branded hostname: PTR records like 123-45-67-89.dynamic.isp.net look like residential or dynamic IP addresses, not dedicated mail infrastructure. Spam filters heavily penalize these. A clean hostname like mail.yourdomain.com signals intentional, configured sending.

Missing or generic PTR records are one of the most common reasons self-hosters and small senders see their email land in spam or get rejected, even when SPF, DKIM, and DMARC are all configured correctly.

Who Controls Your PTR Record?

This is where many senders get confused. You do not set PTR records through your domain registrar or your regular DNS provider. PTR records are controlled by whoever owns the IP address — almost always your hosting provider or VPS provider (e.g., Hetzner, Vultr, DigitalOcean, Linode, OVH).

Your domain registrar controls forward DNS for your domain. Your server host controls reverse DNS for the IP they have assigned to you. These are two separate systems, and both need to be configured.

How to Set Your PTR Record: Step by Step

Step 1: Choose your PTR hostname

Pick a hostname that matches what your mail server presents in its SMTP EHLO/HELO greeting. It should be a fully qualified domain name (FQDN) that you control, such as mail.yourdomain.com. Avoid generic or meaningless strings.

Step 2: Create the forward DNS A record

In your DNS provider's control panel, create an A record for your chosen hostname pointing to your sending IP. For example, mail.yourdomain.com → 203.0.113.10. This must be in place before or alongside the PTR record so the FCrDNS check passes.

Step 3: Set the PTR record with your hosting provider

Log in to your server or VPS control panel. Most major providers offer a field labeled "Reverse DNS" or "PTR record" directly in the network or IP settings section. Enter your chosen hostname (e.g., mail.yourdomain.com) and save. Changes typically propagate within minutes to a few hours, though full global propagation can take up to 24 hours.

If you cannot find this option, contact your hosting provider's support. Some providers require a support ticket to set PTR records, particularly for dedicated servers.

Step 4: Verify your configuration

Once propagation is complete, verify both directions:

• Run a reverse lookup on your IP: dig -x 203.0.113.10 — confirm it returns your chosen hostname.
• Run a forward lookup on the hostname: dig mail.yourdomain.com A — confirm it returns your IP.
• Check that your SMTP server's EHLO hostname matches the PTR hostname.

You can also use the free deliverability checker to audit your PTR record alongside your SPF, DKIM, DMARC, and blacklist status in one place.

Common Mistakes to Avoid

• Setting the PTR but forgetting the forward A record: The FCrDNS check will fail, and many spam filters treat this as worse than having no PTR at all.
• Mismatching the PTR hostname and EHLO string: Your mail server's EHLO greeting should match the PTR hostname exactly. A mismatch adds spam scoring points on many filters.
• Using a shared IP without PTR control: On some shared hosting environments, you may not have a dedicated IP, meaning you cannot set a custom PTR. If deliverability is important, a dedicated sending IP is worth the cost.
• Forgetting to update PTR after changing IPs: If you migrate servers or get a new IP, your old PTR configuration does not follow you. The new IP needs its own PTR record configured from scratch.

PTR Records in Context: The Broader Deliverability Picture

A correctly configured PTR record is necessary but not sufficient on its own. Receiving servers layer many signals: SPF authentication, DKIM signatures, DMARC policy, IP reputation, sending volume, engagement rates, and more. PTR is best understood as the foundation — without it, other good signals may not even get evaluated, because the connection can be rejected before authentication checks run.

For senders managing their own infrastructure, especially those on new or previously unused IPs, proper PTR configuration is the starting point. Services like Rainmail are built for senders who need hands-on guidance through exactly this kind of setup — including IP warm-up, authentication, and reputation management from day one.

Get the fundamentals right, verify them carefully, and your sending infrastructure will have the credibility to compete in increasingly strict inbox filtering environments.