FCrDNS (Forward-Confirmed Reverse DNS) is one of the most commonly overlooked email deliverability requirements. Every major ISP — Gmail, Microsoft, Yahoo, and hundreds of smaller providers — uses FCrDNS as a basic spam filtering signal. A mail server without a properly configured PTR record that forward-confirms back to the same IP will see elevated spam folder placement and outright rejection from ISPs that treat missing FCrDNS as a hard requirement. For Microsoft's May 2025 bulk sender enforcement, FCrDNS became explicitly mandatory.

FCrDNS
Forward-confirmed reverse DNS — PTR must match A record
PTR
reverse DNS — maps IP address back to hostname
Yahoo
requires FCrDNS for all sending IPs — will reject without it
dig -x
command to check PTR record for your sending IP

ISP Enforcement of PTR / FCrDNS for Inbound Email (2025)

95%Yahoo82%Comcast71%Microsoft45%Gmail60%iCloud88%Orange

What FCrDNS Is and Why ISPs Care

FCrDNS consists of two DNS lookups that must agree:

  1. Reverse DNS (PTR): Looking up the hostname associated with an IP address (e.g., 203.0.113.10 → mail.yourdomain.com)
  2. Forward DNS (A/AAAA): Looking up the IP address associated with that hostname (e.g., mail.yourdomain.com → 203.0.113.10)

FCrDNS passes only if both lookups agree: the IP resolves to the hostname, and the hostname resolves back to the same IP. This bidirectional verification provides meaningful identity signal — it demonstrates that whoever controls the sending IP also controls the DNS zone for the associated hostname. Spammers using compromised or rented servers often don't control DNS, making FCrDNS an effective filter.

How PTR Records Work

PTR records live in a special in-addr.arpa. DNS zone (for IPv4) or ip6.arpa. zone (for IPv6). The zone is controlled by whoever owns the IP address block — typically your data centre, cloud provider, or ISP — not by you as a customer.

FCrDNS verification — checking PTR and A record consistency
# Step 1: Check PTR record for sending IP 203.0.113.42
$ dig -x 203.0.113.42 +short
mail.yourcompany.com.

# Step 2: Check A record for that hostname
$ dig A mail.yourcompany.com +short
203.0.113.42

# FCrDNS PASSES: IP resolves to hostname, hostname resolves back to same IP.

# Failing example:
$ dig -x 198.51.100.7 +short
7.100.51.198.in-addr.arpa.  ← no PTR record
# or:
ec2-198-51-100-7.compute-1.amazonaws.com.  ← generic cloud PTR
# Yahoo will reject mail from this IP.
# The PTR record for 203.0.113.10 lives at:
10.113.0.203.in-addr.arpa. PTR mail.yourdomain.com.

# Check your current PTR record:
dig -x 203.0.113.10
# Returns: 10.113.0.203.in-addr.arpa. 300 IN PTR mail.yourdomain.com.

# Then verify the forward lookup:
dig A mail.yourdomain.com
# Must return: mail.yourdomain.com. 300 IN A 203.0.113.10

# Both must match for FCrDNS to pass

Setting Up PTR Records on Different Platforms

Dedicated server (data centre): Contact your data centre or hosting provider. Most provide a control panel where you can set the PTR (reverse DNS) for your IP. The process: log into your server management panel → find "Reverse DNS" or "PTR Record" settings → enter the hostname (mail.yourdomain.com) → save. Changes propagate within 1–24 hours.

AWS EC2: Elastic IP addresses support reverse DNS through the AWS Console. Navigate to EC2 → Elastic IPs → select your IP → Actions → Update Reverse DNS. You can only set the PTR to a hostname that forward-resolves to that IP.

Google Cloud (GCP): For static external IP addresses: VPC Network → External IP addresses → select IP → Edit → set DNS PTR record.

DigitalOcean: The PTR is set as the Droplet name. Rename your Droplet to the hostname you want (mail.yourdomain.com) and the PTR automatically updates. Alternatively, some DO regions allow setting PTR via the networking settings.

Azure: For public IP addresses: Public IP → Configuration → Reverse FQDN → enter hostname.

# After setting the PTR, verify both directions:
# 1. PTR lookup
dig -x YOUR_IP +short
# Should return: mail.yourdomain.com.

# 2. Forward lookup  
dig A mail.yourdomain.com +short
# Should return: YOUR_IP

# 3. FCrDNS test (online tools)
# - mxtoolbox.com/ReverseLookup.aspx
# - Check "PTR" in MXToolbox's MX Lookup output

Testing FCrDNS Configuration

# Quick command-line test
IP="203.0.113.10"
HOSTNAME=$(dig -x $IP +short | sed 's/\.$//')
FWDIP=$(dig A $HOSTNAME +short)

if [ "$IP" = "$FWDIP" ]; then
    echo "FCrDNS OK: $IP → $HOSTNAME → $FWDIP"
else
    echo "FCrDNS FAIL: $IP → $HOSTNAME → $FWDIP (mismatch)"
fi
# Common PTR/FCrDNS rejection messages in mail logs:
"550 PermFail - Host not found or poorly configured. PTR lookup failed"
"550 Mail not accepted from IPs without a reverse DNS record"
"550 5.7.1 [x.x.x.x] Messages with no rDNS will not be accepted"
"421 Service unavailable; Client host [x.x.x.x] has no PTR record"

# The fix sequence:
# 1. Confirm PTR is missing:
dig -x YOUR_IP
# If returns NXDOMAIN (no answer) - PTR is missing

# 2. Set PTR with your provider (see section above)

# 3. After 1-4 hours, verify:
dig -x YOUR_IP  # Should return hostname
dig A HOSTNAME  # Should return your IP

Diagnosing FCrDNS Failures in Your Sending Infrastructure

