Reverse DNS and email: PTR records and FCrDNS

The moment your server connects to Gmail or Outlook, the receiving side looks up your sending IP in DNS: what hostname does this address belong to? That answer lives in the PTR record. No answer, or one that doesn't match what your server claims to be, and the message starts with a strike against it.

Forward DNS vs. reverse DNS

Forward DNS translates a domain name into an IP. You look up mail.example.com, DNS returns 93.184.216.34. That's an A record. Reverse DNS goes the other way: IP in, hostname out. The query goes to a special zone called in-addr.arpa for IPv4 and ip6.arpa for IPv6. The record type that holds the answer is PTR.

# Forward DNS: name → IP
$ dig A mail.example.com +short
93.184.216.34

# Reverse DNS: IP → name
$ dig -x 93.184.216.34 +short
mail.example.com.

Forward DNS is controlled by the domain owner. Reverse DNS is controlled by whoever owns the IP block, typically your hosting provider or datacenter. That's why setting a PTR always requires going through your provider, not your domain registrar.

What a PTR record actually is

PTR (Pointer Record) maps an IP address to a hostname. It lives in the reverse DNS zone. For IP 93.184.216.34, the record sits in the zone 34.216.184.93.in-addr.arpa. Octets are written in reverse order; that's the standard.

# PTR record structure
34.216.184.93.in-addr.arpa.   IN   PTR   mail.example.com.

One IP can technically have multiple PTR records, but mail servers expect exactly one. Multiple PTRs are unusual and sometimes trigger questions from spam filters.

Why PTR matters for email sending

When your sending server opens an SMTP connection, it introduces itself with EHLO and declares its hostname. The receiving server looks up the PTR record for the connecting IP. This happens before SPF, DKIM, or DMARC are evaluated.

Gmail's bulk sender guidelines are explicit: your sending IP must have a PTR record. Without one, inbox placement drops. Outlook and Yahoo enforce the same requirement. A missing PTR is one of the signals providers use to distinguish a legitimate mail server from a compromised machine or botnet node.

FCrDNS: the two-way check that actually matters

A PTR record alone is only half the picture. The real verification is FCrDNS (Forward-Confirmed Reverse DNS), which runs two steps:

1. Reverse lookup: IP 93.184.216.34 → PTR returns mail.example.com
2. Forward lookup: A record for mail.example.com → returns 93.184.216.34

If the IP at the end matches the IP at the start, FCrDNS passes. This proves the domain owner and IP block owner agree: yes, this IP is genuinely our mail server.

# Step 1: reverse lookup (PTR)
$ dig -x 93.184.216.34 +short
mail.example.com.

# Step 2: forward lookup (A)
$ dig A mail.example.com +short
93.184.216.34

# IPs match → FCrDNS passes

When FCrDNS fails, the receiving server sees a contradiction. The IP claims to be mail.example.com, but mail.example.com points to a different IP. Or PTR is missing entirely. Either way, spam filters add negative points.

FCrDNS is a handshake between forward and reverse DNS. If it doesn't complete, the receiving server has grounds to distrust the sender.

When PTR and FCrDNS break: common scenarios

• No PTR configured. Server rented, IP assigned, mail set up, but nobody asked the provider for a PTR. The reverse lookup returns empty. Gmail reads this as amateur or temporary infrastructure.
• PTR points to the host's default hostname. The provider auto-assigned something like vps12345.hosting.provider.net. Technically a PTR exists, but FCrDNS fails because your mail server introduces itself as mail.yourdomain.com.
• PTR exists but the A record doesn't match. You moved to a new IP, updated the A record, but forgot to update the PTR. Reverse DNS still points at the right name, but forward DNS now resolves to the new IP. FCrDNS fails.
• PTR uses a different subdomain than EHLO. PTR returns smtp.example.com, but the server announces itself as mail.example.com. Some filters flag this as a mismatch even though the second-level domain is the same.
• Dynamic IP. Home and office connections use dynamic IPs with PTRs like pool-12-34-56-78.isp.net. Many providers block inbound SMTP from these addresses outright.

Checking PTR with dig and host

dig (recommended)

# Reverse lookup by IP
$ dig -x 74.125.45.100 +short
mail-yw1-f100.google.com.

