How to Set Up Reverse DNS for Email

Do not index

Your transactional emails are failing, outbound replies are slowing, and the sending domain looks properly authenticated. SPF passes. DKIM passes. DMARC is published. Yet messages still land in spam, or the receiving server rejects the connection before it evaluates the message.

The missing piece may be reverse DNS, also called rDNS. Reverse DNS maps a sending IP address to a hostname through a PTR record. For email, that hostname must resolve back to the same IP through a forward A or AAAA record, a relationship called forward-confirmed reverse DNS, or FCrDNS. The important operational detail is easy to miss: the domain registrar usually doesn't control the PTR record. The IP owner, such as a cloud provider, VPS host, or ISP, does.

This guide explains how to set up reverse DNS for email, validate the actual SMTP path, and separate a genuine infrastructure problem from broader authentication or reputation issues. For the wider relationship between DNS records and authentication, see this practical guide to SPF DMARC DNS explained.

Table of Contents

Why Missing Reverse DNS Sends Email to Spam What receiving servers evaluate Why a generic PTR still causes trouble The Forward-Confirmed Reverse DNS Workflow Follow the dependency chain Confirm FCrDNS before sending Provider-Specific Setup Instructions Cloud and VPS environments IPv6 requires a different reverse namespace Verifying Your Configuration and SMTP Path Test both directions Validate the live SMTP path Common Mistakes That Break Deliverability What to avoid Diagnostic Workflows and Frequently Asked Questions Frequently asked questions Who controls a reverse DNS record?Does a PTR record guarantee inbox placement?Does IPv6 need reverse DNS?What happens when a third-party relay sends the email?How long do changes take to appear?

Why Missing Reverse DNS Sends Email to Spam

A sender can have correct SPF, DKIM, and DMARC records and still fail an infrastructure-level trust check. When an outbound server opens an SMTP connection, the receiving system sees the connecting IP before it has assessed the message body, links, or campaign copy. It commonly performs a reverse lookup to find the hostname associated with that IP, then checks whether the hostname resolves forward to the same address.

That check happens around the SMTP greeting, where the sending server identifies itself with a HELO or EHLO hostname. A missing PTR record, a generic provider hostname, or a hostname that points somewhere else creates an inconsistent identity chain. The receiving server may defer the message, reject it, or treat the connection as suspicious during the SMTP handshake.

What receiving servers evaluate

A useful way to think about the connection is as a sequence of questions:

Does the IP have a PTR record? A missing record can indicate unmanaged or poorly configured sending infrastructure.

Is the PTR hostname stable and meaningful? A custom hostname such as mail.example.com is easier to align with the rest of the mail stack than a generic provider label.

Does the hostname resolve back to the sending IP? This is the forward-confirmed portion of FCrDNS.

Does the HELO or EHLO value match? A mismatch can make the server appear to claim different identities.

Do authentication and reputation signals support the connection? PTR doesn't replace SPF, DKIM, DMARC, or a clean sending history.

Google and Yahoo treated missing reverse DNS as a blocking issue in April 2024, while Microsoft applied the requirement on May 5, 2025 to senders sending 5,000 or more messages per day. The dates and threshold are documented in this reverse DNS deliverability overview. The practical conclusion is straightforward, especially for high-volume infrastructure: a valid PTR is no longer a cosmetic DNS improvement.

Why a generic PTR still causes trouble

A provider may assign a default hostname that technically answers a reverse lookup but doesn't match the sender's mail identity. That record can clear a basic existence check while leaving the SMTP banner, forward DNS, and visible sending domain out of alignment.

Mailbox providers don't treat a PTR record as proof that a message belongs in the inbox. It is one infrastructure signal among several. A valid result can remove one reason for suspicion, but a damaged IP reputation, blacklist listing, broken DKIM alignment, or weak DMARC policy can still divert mail to spam.

The Forward-Confirmed Reverse DNS Workflow

The first correction is about ownership. A domain registrar or regular DNS host manages records such as A, AAAA, MX, TXT, and CNAME. The organization that controls the IP range manages the reverse zone and publishes the PTR record. That usually means the cloud provider, VPS company, dedicated-server host, or ISP must create or delegate the reverse entry.

Follow the dependency chain

Identify the actual sending IP. Confirm which public IPv4 or IPv6 address opens the SMTP connection. A server can have several addresses, and configuring the wrong one won't change the production mail path.

Identify the IP owner. Check the provider's network or IP-management area. If no reverse DNS option exists, open a support request and provide the exact IP and requested fully qualified domain name.

