Reverse DNS (PTR) for Email Explained (2026)

Reverse DNS maps an IP address back to a hostname, and for email it is one of the quiet make-or-break signals of whether your mail is trusted or blocked. Where forward DNS turns a name into an IP, reverse DNS does the opposite using a PTR record, and mailbox providers check it on every connection. Since 2024 it is a hard requirement: Google and Yahoo both reject mail from sending IPs without valid reverse DNS. This guide explains what reverse DNS for email is, how a reverse DNS lookup and the PTR record work, who actually controls it, and how to get it right. It complements the authentication standards in our email authentication hub.

What is reverse DNS?

Reverse DNS is the process of resolving an IP address to a hostname, the mirror image of the normal “forward” lookup. It works through a PTR record published in a special reverse zone — in-addr.arpa for IPv4 and ip6.arpa for IPv6. When a receiving mail server accepts a connection, it performs a reverse DNS lookup on the connecting IP to see what hostname claims it. The foundational best practice is RFC 1912, which states that every IP address should have a matching PTR record and warns that missing reverse DNS can cause loss of service “similar to not being registered in DNS at all.”

How reverse DNS works for email

Receivers do not just check that a PTR record exists — they check that it agrees with forward DNS. This two-way check is called Forward-Confirmed reverse DNS (FCrDNS):

1. A reverse DNS lookup on the sending IP returns a hostname (the PTR record).
2. A forward lookup of that hostname’s A/AAAA record must resolve back to the original IP.
3. If the loop closes, FCrDNS passes; if the two disagree, it fails.

Many servers also compare the PTR hostname against the name the sender announces in its SMTP HELO/EHLO greeting. The closer these three agree — PTR hostname, forward record, and HELO name — the more trustworthy you look.

PTR record syntax and a reverse DNS example

A PTR record lives in the reversed-IP zone and points to a hostname. For the IPv4 address 192.0.2.1, the octets are reversed and suffixed with .in-addr.arpa:

1.2.0.192.in-addr.arpa.   IN PTR   mail.example.com.
mail.example.com.          IN A     192.0.2.1     ; forward record must match

The two records together form the closed loop FCrDNS requires. IPv6 works the same way but uses 32 reversed hex nibbles under .ip6.arpa. Note one rule that trips people up: a PTR record must point to a real hostname with an A/AAAA record — it can never point to a CNAME.

Who controls your reverse DNS

This is the single most important and most misunderstood point: you do not set a PTR record in your domain’s normal DNS zone the way you set SPF or MX. Reverse DNS is controlled by the owner of the IP address — your hosting provider, cloud platform or ISP — because they hold the reverse zone for that IP block. Depending on your setup you configure it by:

• Setting it in your VPS or cloud control panel (most providers expose a “reverse DNS” or “PTR” field per IP).
• Opening a support ticket with your ISP or host to set the PTR for your sending IP.
• Having a reverse zone delegated to you for larger IP blocks such as a /24.

On shared hosting you usually cannot customise the PTR at all — it belongs to the platform’s IP. This is exactly why reputable email service providers configure FCrDNS for you on their sending infrastructure.

Forward DNS vs reverse DNS

The two directions of DNS do opposite jobs, and getting reverse DNS for email right means making them agree:

FCrDNS is simply the requirement that these two tables line up: the PTR’s hostname, looked up forward, must come back to the same IP. When they disagree, receivers treat the sender as suspect — which is the whole reason reverse DNS for email is checked on every connection.

Dedicated vs shared IPs

Whether you can control reverse DNS at all depends on your sending setup. On a dedicated IP — a VPS, a dedicated server, or a dedicated IP from an email platform — the address is yours alone, so you can (and must) set a meaningful PTR that points to a hostname on your own domain. On a shared IP, many senders use the same address, so the platform sets a single generic PTR that applies to everyone; you cannot customise it, and you inherit whatever reputation the pool has. Neither is automatically better: a well-managed shared pool from a reputable provider often delivers better than a cold dedicated IP with no sending history. What matters is that someone has configured correct FCrDNS on the IP you send from — which on a reputable email platform is handled for you.

How to check your reverse DNS

Verifying reverse DNS takes two quick lookups. First, run a reverse DNS lookup on your sending IP — dig -x 192.0.2.1 or host 192.0.2.1 — and confirm it returns a meaningful hostname on your domain rather than a generic ISP string. Second, look up that hostname’s A/AAAA record and confirm it resolves back to the same IP, closing the FCrDNS loop. It is also worth checking what your mail server announces in its SMTP HELO greeting and making sure that name agrees too. Do this after any change to your sending infrastructure, and re-check IPv6 separately if you are dual-stack, because a host can have perfect IPv4 reverse DNS and no IPv6 PTR at all.