When FCrDNS fails, receiving servers — particularly enterprise MTA configurations and some EU ISPs — reject or defer connections before a single message is evaluated. The failure signature in your PowerMTA accounting log: connection refused or deferred at the EHLO stage, with response text mentioning hostname verification or PTR mismatch. These deferrals are infrastructure-level failures, not reputation events, which means Postmaster Tools and SNDS will not show them — only the accounting log reveals the pattern.

The diagnostic process for suspected FCrDNS failures: (1) From the sending server, run dig -x [sending-IP] to confirm the PTR record exists and resolves to the expected hostname. (2) Run dig [hostname] to confirm the A record for that hostname resolves back to the sending IP. (3) Compare the EHLO hostname in your PowerMTA configuration against the PTR hostname — they must match exactly, including subdomain structure. (4) Check the accounting log for delivery attempts to the suspected destination ISP and look for connection-stage rejections with FCrDNS-related text.

Common misconfiguration patterns: the PTR record was set at the datacenter level to the server's generic hostname (e.g., server123.datacenter.com) while PowerMTA's EHLO was configured as mail1.brand.com. The PTR says one thing; the EHLO says another; FCrDNS fails. The fix requires either updating the PTR record at the IP hosting level (contact the datacenter or VPS provider) or aligning the EHLO hostname to match the existing PTR. The first approach is preferable — PTR records should reflect the programme's own domain, not the datacenter's generic hostname.

PTR Records and IP Warming — Sequencing Matters

One frequently overlooked requirement in IP warming protocols is that PTR records must be in place before the first message is sent from a new IP. ISPs that log FCrDNS status at first contact build that initial record into the IP's reputation history. Starting warming on an IP without PTR records and correcting them on day 3 of warming means that the first few hundred connections from that IP have FCrDNS failures in the ISP's history — a poor start that can slow warmup progress even after the PTR is fixed.

The correct sequence for adding a new IP to your sending pool: (1) Provision the IP at the datacenter. (2) Set the PTR record to your mail hostname (e.g., mail2.brand.com). (3) Set the A record for mail2.brand.com to the new IP. (4) Allow 24-48 hours for DNS propagation. (5) Verify FCrDNS passes from multiple DNS resolvers. (6) Add the IP to your PowerMTA configuration with correct EHLO hostname. (7) Begin warmup. This sequence ensures that the very first connection from the new IP passes FCrDNS at every destination — the right foundation for a clean warmup.

Multiple IPs, Multiple PTR Records — Operational Management

A sending pool with 8 IPs requires 8 PTR records — one per IP — each pointing to a distinct mail hostname. The hostname convention matters: use a structured format like mail1.brand.com through mail8.brand.com, and ensure each hostname has a corresponding A record resolving to the correct IP. The most common error in multi-IP deployments is copying a single EHLO hostname across all IPs in the PowerMTA configuration — which means IPs 2-8 present mail1.brand.com as their EHLO even though their PTR records point to different hostnames. Each IP needs its own EHLO configuration matching its own PTR.

In PowerMTA, per-IP EHLO configuration is set in the virtual-mta block for each IP binding. When using a VMTA pool (where multiple IPs rotate within the same VMTA), the EHLO should be templated dynamically from the bound IP's PTR. This requires a custom EHLO macro in the PowerMTA configuration — without it, all IPs in a pool present the same EHLO regardless of which IP is bound for the session, causing FCrDNS failures for all IPs except the one whose PTR matches the static EHLO.

Maintaining correct FCrDNS across a growing IP pool is an ongoing operational practice: each time an IP is added, transferred, or decommissioned, the PTR/A record pair must be updated accordingly. Quarterly infrastructure audits should include an FCrDNS check for every IP in the sending pool — a 10-minute task that prevents the silent delivery failures that incorrect FCrDNS configuration causes without producing the visible reputation signals that would otherwise alert the programme to a problem.

FCrDNS and Enterprise Mail Filter Behaviour

While consumer ISPs (Gmail, Yahoo, Microsoft consumer) use FCrDNS as a soft signal — contributing to spam scoring rather than causing outright rejection — enterprise mail security gateways (Proofpoint, Mimecast, Barracuda, Cisco IronPort) frequently apply strict FCrDNS enforcement. An enterprise recipient whose company uses Proofpoint with FCrDNS validation enabled will see zero delivery from a sending IP that fails FCrDNS — the connection is rejected at the MTA level before any content analysis occurs. For B2B senders with significant enterprise recipient populations, FCrDNS compliance is effectively mandatory, not optional.

Enterprise FCrDNS enforcement varies by gateway product and configuration: Proofpoint Enterprise applies FCrDNS by default in its Dynamic Reputation (DRP) module; Mimecast applies FCrDNS as part of its connection-level checks; Barracuda Essentials uses FCrDNS as a contributing signal in its reputation scoring. If your accounting log shows consistent delivery failures to corporate domains (company.com addresses) but good delivery to consumer ISPs, FCrDNS failure is the most common infrastructure-level cause to investigate first.

The commercial impact of FCrDNS failures in B2B sending is asymmetric: the corporate decision-makers that B2B programmes most want to reach are the most likely to be protected by enterprise mail gateways that enforce FCrDNS. Getting FCrDNS right is the prerequisite for reliable B2B delivery, and the fix — correct PTR/A record alignment — is a one-time configuration change that provides permanent delivery improvement across the entire enterprise recipient population.

PTR records are infrastructure plumbing that most operators configure once and never revisit. Schedule a quarterly FCrDNS audit — 10 minutes, all sending IPs, confirmed pass — and this foundational deliverability requirement will never silently fail between checks. The corporate inbox access it protects is worth the quarterly 10 minutes it takes to verify it.