Choose a stable hostname. A name such as mail.example.com is appropriate when it represents the server's actual sending identity. The name should remain stable through routine application and DNS changes.

Ask the IP owner to publish the PTR. The provider should map the sending IP to the selected hostname. Some providers expose self-service controls, while others require manual approval or a support ticket.

Publish the forward record. At the domain DNS host, create an A record for IPv4 or an AAAA record for IPv6 that maps the PTR hostname back to the same sending address.

Align the SMTP identity. Configure the mail server's SMTP banner and HELO or EHLO hostname to use the same FQDN. A correct PTR with a different SMTP greeting leaves the identity chain incomplete.

Confirm FCrDNS before sending

FCrDNS passes only when both directions agree:

Reverse direction: sending IP → PTR hostname

Forward direction: PTR hostname → the same sending IP

If the PTR points to mail.example.com, but the A record returns another address, the check fails. The same principle applies to IPv6 through an AAAA record. Fix the forward record at the domain DNS host, or ask the IP owner to correct the PTR target if the reverse entry is wrong.

This ownership distinction also matters when an IP reputation problem is involved. Reverse DNS repair may be one step in sending IP reputation repair, but it can't repair a history of complaints or abusive traffic by itself.

Provider-Specific Setup Instructions

Reverse DNS configuration varies by infrastructure type because the control plane follows the IP allocation, not the domain registration. A domain DNS dashboard may show no PTR setting at all, and that absence usually isn't an error. It means the reverse zone belongs to another operator.

Provider Type	Configuration Location	IPv6 Support
Cloud infrastructure	Reserved or assigned IP settings, network interface controls, or provider support	Often available through address or prefix management, with provider-specific delegation
VPS hosting	IP management panel, reverse DNS screen, or support ticket	Depends on the assigned address block and provider policy
Bare-metal server	Dedicated-server control panel or infrastructure support team	Usually requires prefix-level coordination for larger allocations
ISP-managed connection	ISP account portal or technical support	Often restricted, especially for residential or dynamic allocations

Cloud and VPS environments

For cloud infrastructure, search for Elastic IP, reserved IP, network interface, or reverse DNS, rather than opening the standard hosted-zone editor. The PTR may be attached to an individual address reservation or interface. A provider may also require the forward hostname to exist before it accepts the reverse DNS request.

VPS platforms commonly provide one of two models. A self-service panel lets the customer enter the hostname, or the provider requires a ticket containing the IP, FQDN, and confirmation that the forward record is ready. Shared or dynamically assigned addresses may not support a custom PTR, which makes them a poor fit for a self-hosted SMTP server.

Bare-metal providers can offer more control, but the operational process may still be manual. Teams managing multiple addresses should document which IP sends which traffic, because a PTR change on one address doesn't fix a second production address.

IPv6 requires a different reverse namespace

IPv6 reverse DNS uses the ip6.arpa tree rather than the IPv4 reverse namespace. RFC 4472 describes the IPv6 reverse-zone structure, while RFC 8501 discusses operational models such as prefix delegation, wildcard PTRs, dynamic DNS, and on-demand generation for larger address pools. The standards background is available in this IPv6 reverse DNS operational reference.

For a single IPv6 address, the provider may expose a straightforward PTR setting. For an allocated prefix, the operator may need to publish name-server delegation, coordinate the reverse zone with the provider, and generate individual PTR records. A dual-stack mail server must validate the IPv4 and IPv6 paths separately. Fixing IPv4 doesn't make an IPv6 connection trustworthy.

Verifying Your Configuration and SMTP Path

A provider marking a reverse DNS request complete does not confirm that production mail uses the intended identity. Test the public DNS response and the actual SMTP connection, because cached answers, multiple outbound interfaces, and relays can hide configuration errors.

Test both directions

For an IPv4 sending address, run dig -x or nslookup and confirm that the PTR returns the intended FQDN. Query that FQDN forward and verify that its A record returns the original sending address. For IPv6, repeat the process with the IPv6 address and confirm that the hostname's AAAA response points back to it.

Check each of these conditions:

Is a PTR present?

Does it return one deliberate hostname?

Does that hostname resolve to the sending address?

Does it match the server's HELO or EHLO identity?

Do independent public resolvers return the same result?

The mailX PTR Lookup and other DNS tools can display reverse and forward results without relying on a single local resolver. The useful evidence is the complete relationship between the records, not a successful PTR lookup.

Validate the live SMTP path

