Reverse DNS Setup for Mail Servers That Pass FCrDNS

Do not index

Authenticated email can still land in spam when the sending IP has no usable reverse DNS, the PTR points to the wrong hostname, or the hostname fails the forward lookup. A reliable reverse DNS setup requires the IP owner to publish a PTR record, the returned hostname to resolve back to the same IP, and the SMTP HELO or EHLO identity to remain consistent with both records.

Table of Contents

Why Your Mail Still Lands in Spam Without Reverse DNS The failure pattern seen in production rDNS is not configured where many teams expect Where PTR Records Live and What FCrDNS Requires The FCrDNS loop How to Create PTR Records Across Common Hosting Scenarios Cloud VPS providers Dedicated servers On-premises servers and ISP delegation ESP customers Matching PTR HELO and SMTP Banner for Gmail and Outlook Good and bad identity choices How to Verify Reverse DNS With Dig and Other Tests Read the SMTP identity Common Mistakes That Break Reverse DNS and Deliverability The mistakes that keep recurring Reverse DNS setup FAQ Does the domain owner create the PTR record?What does FCrDNS verify?Is a valid PTR enough for inbox placement?What should an ESP customer verify?Who can help when ownership is unclear?

Why Your Mail Still Lands in Spam Without Reverse DNS

A campaign can have valid SPF, DKIM, and DMARC records yet receive a Gmail rejection or watch open rates collapse. One common cause sits outside the domain's ordinary DNS zone: the sending IP has no PTR record, or its PTR hostname doesn't resolve back to that IP. Receivers use this infrastructure signal while evaluating whether a connecting mail server looks legitimate.

Reverse DNS has been part of the operational DNS model for decades. PTR records were defined in RFC 1035, and later guidance stated that each IP address should have a matching PTR record in the in-addr.arpa domain. That history matters because rDNS identifies the host behind an address. It isn't a cosmetic label added after SPF and DKIM.

A practical email deliverability guide treats rDNS as one part of a broader trust system. Gmail, Outlook, and Yahoo still assess authentication, sending behavior, reputation, complaint signals, and connection details separately. A PTR record can remove an infrastructure objection, but it can't authenticate message content or guarantee inbox placement.

The failure pattern seen in production

A sender may own example.com, publish an SPF record, sign mail with DKIM, and enforce DMARC. The mail server can still connect from an IP whose reverse lookup returns a provider-default hostname or no hostname at all. If the receiving server performs a reverse lookup and then checks the hostname forward, the mismatch can make the connection appear suspicious.

That's why guidance on securing business email the right way needs to include server identity, not only domain authentication. The domain proves one part of the sender's authorization. Reverse DNS helps receivers assess whether the connecting infrastructure has a coherent identity.

rDNS is not configured where many teams expect

The PTR record doesn't belong in the DNS zone managed by the domain registrar or authoritative DNS provider. It belongs in the reverse zone controlled by the organization that owns the IP address, usually a cloud provider, hosting company, ISP, or dedicated server operator.

A 2025 deliverability benchmark reported 98% excellent reverse DNS adoption, with 2% of observed infrastructure lacking proper rDNS, as documented by the deliverability benchmark. That level of adoption changes the practical standard. A sender without correct rDNS increasingly looks like an outlier, not a normal configuration waiting for optimization.

The remainder of the setup depends on ownership. The right workflow is to identify who controls the IP, publish the forward hostname first, request or create the PTR with that exact name, and then verify FCrDNS and SMTP identity alignment.

Where PTR Records Live and What FCrDNS Requires

The first task in reverse DNS setup is identifying the authoritative owner of the sending IP. Teams often edit the right-looking DNS dashboard and still change nothing because they're working in the forward zone for example.com, while the PTR sits in a reverse zone owned by the IP provider.

For IPv4, reverse DNS uses in-addr.arpa. For IPv6, it uses ip6.arpa. Providers commonly manage reverse zones by address block, and the provider may either expose a self-service setting or handle the change after a support request. The domain team can create the forward A or AAAA record, but it usually can't create the PTR unless the IP block has been delegated.

The FCrDNS loop

Forward-confirmed reverse DNS, or FCrDNS, is a two-direction validation:

The sending IP resolves backward through PTR to a hostname such as mail.example.com.

mail.example.com resolves forward through an A record for IPv4 or an AAAA record for IPv6.

The forward result includes the original sending IP.

The returned hostname should be deliberate, stable, and associated with the mail server. A PTR that exists but points to a hostname with no matching forward record is not a complete mail identity. The email authentication guidance should be applied alongside this infrastructure check, because rDNS doesn't replace SPF, DKIM, or DMARC.

Each sending IP needs its own matching reverse configuration. Multiple IPs shouldn't rely on one PTR assumption, and a multi-homed server shouldn't leave only its first outbound address configured. IPv6 also needs its own reverse request in ip6.arpa; an IPv4 PTR doesn't cover IPv6 delivery.

