Reverse DNS (PTR) & Forward-Confirmed Reverse DNS (FCrDNS)

Configure Forward-Confirmed Reverse DNS (FCrDNS) on every sending IP address, ensuring the PTR record matches the forward A/AAAA record and the SMTP EHLO greeting.

What it is

Reverse DNS (rDNS) is the DNS mechanism that resolves an IP address back to its fully qualified domain name (FQDN) using a pointer (PTR) record in the in-addr.arpa (for IPv4) or ip6.arpa (for IPv6) zone.

Forward-Confirmed Reverse DNS (FCrDNS), also known as full-circle reverse DNS, is a strict verification procedure where the receiving mail transfer agent:

Performs a reverse DNS lookup on the connecting client IP to obtain the hostname (PTR record).
Performs a forward DNS lookup on that returned hostname (A or AAAA record).
Verifies that the forward lookup IP exactly matches the original connecting client IP.
Verifies that the outbound SMTP server announces the exact same hostname in its HELO/EHLO greeting.

Connecting IP: 198.51.100.25 ──(PTR)──> mail1.example.com ──(A)──> 198.51.100.25 [MATCH]

Why it matters

Hard Requirement for Inbox Acceptance: Google, Yahoo, Microsoft 365, and major anti-spam filtering engines (Spamhaus, Cloudmark, Barracuda) immediately reject or drop connections from MTAs lacking valid FCrDNS with a 550 5.7.1 error.
Prevents Botnet and Dynamic IP Abuse: Malware botnets and residential compromised machines cannot configure authoritative PTR records on ISP-managed IP allocations. FCrDNS provides receivers with instant confirmation of accountable, professional infrastructure.
Establishes IP Reputation Anchor: Mailbox providers anchor deliverability metrics, volume throttling, and historical reputation to the sending IP’s FCrDNS identity.

How to implement

1. Set up the PTR record with your hosting provider / ISP. PTR records can only be created by the entity that owns the IP netblock (your cloud provider, ISP, or hosting infrastructure provider):

; IPv4 Reverse Zone (100.51.198.in-addr.arpa)
25.100.51.198.in-addr.arpa. IN PTR mail1.example.com.

; IPv6 Reverse Zone (0.0.0.0...ip6.arpa)
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail1.example.com.

2. Create matching forward A and AAAA records in your DNS zone. Ensure the hostname declared in the PTR record resolves directly back to the sending IP address:

; Forward Zone (example.com)
mail1.example.com. IN A 198.51.100.25
mail1.example.com. IN AAAA 2001:db8::1

3. Configure your MTA HELO/EHLO greeting to match the FCrDNS hostname. In Postfix (/etc/postfix/main.cf):

myhostname = mail1.example.com
smtpd_banner = $myhostname ESMTP

In Exim (/etc/exim/exim.conf):

primary_hostname = mail1.example.com
smtp_active_hostname = mail1.example.com

4. Avoid generic and default ISP hostnames. Never use default generic hostnames like 198-51-100-25.static.cloud-provider.com or vps-49219.local. Use a branded, recognizable domain name associated with your organization (such as mail1.example.com or outbound.example.com).

Common mistakes

Asymmetric Mismatch: The PTR record points to mail1.example.com, but the forward A record points to a different IP or does not exist at all.
HELO/EHLO Discrepancy: Announcing localhost, a bare IP literal ([198.51.100.25]), or a domain that differs from the PTR hostname in the SMTP greeting.
Multiple Conflicting PTR Records: Assigning multiple PTR records to a single IP address with divergent hostnames causes unpredictable resolution behavior across different DNS caching resolvers.
Overlooking IPv6 Outbound Connections: If your MTA sends email over IPv6, an ip6.arpa PTR record and corresponding AAAA record must be published. Missing IPv6 rDNS causes immediate delivery rejection at Google and Yahoo.

Verification

1. Perform the full-circle DNS verification using dig:

# 1. Reverse lookup (IP -> Hostname)
dig +short -x 198.51.100.25
# Output: mail1.example.com.

# 2. Forward lookup (Hostname -> IP)
dig +short A mail1.example.com
# Output: 198.51.100.25

2. Test SMTP greeting connection:

telnet 198.51.100.25 25
# Check banner: 220 mail1.example.com ESMTP
EHLO client.test
# Check response: 250-mail1.example.com

3. Inspect received headers: Delivered email headers must show verified reverse DNS without warnings:

Received: from mail1.example.com (mail1.example.com. [198.51.100.25])
        by mx.google.com with ESMTPS id ...
        for <[email protected]>;