Correct DNS is irrelevant if another address opens the recipient's SMTP connection. Identify the public IP observed during delivery, then compare its PTR hostname with the SMTP banner and HELO or EHLO value. For a relay-based setup, validate the relay's IP and hostname. The application server's internal hostname does not establish the receiving server's identity.

Teams using managed SMTP can consult SendGrid SMTP best practices Tagada to separate relay configuration from DNS tasks controlled by the sender. Confirm which system connects to the recipient. That system owns the deliverability path you need to test.

Send a controlled message to an account you can inspect, then review the raw headers. Check the authentication results, the recorded sending path, and the hostnames associated with the connection. Header evidence does not replace an external PTR and forward-confirmation test, but it can expose an unexpected outbound IP or relay.

Test from more than one network or resolver where possible. DNS caches may preserve an old PTR after a change, while a production connection can still leave through a different address.

Before declaring the configuration complete, check ip blacklist spamhaus. FCrDNS confirms identity alignment, not reputation. A listed IP or an existing sending-history problem can still affect delivery even when every DNS check passes.

Common Mistakes That Break Deliverability

A PTR record is necessary for many mail infrastructures, but it isn't an inbox-placement guarantee. The common failure is treating reverse DNS as a single record instead of an identity chain that includes the IP owner, forward DNS, SMTP greeting, authentication, and reputation.

What to avoid

Editing the wrong DNS panel. Adding a PTR record at the registrar won't change the provider-owned reverse zone. Contact the IP owner instead.

Leaving a generic hostname in place. A default provider name may not align with the SMTP banner or the domain used for sending.

Publishing mismatched forward DNS. If the PTR hostname resolves to a different address, FCrDNS fails even though the PTR exists.

Using inconsistent HELO or EHLO values. The server greeting should match the intended reverse hostname.

Creating multiple competing PTR values. A single IP should present a clear, deliberate reverse identity. Multiple answers can produce inconsistent checks.

Assuming PTR replaces authentication. SPF authorizes sending sources, DKIM signs message content, and DMARC evaluates alignment and policy. Reverse DNS doesn't perform those jobs.

Ignoring reputation and blacklist status. A valid lookup doesn't erase complaints, poor list hygiene, abusive traffic, or an IP listing.

DNS changes can also appear broken while resolvers still hold older answers. Check the authoritative provider response, account for caching, and test again after the published TTL has elapsed. If the production server uses more than one address, verify every address that sends mail, including IPv6.

Diagnostic Workflows and Frequently Asked Questions

A reliable diagnosis follows the public SMTP path, not the settings in an application dashboard. Start by identifying the address that sends mail, then check each identity it presents:

Confirm the production sending IP and its PTR.

Validate FCrDNS by checking the PTR hostname's matching A or AAAA record.

Compare that hostname with the SMTP HELO or EHLO value.

Check SPF, DKIM, and DMARC alignment.

Test SMTP and, where applicable, IMAP connectivity.

Review blacklist status and sender reputation.

Run a full mailX audit and convert the findings into prioritized fixes.

mailX provides live checks for PTR, DNS, authentication, SMTP, IMAP, blacklist status, and related email infrastructure. Developers and AI agents can also use its MCP endpoint and Agent Skill to inspect infrastructure before an automated workflow sends a campaign.

Frequently asked questions

Who controls a reverse DNS record?

The IP owner controls the reverse zone. A cloud provider, VPS host, or ISP must publish the PTR unless it delegates that authority. The domain registrar cannot change a provider-owned reverse zone.

Does a PTR record guarantee inbox placement?

No. PTR supports infrastructure validation, while SPF, DKIM, DMARC, reputation, blacklist status, content, and sending behavior affect delivery. Forward-confirmed reverse DNS helps establish a consistent identity, but it is one part of the SMTP trust signal.

Does IPv6 need reverse DNS?

Yes, when a mail server sends over IPv6. Its reverse zone uses the ip6.arpa namespace, and the PTR hostname must resolve back through AAAA.

What happens when a third-party relay sends the email?

The relay's public sending IP, PTR, forward DNS, and SMTP identity are the relevant signals. The application server's private hostname does not determine the recipient's reverse lookup.

How long do changes take to appear?

Provider processing and resolver caching affect visibility. Check authoritative responses and public resolvers, then test again after cached answers expire. A dashboard update does not prove that every recipient sees the new record.

Use mailX to run a live deliverability audit covering reverse DNS, FCrDNS, authentication, SMTP, blacklist status, and related infrastructure. It returns plain-language explanations and specific fixes for teams and AI agents troubleshooting a campaign or transactional release.