Reverse DNS and email: PTR records and FCrDNS

When your server connects to Gmail or Yahoo, the receiving side sees nothing but an IP address, so it asks DNS which hostname that address belongs to. The answer sits in a PTR record. If there is no answer, or the name doesn't match what your server called itself, the message starts out behind, and at Gmail it may not get in at all.

Forward DNS vs. reverse DNS

Forward DNS turns a name into an IP. Ask for mail.example.com and you get 198.51.100.25 back. That's an A record, and anyone who has set up a domain has met one.

Reverse DNS (rDNS) runs the other way, from IP to name. The query doesn't go to your domain's zone at all. It goes to a special one, in-addr.arpa for IPv4 or ip6.arpa for IPv6, and the record that answers it is the PTR.

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

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

The domain owner controls the forward zone. Whoever owns the IP block controls the reverse one, which usually means your hosting provider or datacenter. So the PTR isn't set next to your MX and SPF records; you have to ask the provider.

What a PTR record actually is

PTR stands for pointer record. RFC 1035 defines it as a record holding a domain name that points somewhere else in the DNS, and in practice that means an address in the reverse zone pointing to a hostname. For 198.51.100.25, the record lives at 25.100.51.198.in-addr.arpa, octets reversed.

# PTR record in the reverse zone
25.100.51.198.in-addr.arpa.   IN   PTR   mail.example.com.

IPv6 works the same way with more typing: every hex digit of the address (a nibble) is reversed on its own and ip6.arpa goes on the end.

Nothing in DNS stops one IP from having several PTR records. The iprev check in RFC 8601 handles that by looking up each returned name, up to a limit, and passing if any of them leads back to the original IP. A mail server is still easier to run with one name, since that is the name it gives in EHLO and the one you will be searching for in headers.

Why PTR matters for email sending

Your server opens an SMTP connection and introduces itself with EHLO (or HELO), giving its hostname. The receiving server already knows the connecting IP, so it can look up the PTR right away, before MAIL FROM, which is earlier than any SPF, DKIM or DMARC evaluation.

The big mailbox providers say so in writing. Google's sender guidelines require valid forward and reverse DNS for sending IPs from every sender, bulk or not, and add that the hostname in the PTR must resolve back to the same IP. Yahoo lists valid forward and reverse DNS among its requirements for all senders and asks for PTR names that are meaningful, non-generic and reflect your domain. Mail.ru gives a pair of examples: mail.domain.com is fine, 231.2.53.243.domain.isp.com is not.

Why do filters care? An infected home PC sends spam from an ISP address that has either no PTR or a templated one like pool-12-34-56-78.isp.net. A server someone actually set up has a deliberate name on its own domain. RFC 1912 was already warning in 1996 that many internet services won't talk to a host that isn't correctly registered in DNS.

FCrDNS: checking in both directions

The PTR alone doesn't prove much, so receivers usually run FCrDNS (forward-confirmed reverse DNS), which takes two lookups.

1. Reverse lookup: for IP 198.51.100.25, the PTR returns mail.example.com.
2. Forward lookup: the A record for mail.example.com returns 198.51.100.25.

If you end up at the IP you started from, the check passes, and the owner of the address and the owner of the domain are describing the same machine. In an Authentication-Results header this test goes by the name iprev; RFC 8601 defines its results as pass, fail, temperror and permerror.

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

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

# IPs match → FCrDNS passes

A failure looks like this: the IP says it is mail.example.com, but mail.example.com resolves somewhere else. Or there's no PTR at all, which iprev reports as permerror. RFC 8601 notes that an MTA will often just reject a connection that fails the test; others record the result and let it count against the message.

The EHLO name is a separate matter. RFC 5321 lets a server compare it with the client's IP but forbids refusing a message on that basis alone. Nothing stops a filter from scoring the mismatch, though, so keep the EHLO name equal to the PTR.

When PTR and FCrDNS break: common scenarios

Reverse DNS is easy to break, and one server move is usually enough.

• No PTR configured. The server is rented and mail is running, but nobody asked the provider for a PTR. The reverse lookup comes back empty, and the mail no longer meets Gmail's or Yahoo's requirements.
• The host's default name. The provider filled in something like vps12345.hosting.provider.net. A PTR exists, but it doesn't match the mail.yourdomain.com your server uses in EHLO, and Yahoo wants the PTR to reflect your domain.
• PTR exists, A record doesn't match. You moved to a new IP and updated the A record but never asked the host to change the PTR. Reverse DNS still gives the right name; forward DNS now points at the new address. FCrDNS fails.
• PTR and EHLO use different subdomains. PTR says smtp.example.com, EHLO says mail.example.com. Same registered domain, but some filters will still call it a mismatch.
• Dynamic IP. Home and office connections draw addresses from a pool, and their PTRs are templated: the IP digits in the name plus words like dynamic, dhcp, dsl, pool or client. Mail.ru flatly refuses direct connections to its MX servers from dynamic and home-network addresses.

Checking PTR with dig, host and nslookup

dig and host come with the BIND utilities (the dnsutils package on Debian and Ubuntu). nslookup is there on Windows as well.

dig