The ownership boundary explains many stalled tickets. The domain's DNS administrator controls the A or AAAA record. The IP owner controls the reverse zone. FCrDNS passes only when both administrators publish compatible data.

How to Create PTR Records Across Common Hosting Scenarios

The workflow changes according to who owns the address block. The technical result is the same, but the control panel, request process, and delegation model differ.

Cloud VPS providers

Start with the hostname that should represent the sending server. Create its forward A record, or AAAA record when the server sends over IPv6, and confirm that it returns the correct public address.

AWS pattern: Use the provider's reverse DNS request path for the relevant elastic address, or submit the request through its console or support process. The requested PTR should be the same FQDN already published forward.

Google Cloud pattern: Set the external hostname in the Compute Engine network configuration where the provider exposes reverse DNS controls. If the setting isn't available for the address type, the account may need a provider request.

OVH pattern: Configure reverse DNS in the hosting control panel for the assigned address. The forward record still belongs in the domain's DNS zone, so both sides must be checked independently.

DigitalOcean pattern: The droplet hostname can drive the provider's PTR behavior. Set the server hostname deliberately before relying on automatic reverse mapping, then verify the result from outside the server.

The provider may apply the record quickly or require internal processing. The important operational point is not the interface. It's confirming that the actual public lookup returns the requested name and that the name resolves back to the same address.

Dedicated servers

A dedicated server host commonly controls the reverse zone for the assigned block. The customer should request a specific PTR for every outbound sending IP and provide the exact forward hostname.

Avoid submitting a vague request such as “enable rDNS.” Give the provider the address, the intended FQDN, and confirmation that the A or AAAA record is already published. If the provider offers a reverse DNS panel, use it to set one canonical PTR per address and remove stale values.

The hostname must also be configured in the mail transfer agent. A correct DNS record won't fix a server that introduces itself with a different HELO name or presents a conflicting SMTP banner.

On-premises servers and ISP delegation

An on-premises mail server depends on the ISP that assigned the public address. The ISP may create the PTR directly, delegate the reverse zone to the organization's authoritative nameservers, or restrict custom reverse DNS on the connection type.

Request delegation when the organization needs ongoing control over a routed address block. For a single address, direct provider-managed PTR publication is usually simpler. IPv6 requires a separate request for the relevant reverse zone and address, even when the same mail system handles both protocols.

ESP customers

An email service provider may manage the sending IP, PTR, HELO, and SMTP banner. That reduces the customer's configuration burden, but it doesn't remove the need for verification.

The customer should obtain the actual sending IPs, confirm the PTR hostname, run the forward lookup, and inspect message headers and bounce responses. If the provider uses a shared or pooled infrastructure, the customer may not control the identity at all. In that case, the relevant question is whether the provider can document and maintain FCrDNS for the addresses used by the account.

Matching PTR HELO and SMTP Banner for Gmail and Outlook

A valid PTR can still fail the practical mail test when the server introduces itself with another hostname. Receivers can compare the PTR result, the forward DNS record, the SMTP HELO or EHLO greeting, and the banner presented during connection handling. These names don't need to be decorative. They need to describe the same sending identity.

Gmail's enforcement guidance has included 5.7.25 rejection behavior for noncompliant reverse and forward DNS alignment, as discussed in this Gmail enforcement guidance. SPF and DKIM passing doesn't erase a broken server identity. Authentication answers who is authorized to send for a domain, while the connection identity answers whether the host appears coherently configured.

Good and bad identity choices

A coherent setup might use:

PTR: mail.example.com

Forward A record: mail.example.com resolves to the sending IP

HELO or EHLO: mail.example.com

SMTP banner: mail.example.com

A weak setup might publish a branded PTR but send EHLO server.provider.example, or retain a generic provider hostname in the banner. Another failure occurs when the PTR points to one branded hostname while the A record points to a different address.

Before changing production configuration, the sending team should decide:

Canonical hostname: Which FQDN represents the server?

Address coverage: Which IPv4 and IPv6 addresses can send?

SMTP identity: What hostname does the mail software use for HELO or EHLO?

Banner identity: What hostname does the receiving server see immediately after connection?

Authentication relationship: Does the sending domain still align correctly with SPF, DKIM, and DMARC?

Mailbox protection features also vary by environment. Teams reviewing EOP features for SMBs should remember that filtering decisions combine infrastructure identity with authentication and reputation. No single DNS record guarantees acceptance, and inconsistent names can erode trust even when the message signature is valid.

The revenue consequence is straightforward. Rejections delay transactional messages, spam placement hides marketing offers, and repeated failures can weaken the reputation attached to the sending infrastructure. A consistent identity doesn't guarantee inbox placement, but an inconsistent one creates an avoidable reason for receivers to distrust the connection.

How to Verify Reverse DNS With Dig and Other Tests

