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

If you run your own mail server, one of the first things a receiving provider checks is your reverse DNS. This guide covers how to set up a reverse DNS PTR record for email: what a correct record looks like, who actually controls it, and the forward-confirmed check that most PTR guides leave out.

A PTR record trips people up because you usually cannot set it in your own DNS zone — it lives with whoever owns your sending IP address. Get it right and you clear a baseline that major mailbox providers check, Gmail included. Get it wrong and your mail can be throttled or bounced before anyone reads a word.

What a reverse DNS PTR record actually does#

A PTR (pointer) record is the reverse of an A record. An A record maps a hostname to an IP address; a PTR record maps an IP address back to a hostname. Mail servers use both.

When your server connects to a provider like Gmail to deliver a message, the provider looks up the PTR record for your IP. If the IP has no PTR, or the PTR points to a generic hostname the provider distrusts, your reputation drops before the message is even scanned.

The catch is that a PTR alone is not enough. The provider also checks that the hostname in the PTR record has a matching forward record resolving back to the same IP. When both directions agree, that is forward-confirmed reverse DNS, or FCrDNS.

Forward-confirmed reverse DNS, in plain terms#

Forward-confirmed reverse DNS means the loop closes: the IP resolves to a hostname, and that hostname resolves back to the same IP. Google's Email sender guidelines require both halves for the IPs of your sending servers. One direction without the other still counts as a failure.

Do you actually need a PTR record?#

You need one if your server talks to receiving mail servers directly — a self-hosted box, a VPS running Postfix or Exim, or a dedicated sending appliance. Every IP that opens an SMTP connection to deliver mail should have a valid, forward-confirmed PTR.

You do not do this work yourself if you send through a third party. When you send through Google Workspace, Microsoft 365, Fastmail, or an email service provider, the connecting IP belongs to them, and their IPs already have correct reverse DNS. Your job is SPF, DKIM, and DMARC for your domain, not the PTR.

Shared and cPanel hosting sits in between. The shared IP already has a PTR the host controls, and you generally cannot change it. If that PTR does not match your domain, moving to a dedicated IP or a proper relay is usually the fix.

Before you start#

Gather these before you request or set anything. A missing item is the most common reason a PTR request comes back unactioned.

• A static, dedicated sending IP. Reverse DNS on a shared or dynamically assigned address is either out of your control or will change under you.
• Control of the forward DNS for the hostname you want to use — usually a subdomain like mail.example.com in your domain's zone.
• The exact hostname decided in advance. The PTR, the forward A record, and your server's HELO/EHLO name should all use the same fully qualified name.
• A way to reach whoever owns the IP: your host's support desk, a control-panel field, or a cloud provider's console or API.

How to set up a reverse DNS PTR record, step by step#

1. 1

   Confirm the IP is static and yours to use

   Reverse DNS only makes sense on a fixed, dedicated IP. If your address is dynamic or shared, sort that out first — request a static or elastic IP from your provider.

2. 2

   Create the forward record first

   In your domain's DNS, add an A record (and AAAA if you send over IPv6) for the hostname — for example mail.example.com pointing to your sending IP. The forward-confirmed check fails later if this does not exist.

3. 3

   Find who owns the IP

   Run a WHOIS lookup on the IP address. The organization listed controls the reverse (in-addr.arpa) zone, and therefore sets your PTR — often your host, ISP, or cloud provider, not you.

4. 4

   Request or set the PTR record

   Ask that owner to point the IP's PTR at your hostname, or set it yourself if they expose a control-panel field or API. The PTR value must be the same hostname you used in step 2.

5. 5

   Match your HELO/EHLO name

   Set your mail server to announce that same hostname at connection time. RFC 5321 requires the EHLO argument to be a valid fully qualified domain name (or an address literal); aligning it with your PTR and forward record is the widely expected best practice.

6. 6

   Verify forward-confirmed reverse DNS

   Confirm the IP resolves to the hostname and the hostname resolves back to the same IP. Both directions must agree before you call it done.

Where the PTR is set, by platform#

Who you ask depends on where the IP lives. The table below is accurate as of August 2026; provider consoles change often, so confirm the current path on the vendor's own documentation before you file a request.

The forward-confirmed check most PTR guides skip#

This is the step that separates a PTR that works from one that only looks set. Do not stop at "the IP has a PTR record." Check that the loop closes.

The receiver takes your sending IP, looks up its PTR to get a hostname, then looks up that hostname's A or AAAA record. If that forward lookup returns the same IP it started with, the reverse DNS is forward-confirmed. If the hostname is missing, or resolves to a different IP, it is not.

What to do when it doesn't work#

Most PTR failures fall into a handful of patterns. Match the symptom to the cause before you open a support ticket.

A faster way: skip reverse DNS entirely#

Reverse DNS is a property of the IP address that opens the connection to the receiving server — an outbound-sending concern that belongs to whoever runs your mail infrastructure. If you are not in the business of running a mail server, the simplest path is to not have a sending IP of your own at all.

AI Emaily is a client that sits on top of your existing Gmail, Outlook, or IMAP mailbox. It sends through your provider's outbound servers, so their reverse DNS applies, not yours — you never touch a PTR record. What it works on is the inbound side of the same inbox: triaging what arrives, drafting replies in your voice from a Personal Context brain you set, and spam protection that keeps unwanted mail out. It does not manage reverse DNS or sending reputation, so if you do run your own server or a bulk-sending platform, the steps above are still yours to do. We build AI Emaily.