# Reverse lookup by IP
$ dig -x 198.51.100.25 +short
mail.example.com.

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

The -x flag switches dig to a reverse lookup. You don't need to flip the octets or add in-addr.arpa yourself.

host and nslookup

$ host 198.51.100.25
25.100.51.198.in-addr.arpa domain name pointer mail.example.com.

# Windows, or any system without dig
> nslookup 198.51.100.25

host works out by itself that it was given an IP and does the reverse lookup. The output fits on one line, which is handy in scripts.

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 it after any infrastructure change: a server migration, a new IP, a new provider. FCrDNS doesn't decay on its own; it breaks when one side changes and the other is left behind.

How to configure a PTR record

Your domain's DNS panel (Cloudflare, Namecheap and the like) can't create a PTR for your server, because the reverse zone belongs to the owner of the IP block.

1. Find the sending IP. You want the address mail actually leaves from. If you send through an ESP, they have already set PTRs on their IPs.
2. Find the setting at your host. Many providers have a Reverse DNS (rDNS) field under IP or network settings. If yours doesn't, open a support ticket.
3. Enter your mail server's hostname. For example mail.yourcompany.com. The server should use the same name in EHLO.
4. Make sure the A record points back. In your domain's DNS, mail.yourcompany.com has to resolve to the IP you set the PTR on, or FCrDNS won't close.
5. Wait for caches. Providers usually apply the change quickly, but resolvers can keep serving the old answer until its TTL runs out. Check with dig -x against an outside resolver.

PTR when using an ESP or cloud SMTP

Send through Mailgun, Amazon SES, Postmark or a similar service and the PTRs on their IPs are theirs to manage. What you owe is SPF, DKIM and DMARC for your own domain: the PTR vouches for the ESP's machines, SPF and DKIM vouch that the ESP may send for you.

Running your own Postfix, Exim or Exchange on a VPS is a different story. The PTR is entirely on you, and without it your mail looks suspect before the recipient's server has read a single header.

PTR for IPv6

Same idea, longer record: the IPv6 address is split into nibbles, reversed, and placed under ip6.arpa.

$ dig -x 2001:db8::25 +short
mail.example.com.

If your server sends over IPv6, the IPv6 address needs a PTR too. Gmail turns such mail away with 550-5.7.1: Message does not meet IPv6 sending guidelines regarding PTR records and authentication, and Google suggests that anyone sending through an ESP confirm the provider has IPv6 PTR records in place.

PTR alongside SPF, DKIM, and DMARC

SPF, DKIM and DMARC authenticate the sender at the domain level. PTR vouches for the sending IP at the infrastructure level. They cover different gaps and none of them replaces another.

You can pass SPF and DKIM with no PTR, and a receiver without strict checks may still accept the message. Gmail and Yahoo, though, both list reverse DNS as a requirement, and a Postfix server using reject_unknown_reverse_client_hostname will refuse the client before it ever looks at a signature. The opposite setup fails too. A perfect PTR with no SPF or DKIM falls short of Google's and Yahoo's rules, which ask every sender for at least one of the two and bulk senders for DMARC on top.

Checklist: common PTR mistakes

• Generic hostname in the PTR. Names like 12-34-56-78.static.provider.net technically pass rDNS, but Yahoo and Mail.ru both ask senders not to use generated names. Use one on your own domain.
• Several PTRs on one IP. DNS allows it and iprev will try each name. Your EHLO name is still only one, and which PTR a given filter compares it with is anyone's guess.
• EHLO says localhost or the host's name. Postfix takes its EHLO name from myhostname, which defaults to the machine's hostname. On a fresh VPS that is often localhost or something like vps12345, and it won't match your PTR.
• No IPv6 PTR. The server talks over both stacks, the PTR was only set for IPv4, and connections over IPv6 fail the check. Gmail rejects them.
• Server migrated, PTR left behind. When moving to a new IP: create the PTR at the new host, update the A record, check the EHLO name, and only then switch traffic.

How to see the PTR result in message headers

Open a delivered message and view the headers (in Gmail: three dots → “Show original”). Look for the Received: line added by the receiving server.

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)

The name after from is what your server said in EHLO. Inside the parentheses the receiver writes what it found itself: the PTR name and the IP. When the two names agree, reverse DNS is in order. An IP on its own, or the word unknown that Postfix uses, means the PTR is missing or doesn't resolve. Servers that run FCrDNS also add iprev=pass or iprev=fail to Authentication-Results:, next to the SPF, DKIM and DMARC verdicts.

PTR and SMTP email verification

To check an address, a validator looks up the recipient domain's MX records, connects to its mail server and asks whether the mailbox exists. The recipient server's own PTR has no bearing on the answer. The verifier's PTR does, because to the receiving server a verifier is just another SMTP client.

Postfix ships two restrictions for this. reject_unknown_reverse_client_hostname turns away clients with no PTR; the stricter reject_unknown_client_hostname also wants FCrDNS to close. Both answer with 450 by default, so instead of a verdict on the mailbox the verifier gets a temporary refusal and the address stays unchecked.

That is why uChecker gives every IP it runs SMTP checks from its own EHLO name, one that is meant to match that address's reverse record. A single shared name would break FCrDNS on all addresses but one.