Why bulk senders get blocked without reverse DNS

Reverse DNS is no longer a nice-to-have. Google’s sender guidelines, enforced since February 2024, require every sending IP to have valid forward and reverse DNS, with the IP matching its PTR hostname. Yahoo requires “valid, meaningful, non-generic” reverse DNS that reflects your domain and explicitly rejects dynamic-looking entries. Beyond the big mailbox providers, many mail servers and reputation systems (such as Spamhaus PBL) penalise or refuse IPs that have no PTR, a generic provider-default PTR, or a PTR that fails FCrDNS.

Reverse DNS pitfalls and best practices

• No PTR at all — the most basic failure; the IP looks anonymous and untrusted.
• Generic or dynamic PTR like host-203-0-113-5.isp.net — almost as bad as none, because it signals an ISP pool rather than a real mail server.
• FCrDNS mismatch — the PTR hostname does not forward-resolve back to the IP.
• Missing IPv6 PTR on dual-stack servers — a very common cause of Gmail rejections when mail goes out over IPv6.
• Best practice: give each sending IP one meaningful PTR on a real subdomain of yours, make the PTR hostname, the HELO banner and the forward record all agree, set reverse DNS on IPv6 as well as IPv4, and pair it with SPF, DKIM and DMARC.

Reverse DNS and the 2024 bulk-sender rules

Reverse DNS moved from “good hygiene” to “hard requirement” with the 2024 sender rules, and it is worth understanding where it sits among them. Google’s requirements distinguish two tiers. Every sender, regardless of volume, must have valid forward and reverse DNS on its sending IP, with the IP matching the PTR hostname — there is no minimum-volume exemption from this one. Senders of roughly 5,000 or more messages a day to personal Gmail accounts must additionally publish SPF, DKIM and DMARC, keep spam complaints low, and offer one-click unsubscribe. In other words, reverse DNS is the one authentication-adjacent requirement that applies to all senders, which is why a missing or generic PTR is such a common and avoidable cause of blocked mail.

Yahoo frames it similarly, requiring reverse DNS that is valid, meaningful and non-generic — explicitly rejecting the dynamic-looking hostnames that residential and unconfigured server IPs carry by default. The practical takeaway is that reverse DNS for email is not something to bolt on after a deliverability problem appears; it is part of the baseline you establish before you send your first campaign from a new IP, alongside the rest of your authentication. Treat it as the entry ticket: without it, the more advanced standards cannot compensate, because many receivers will not even get as far as evaluating them.

Related reading

• SPF records guide
• DKIM records guide
• DMARC records guide
• BIMI records guide
• MX records guide

Reverse DNS FAQ

Do I set the PTR record in my domain’s DNS like SPF or DKIM?

No. A PTR record lives in the reverse zone for the IP address, which is controlled by whoever owns that IP — your host, cloud provider or ISP. You set it through their control panel or a support request, not in your normal domain DNS.

What is FCrDNS and why does it matter?

Forward-Confirmed reverse DNS means the PTR hostname forward-resolves back to the same IP, closing the loop. It matters because a matching forward and reverse record proves the IP’s owner and the hostname agree, which a spoofer cannot easily fake. A bare PTR that fails this check is treated as untrustworthy.

Is reverse DNS required for email or just recommended?

For anyone running their own sending IP, it is effectively required. Google has mandated valid, matching reverse DNS since February 2024, and Yahoo requires non-generic reverse DNS too. Without it, expect blocks or spam-foldering from the major providers.

My PTR exists but mail is still flagged — why?

The most likely causes are a generic or dynamic-looking PTR hostname, or a PTR that fails FCrDNS because it does not forward-resolve back to the sending IP. Replace it with a meaningful hostname on your own domain and confirm the forward record matches.

Do I need a reverse DNS record for IPv6 too?

Yes, if you send over IPv6. A missing IPv6 PTR is one of the most common reasons dual-stack servers get rejected by Gmail, because the message may leave over IPv6 even when an IPv4 PTR is present. Set reverse DNS on every IP you send from.

Can I configure reverse DNS on shared hosting or through an ESP?

On shared IPs you generally cannot — the platform’s PTR applies to everyone on that IP. Reputable email service providers set up correct FCrDNS on their sending infrastructure for you, which is one of the underrated reasons to send through an established platform rather than a bare server. On your own VPS or dedicated IP, configuring reverse DNS is your responsibility, and it should be one of the very first things you set up before sending any production mail.