Verification should test the entire loop, not just whether a PTR record exists. The first command performs the reverse lookup:

dig -x SENDING_IP +short

A successful result returns the intended FQDN, such as mail.example.com. The next command tests the returned name forward:

dig mail.example.com A +short

For IPv6, query the AAAA record:

dig mail.example.com AAAA +short

The output must include the original sending address. If the reverse command returns no answer, the PTR is missing or unavailable from the queried resolver. If it returns a hostname whose forward result points elsewhere, FCrDNS fails.

Read the SMTP identity

DNS commands won't reveal every mismatch. A receiving server sees the actual connection greeting, so the mail team should inspect the SMTP service configuration and a delivered message header. The relevant values are the connecting IP, the Received chain, the HELO or EHLO hostname, and any bounce text referring to reverse or forward DNS.

Useful alternatives include:

host SENDING_IP
nslookup SENDING_IP

A generic hostname isn't automatically a rejection, but it can indicate that the provider default remains active. The fix is usually to choose one canonical hostname, publish it forward, request the matching PTR, and configure the SMTP service to use it consistently.

Test Result	What It Means	Fix Required
PTR returns the intended hostname, and A or AAAA returns the same IP	FCrDNS is structurally valid	Check HELO, banner, authentication, and reputation
`NXDOMAIN` on reverse lookup	No usable PTR exists for the address	Ask the IP owner to create the PTR or delegate the reverse zone
PTR returns a hostname, but forward lookup returns another IP	The bidirectional check fails	Correct the A or AAAA record, or request a corrected PTR
PTR is a provider default while HELO uses a branded name	Server identity is inconsistent	Align PTR, forward DNS, HELO, and banner
IPv4 passes but IPv6 fails	The IPv6 reverse path is incomplete	Request and validate the IPv6 PTR in `ip6.arpa`

After rDNS passes, teams should check your IP against blacklists as a separate reputation check. A clean reverse lookup doesn't prove that an address has no reputation problem, and a blacklist result doesn't explain an FCrDNS mismatch.

Common Mistakes That Break Reverse DNS and Deliverability

The most expensive rDNS errors are ownership errors, not syntax errors. Teams often know what a PTR record is but still apply it in the wrong place or validate only the easy half of the configuration.

The mistakes that keep recurring

Editing the domain zone: Creating a record under example.com doesn't create reverse DNS for the IP. The IP owner must publish the PTR, so editing the wrong dashboard wastes time while mail continues to face the same trust objection.

Creating PTR first: A PTR without a matching A or AAAA record fails FCrDNS. Create the forward record first, then request the reverse record with the identical hostname.

Leaving a generic hostname active: A provider-default name may identify the infrastructure owner rather than the sending organization. It can also conflict with the SMTP greeting, giving receivers another reason to scrutinize or reject the connection.

Ignoring IPv6: An IPv4 PTR doesn't cover IPv6. If the server can send over IPv6, the IPv6 reverse path needs separate ownership, publication, and testing.

Assuming one PTR covers every address: Each sending IP needs a matching reverse identity. A second outbound address with no PTR can create intermittent failures that are difficult to reproduce.

Checking only a lookup tool: A tool may show a valid PTR while missing the HELO, banner, and actual outbound IP used in production. Header and SMTP-level checks are necessary.

These failures affect more than technical cleanliness. Rejections reduce the number of messages that reach customers, spam placement suppresses conversions, and repeated infrastructure problems can damage brand trust. The 98% excellent adoption benchmark cited earlier shows why receivers can treat missing or poor rDNS as an unusual condition rather than an acceptable default.

Reverse DNS setup FAQ

Does the domain owner create the PTR record?

Usually not. The PTR lives with the IP owner, such as the cloud provider, hosting company, ISP, or organization controlling the delegated reverse zone.

What does FCrDNS verify?

It verifies that the IP resolves through PTR to a hostname and that the hostname resolves forward through A or AAAA to the same IP.

Is a valid PTR enough for inbox placement?

No. Reverse DNS is one trust signal. Receivers also assess SPF, DKIM, DMARC, reputation, complaint behavior, and other connection factors.

What should an ESP customer verify?

The customer should confirm the actual sending IPs, PTR hostnames, forward resolution, HELO or EHLO identity, SMTP banner, and bounce behavior, even when the ESP manages the records.

Who can help when ownership is unclear?

A deliverability review can map the IP owner, DNS owner, mail software identity, and authentication relationships. That distinction is often necessary when several providers manage different parts of the sending path.

MailAdept combines subscription-based deliverability consulting with AI agents and human experts to trace PTR ownership, validate FCrDNS, inspect HELO and SMTP banner alignment, and connect infrastructure findings to SPF, DKIM, DMARC, and reputation risks. Teams dealing with recurring rejections or unexplained spam placement can visit Mailadept for help resolving the configuration rather than relying on a PTR lookup alone.