# Query a specific resolver
$ dig -x 74.125.45.100 @8.8.8.8 +short

The -x flag tells dig to run a reverse lookup, reversing the IP octets and appending in-addr.arpa automatically.

Full FCrDNS check in three commands

# 1. Get the PTR for your mail server's IP
$ dig -x 198.51.100.25 +short
mail.yourcompany.com.

# 2. Check the A record for that hostname
$ dig A mail.yourcompany.com +short
198.51.100.25

# 3. IPs match → FCrDNS passes
#    Different IP or empty → problem

Run this after any infrastructure change: server migration, new IP, switching providers. FCrDNS breaks every time IP or PTR changes without updating both sides.

How to configure a PTR record

You cannot create a PTR in your domain control panel (Cloudflare, Namecheap, or similar). The reverse DNS zone belongs to the IP block owner.

1. Identify your mail server's sending IP. If you use an ESP, PTR is already set on their IPs; nothing to do here.
2. Go to your hosting provider. Most providers (Hetzner, OVH, DigitalOcean, Vultr) have a PTR panel under IP or network settings. If not, open a support ticket.
3. Set your mail server's hostname. For example mail.yourcompany.com. This name must match what the server sends in EHLO.
4. Verify the A record points back to the same IP. Open your domain's DNS and confirm mail.yourcompany.com resolves to the same IP. Without this, FCrDNS fails.
5. Wait for propagation. PTR records update within minutes, but DNS caching can delay visibility a few hours. Check with dig -x against an external resolver.

PTR when using an ESP or cloud SMTP

If you send through Mailgun, Amazon SES, Postmark, or a similar service, PTR is already configured by the provider on their IPs. Your job is SPF, DKIM, and DMARC for your domain.

Running your own SMTP server (Postfix, Exim, Exchange on your own VPS)? PTR is entirely your responsibility. Skip it and your messages arrive looking suspicious from the first TCP handshake.

PTR for IPv6

Same principle, longer record. An IPv6 address is split into nibbles, reversed, and placed in the ip6.arpa zone.

$ dig -x 2607:f8b0:4004:800::200e +short
mail-yw1-f14.google.com.

If your server sends over IPv6, PTR is required for the IPv6 address too. Gmail rejects inbound SMTP over IPv6 without a valid PTR; this is in their official sender documentation.

PTR alongside SPF, DKIM, and DMARC

SPF, DKIM, and DMARC authenticate the sender at the domain level. PTR authenticates the sending IP at the infrastructure level. Different layers, different gaps covered.

You can pass SPF and DKIM while failing PTR. The message probably still delivers (SPF and DKIM carry more weight), but it picks up negative spam-filter points. Over time that damages IP reputation. The reverse: PTR configured, FCrDNS passing, no SPF or DKIM. In 2026 that's not enough. Gmail and Yahoo require DMARC with at least one passing mechanism for all bulk senders.

Checklist: common PTR mistakes

• PTR has a generic hostname. Names like 12-34-56-78.static.provider.net technically pass rDNS but score higher in spam filters. Use a hostname from your own domain.
• Multiple PTR records for one IP. RFC allows it; mail filters don't expect it. Extra PTRs create ambiguity.
• EHLO sends localhost. Default Postfix configs sometimes use localhost in EHLO. Check myhostname in your Postfix config.
• IPv6 PTR missing. Server listens on both stacks, PTR only set for IPv4. Some connections go over IPv6 and fail the check.
• Server migrated, PTR not updated. When moving to a new IP: create PTR at the new host, update the A record, verify EHLO matches, then switch sending traffic.

How to see the PTR result in message headers

Open any delivered message and look at the headers (in Gmail: three dots → “Show original”). Find the Received: line; it normally shows the reverse DNS result.

Received: from mail.yourcompany.com (mail.yourcompany.com. [198.51.100.25])
        by mx.google.com with ESMTPS id ...
        for <user@gmail.com>;
        Tue, 20 May 2026 10:15:32 -0700 (PDT)

If the hostname in parentheses matches the hostname before it, reverse DNS resolved correctly. If you see only an IP or the word unknown in parentheses, PTR is missing or not resolving. The Authentication-Results: header is also worth checking for explicit SPF, DKIM, DMARC, and rDNS verdicts.