A customer’s IP was failing to deliver to about 18% of recipients in early March. Authentication looked correct in the DMARC reports we monitored. Spam complaint rate was 0.04%. Postmaster Tools showed High reputation. SNDS showed Green status. The customer had no obvious deliverability problem visible in any standard monitoring.
The mail headers from rejected sends revealed the issue. The receiving servers were rejecting with various 5xx responses citing “client host not in DNS” or “no valid DNS record for sending host” or similar errors. The cause was reverse DNS configuration. The IP had a PTR record. The PTR record pointed to a hostname. The hostname did not resolve back to the IP. The reverse DNS was technically present but not forward-confirmed.
This is the failure mode FCrDNS (Forward-Confirmed reverse DNS) prevents. It is also one of the more frequent configuration issues we find when auditing customer infrastructure. The fix is bounded. The cost of not fixing it is meaningful.
This post is the mechanics of reverse DNS for email senders, why FCrDNS specifically matters, the failure modes we see in production, and the operational fix.
What reverse DNS actually is
Forward DNS resolves a hostname to an IP address. You type example.com in your browser, DNS resolves to 93.184.216.34, your browser connects to that IP. The forward lookup answers “what IP does this hostname use?”
Reverse DNS resolves an IP address to a hostname. Given the IP 93.184.216.34, reverse DNS returns the hostname configured for that IP. The reverse lookup answers “what hostname does this IP use?”
Reverse DNS uses PTR records in a special DNS zone (in-addr.arpa for IPv4, ip6.arpa for IPv6). The PTR record is published by whoever controls the IP allocation (usually the hosting provider) rather than by whoever owns the hostname.
For an IP 1.2.3.4, the PTR record lives at 4.3.2.1.in-addr.arpa in DNS. The value is the hostname. When a receiver queries reverse DNS for 1.2.3.4, the DNS system follows the delegation chain to the appropriate authority and returns the PTR record’s value.
What FCrDNS adds
FCrDNS (Forward-Confirmed reverse DNS) is the verification that the reverse and forward DNS records agree. The sequence:
The receiver gets a connection from IP 1.2.3.4.
The receiver queries reverse DNS for 1.2.3.4. The result is mail.sender.com.
The receiver queries forward DNS for mail.sender.com. The result should be 1.2.3.4.
If the forward and reverse match, FCrDNS passes. If they do not match, FCrDNS fails.
The verification catches several scenarios:
The reverse DNS exists but points to a hostname that does not resolve at all. Forward lookup fails.
The reverse DNS points to a hostname that resolves to a different IP. Forward lookup returns the wrong answer.
The reverse DNS points to a generic hostname (vps-12345.provider.com) that resolves to many IPs, only some of which are the connecting IP.
Any of these scenarios produce FCrDNS failure even though there is a reverse DNS record.
Why receivers care
The receivers querying FCrDNS are doing so for legitimate reasons. The check is a low-cost way to identify likely spam sources.
Spam infrastructure historically has weak reverse DNS configuration. Compromised servers, throwaway IPs, anonymous hosting often lack proper PTR records or have generic ones. Legitimate senders with established infrastructure typically have proper FCrDNS configuration.
The check is a strong signal because configuring FCrDNS correctly requires:
- The hosting provider to set the PTR record (sender must request this)
- The sender to maintain forward DNS for the hostname
- The two to remain consistent over time
The configuration is operationally intentional. Senders who care about deliverability handle this. Senders who do not care typically do not.
The receiver behaviors we observe
Different receivers handle FCrDNS failures differently.
Stricter receivers (immediate rejection)
Some receivers reject connections from IPs failing FCrDNS outright. The rejection happens at the SMTP HELO/EHLO phase. The receiver returns a 5xx error citing DNS issues.
Examples we observe:
- AOL Mail (legacy systems still active)
- Many corporate mail servers using SpamAssassin or similar systems
- Some Linux-based mail systems with strict configurations
- Mail systems behind major commercial filtering products
Rejection rates from these sources can be 5-25% of total volume depending on the sender’s recipient mix.
Moderate receivers (filter or junk)
Some receivers accept the mail but apply heavy filtering for FCrDNS failure. The mail lands in spam folder or junk folder rather than being rejected.
Examples:
- Gmail historically tolerated FCrDNS failures but applies reputation penalty
- Microsoft Outlook varies based on SmartScreen reputation
- Yahoo varies based on broader filtering decisions
The signal is less obvious than outright rejection but produces meaningful deliverability impact over time.
Lenient receivers (accept but track)
Some receivers accept mail without immediate filtering but record FCrDNS failures for reputation tracking over time. Subsequent sends from the same IP carry the historical FCrDNS failures into reputation decisions.
This produces deliverability degradation that lags behind the configuration issue by weeks. Senders may not associate the deliverability problem with the FCrDNS configuration because the impact is delayed.
Skeptical receivers (apply other heuristics)
Some receivers use FCrDNS failure as one input among many. The mail may or may not be filtered depending on other signals. Strong sender reputation can compensate for FCrDNS failure; weak sender reputation cannot.
The failure modes we see in production
Across customer audits, several specific failure modes recur.
No PTR record at all
The IP has no PTR record. Reverse DNS lookup returns NXDOMAIN or no answer.
Frequency: about 3-5% of new IPs from typical providers. More common from budget providers, less common from quality providers.
Impact: severe. Many receivers refuse connections from IPs without PTR records. Rejection rates can exceed 30% of total volume.
The fix: request a PTR record from the hosting provider. The provider sets the PTR; the sender cannot do it directly (the provider controls the IP’s reverse DNS zone). Once set, propagation typically takes hours to days.
Generic PTR record
The IP has a PTR record but it is a generic provider hostname like vps-12345.example-provider.com or static.91.1.2.3.example-network.com.
Frequency: about 25-40% of new IPs from typical providers. The default behavior of most providers is to use generic hostnames.
Impact: moderate to severe. Generic hostnames look like spam sources to many filtering systems. Some receivers reject; others apply reputation penalty.
The fix: request a custom PTR record from the hosting provider, pointing to a hostname under the customer’s own domain. The new hostname must also have a forward DNS A record pointing back to the IP. The forward DNS is the sender’s responsibility.
PTR record without forward DNS
The IP has a custom PTR record (mail.customer.com) but the customer has not configured forward DNS for mail.customer.com. Reverse DNS lookup succeeds; forward DNS lookup fails.
Frequency: about 8-12% of customer accounts when we onboard them. Often the customer requested the PTR but forgot to set up the forward DNS.
Impact: severe. FCrDNS verification fails. Receivers treating this as a hard signal reject the mail. The error messages reference “client host” or “host name” issues.
The fix: add A record to the customer’s domain DNS for the hostname in the PTR. Verify both directions resolve correctly.
Mismatched forward DNS
The IP has a custom PTR record pointing to a hostname. The hostname has forward DNS but it points to a different IP than the one in PTR. The two records do not agree.
Frequency: about 4-6% of customer accounts. Often a result of IP changes that updated PTR but not forward DNS, or vice versa.
Impact: severe. FCrDNS verification fails specifically because the two ends do not match. The mismatch is sometimes treated more skeptically than missing records, because it suggests configuration error or potential spoofing.
The fix: align the two records. Either update PTR to match the IP that forward DNS already resolves to, or update forward DNS to match the IP that PTR identifies.
HELO mismatch
The IP has correct FCrDNS but the SMTP HELO/EHLO greeting uses a different hostname than the PTR. Receivers comparing HELO to PTR see a mismatch.
Frequency: about 15-20% of customer accounts when we onboard them. The HELO configuration is often forgotten when other PTR work is done.
Impact: moderate. HELO mismatch alone usually does not cause rejection but produces reputation penalty over time. Combined with other issues, it amplifies the impact.
The fix: configure the SMTP service (PowerMTA, Postfix, etc.) to use the same hostname for HELO/EHLO as the PTR record specifies.
Aged DNS with stale records
The PTR was set up months ago. The corresponding A record was set up months ago. The DNS records are cached at various resolvers. Subsequent changes (IP move, hostname change) updated one but not the other.
Frequency: variable. Common after infrastructure migrations or provider changes.
Impact: variable. Depends on which record is stale and what direction.
The fix: audit and refresh both records. Confirm consistency. Reduce TTL temporarily during transition to allow faster propagation of corrections.
The diagnostic process
When we suspect FCrDNS issues, the diagnostic sequence is straightforward.
Step 1: Reverse DNS lookup
Use dig -x <ip> or host <ip> to query PTR. The result should be a hostname.
If the result is NXDOMAIN, the PTR is missing. Request from hosting provider.
If the result is a hostname, continue to step 2.
Step 2: Forward DNS lookup
Query the hostname from the PTR. Use dig <hostname> A for IPv4 or dig <hostname> AAAA for IPv6.
If the result is NXDOMAIN, the forward DNS is missing. Add the A record.
If the result is one or more IPs, continue to step 3.
Step 3: Verify forward matches reverse
Check whether the IP from forward DNS matches the original IP we started with.
If yes, FCrDNS is working. The issue is elsewhere.
If no, the forward DNS points to a different IP than the PTR. Either the PTR or the forward DNS needs correction.
Step 4: Verify HELO matches
Connect to the SMTP service and observe the HELO/EHLO greeting. The greeting hostname should match the PTR.
If mismatch, configure the SMTP service to use the correct hostname.
Step 5: Verify multiple resolvers
DNS caching can produce inconsistent results across resolvers. Verify FCrDNS through multiple major DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS, regional resolvers).
If results vary, there may be DNS configuration inconsistency between authoritative servers. Investigation at the authoritative DNS layer.
The operational practices we recommend
For sustained good FCrDNS configuration:
Document the PTR-to-hostname mapping
Maintain a record of which IPs have which PTR values and which hostnames are configured. The documentation is the source of truth for verifying configuration consistency.
Set TTLs appropriately
For PTR and A records used in email sending, TTLs should be moderate (1-6 hours). Lower TTLs allow faster propagation of changes; higher TTLs improve query efficiency. The 1-6 hour range balances both.
Verify after any IP changes
Whenever IPs are added, removed, or reassigned, verify FCrDNS configuration. The verification is fast (5-10 minutes per IP) and catches issues that would otherwise emerge as deliverability problems weeks later.
Monitor for drift
DNS configurations can drift over time as records are updated independently. Periodic auditing (quarterly is reasonable) catches drift before it produces deliverability impact.
Test from external resolvers
Internal DNS resolution may differ from external resolution. Test FCrDNS using public DNS resolvers (Google, Cloudflare) rather than relying on internal DNS that may have different configurations.
The hosting provider relationship
PTR records are controlled by the hosting provider, not the customer. The customer relationship with the hosting provider determines what is possible.
Quality providers
Some providers allow customers to set PTR records via control panel or API. Custom hostnames can be configured easily. Updates propagate quickly. The PTR management is essentially a self-service operation.
Standard providers
Some providers allow custom PTR records but require manual support tickets. The process is slower (24-48 hours typical) but the capability exists. Documentation typically describes the process.
Limited providers
Some providers do not allow custom PTR records or charge extra for the capability. Customers using these providers face structural limitations on FCrDNS configuration.
Provider switching
When the provider’s PTR capabilities do not match the operational requirements, switching providers is sometimes the right answer. The cost of provider switching is bounded; the cost of structural FCrDNS limitations is ongoing.
What we have observed about FCrDNS over time
Several patterns from years of customer audits:
FCrDNS issues are underdiagnosed
Many customers have FCrDNS issues for extended periods without realizing it. The symptoms (some receivers reject, others junk, no consistent pattern) are hard to attribute to a specific cause. Customers attribute the deliverability impact to other factors.
When we audit and identify the FCrDNS issue, the customer often reports “we have been seeing problems for weeks.” The fix produces visible improvement within days.
The fixes are bounded
Once identified, FCrDNS issues are typically fixable within hours to days. The work is straightforward DNS configuration. The cost is mostly the time to identify the issue rather than the time to fix it.
Hosting provider quality matters
Providers with proper PTR management capabilities make ongoing FCrDNS hygiene easier. Providers without these capabilities create friction that accumulates over time.
For customers selecting hosting providers, PTR management capability should be evaluated. The capability matters more than many customers realize during provider selection.
Documentation prevents recurrence
Customers who document their FCrDNS configuration have fewer recurring issues than customers who treat each configuration as standalone. The documentation makes verification easier and changes more deliberate.
What we do as part of customer onboarding
Our customer onboarding process explicitly addresses FCrDNS.
IP allocation includes FCrDNS verification
Every IP we allocate to a customer has FCrDNS verified before customer assignment. The pre-flight checks include reverse DNS, forward DNS, and consistency verification.
If we cannot configure FCrDNS properly for an IP (provider limitations, hostname issues, etc.), we either resolve before assignment or do not assign the IP to the customer.
Custom PTR with customer domain
Every customer IP gets PTR pointing to a hostname under the customer’s domain. Generic provider hostnames are not used in customer-facing infrastructure.
The customer provides the desired hostname during onboarding. We coordinate with our hosting providers to set the PTR. The customer adds the matching A record to their domain.
HELO configuration
We configure the SMTP service (PowerMTA, Postal, custom) to use the matching HELO hostname. The HELO matches PTR.
The customer’s outbound mail headers consistently show the proper FCrDNS configuration to receiving servers.
Periodic verification
We verify FCrDNS configuration for all customer IPs quarterly. The verification catches drift and configuration changes that may have occurred during the quarter.
Customer documentation
Each customer receives documentation of their FCrDNS configuration. The documentation lists IP addresses, PTR hostnames, and A record requirements on the customer’s side. The customer has the information needed to audit or update independently.
The broader operational principle
FCrDNS is one element of email infrastructure hygiene. Treating it as standalone or treating it as low-priority produces ongoing deliverability cost.
The pattern repeats across infrastructure elements:
- Authentication (SPF, DKIM, DMARC) similarly needs ongoing maintenance
- IP reputation needs ongoing monitoring
- DNS configurations need periodic audit
- HELO hostnames need consistency verification
The customers who treat email infrastructure as ongoing operational discipline have fewer FCrDNS issues, fewer authentication issues, fewer reputation issues. The discipline produces compound benefits over time.
The customers who treat email infrastructure as set-and-forget accumulate issues across multiple dimensions. Each issue alone may not be catastrophic. The cumulative effect is meaningful deliverability degradation.
FCrDNS specifically is one of the easier elements to address. The mechanics are well-documented. The fix is bounded. The benefit is visible. For senders looking for high-impact deliverability improvements, FCrDNS verification and remediation is among the better investments of operational time.
The customer who started this post had FCrDNS misconfiguration causing their 18% rejection rate. The fix took about 4 hours of work (PTR request to provider, A record addition, verification). The rejection rate dropped to under 1% within 48 hours. The remediation paid for itself in the first day of restored deliverability.
For other senders reading this with “have we checked FCrDNS?” thoughts: check it. The verification takes 15 minutes. The remediation, if needed, is bounded. The deliverability impact of unaddressed FCrDNS issues is often larger than expected. The cost of action is less than the cost of inaction.