Reverse DNS & FCrDNS – Why mail servers must “match” to be trusted

NuStart Email Trust Series — Post 8 of 10

Email deliverability is full of acronym soup—SPF, DKIM, DMARC, TLS, Reverse DNS, FCrDNS—and mostbusinesses don’t have time to become part-time email engineers. In this series, I translate the geeky jargon into plain-English concepts and simple actions. You run the organization; I’ll do the nerding.

---

First: what Reverse DNS (rDNS) is

When you look up a domain name (like example.org) to find an IP address, that’s forward DNS.

Reverse DNS (rDNS) is the opposite: it answers the question:

“If I have this IP address, what hostname does it claim to be?”

That mapping is stored in a PTR record (Pointer record).

So:

• A / AAAA record: hostname → IP
• PTR record (rDNS): IP → hostname

Mail servers care about this because it’s a simple, long-standing trust signal: legitimate mail servers usually have a consistent identity.

---

What is FCrDNS?

FCrDNS stands for Forward-Confirmed reverse DNS.

It’s a two-step “match check”:

1. The IP’s PTR record points to a hostname (reverse lookup).
2. That hostname’s A/AAAA record points back to the same IP (forward lookup).

If both match, you have forward-confirmed reverse DNS.

In plain English: the mail server’s IP and hostname agree about who they are.

---

Why rDNS and FCrDNS matter (real-world)

For businesses, this topic matters most in a specific scenario:

If you send email from a dedicated server or dedicated IP

Examples:

• you run your own mail server (rare today, but it happens)
• your website/server sends mail directly
• you use a transactional provider that gives you a dedicated IP
• you use an ESP where IP reputation and identity matter

In these cases, many receiving systems will treat mail as suspicious if:

• the IP has no PTR record, or
• the PTR hostname doesn’t resolve back to the IP (fails FCrDNS), or
• the hostname looks generic/misconfigured

If you use Google Workspace or Microsoft 365

Good news: you generally don’t need to manage rDNS yourself—those providers handle it. This post is still useful so you can recognize issues when a website host or third-party sender is involved.

---

The “match” concept (easy analogy)

Imagine you meet someone at a door:

• The name tag says “Alex from Accounting” (PTR record).
• You check the staff directory and it says Alex from Accounting works here (A record back to IP).

If the name tag and directory don’t match, you get cautious.

That’s rDNS/FCrDNS in a nutshell: basic identity consistency.

---

Common business scenario: website forms

This is one of the most common reasons rDNS becomes a problem:

• WordPress sends contact form emails directly from the hosting server.
• That server IP may have weak or missing rDNS.
• The mail looks “server-generated” and fails trust checks.
• Result: spam, deferrals, or outright blocks.

This is why you’ll hear advice like:

• “Don’t send form mail directly from shared hosting”
• “Use a transactional mail provider”
• “Use SMTP/API sending with authenticated identity”

It’s not just being picky—mail providers are protecting users from spam and phishing, and infrastructure identity is part of that.

---

What good rDNS looks like

A “good” setup typically has:

• A PTR record that points to a hostname that looks intentional (often under the sender’s domain or provider’s mail domain)
• That hostname has an A record that resolves back to the same IP (FCrDNS pass)
• The server’s HELO/EHLO hostname is consistent with that identity (more on this later)

You don’t need it to be perfect branding, but you do need it to be coherent.

---

How to check rDNS / FCrDNS (without getting too technical)

You can check rDNS with common DNS lookup tools by searching:

• “PTR lookup” for the sending IP
• or “reverse DNS lookup” tools

To confirm FCrDNS:

• Take the PTR hostname you found
• Check its A/AAAA record
• Confirm it returns the original IP

If you’re troubleshooting deliverability, you can also look at SMTP bounce messages—many will explicitly mention missing PTR/rDNS.

---

Practical advice: when you should care (and what to do)

You should care about rDNS/FCrDNS if:

• your website is sending mail directly from the server
• you’re using a dedicated sending IP
• you’re running a mail server (self-hosted)
• you see bounces referencing “PTR” / “reverse DNS” / “rDNS” / “FCrDNS”
• deliverability is inconsistent across providers

What to do:

• If you’re on shared hosting: avoid sending mail directly from the web server and route via a reputable email sender (SMTP/API). We use Postmark Sending service for our clients
• If you have a dedicated IP: set PTR properly with your host/provider and confirm forward resolution.
• If you use a third-party sender: confirm they manage rDNS correctly (most reputable ones do).

---

Managed Hosting Reality Check

If you’re on managed WordPress hosting, you often can’t control PTR records for the server IP—your hosting company owns that. That’s normal. It’s also why server-sent email from managed/shared hosting can be unreliable.

If rDNS is part of your problem, the simplest fix is usually not “fight the host.” It’s to change the sending method (send through a trusted provider that already has clean identity and reputation).

---

Quick rDNS / FCrDNS checklist

• If you send from a dedicated IP, it has a PTR record
• The PTR hostname resolves back to the same IP (FCrDNS pass)
• Your sending method isn’t “random server mail” from shared hosting
• Bounce logs don’t mention PTR/rDNS failures
• Your mail server identity is consistent (PTR, HELO/EHLO, SPF/DKIM where applicable)

---

rDNS / FCrDNS FAQs

---

Want NuStart to handle this for you?
If you’d rather not wrestle with DNS records, alignment, and testing, NuStart can audit your current setup and implement a clean, reliable Email Trust configuration end-to-end. Request an Email Trust Audit today to get started.